Subject: [dane] hash truncated to 28 octets

From: "Jiankang Yao" <[email-masked]>
Date: Tue, 4 Aug 2015 10:10:06 +0800

Hello,

I just read this draft.

in section 3, of draft-ietf-dane-openpgpkey-03.txt 

"

If it("local-part" in the mail message ) is written in another encoding it should be
      converted to UTF-8.  Next, it is turned into lowercase and hashed
      using the SHA2-256 [RFC5754] algorithm, with the hash truncated to
      28 octets and represented in its hexadecimal representation, to
      become the left-most label in the prepared domain name.
      Truncation comes from the right-most octets.  This does not
      include the at symbol ("@") that separates the left and right
      sides of the email address.
"

Question:
1, why should it be  hash truncated to 28 octets ? why choose 28 not other numbers?
2,since some local-parts are longer than 28 octets, are there some collisions after hash truncated to 28 octets ?

Best Regard

Jiankang Yao

---

From: Paul Wouters <[email-masked]>
Date: Tue, 4 Aug 2015 03:50:32 -0400 (EDT)

> I just read this draft.

Note we are changing that part of the draft to use another mechanism
instead of hashing.

> 1, why should it be  hash truncated to 28 octets ? why choose 28 not other numbers?

It was to match the length of the previous draft's sha224 version. That
algorithm wasn't available on all platforms (eg Microsoft) so it was
changed to sha256 but truncated. Truncation was to make the labels
smaller and more managable.

> 2,since some local-parts are longer than 28 octets, are there some collisions after hash truncated to 28 octets ?

I think if you have 100.000 email addresses in one domain, the chance of
collision would be pretty small. but non-zero.

anyway, we will use base32 split encoding in the next version of the
draft.

Paul

---

From: Hosnieh Rafiee <[email-masked]>
Date: Tue, 4 Aug 2015 08:13:27 +0000

> I think if you have 100.000 email addresses in one domain, the chance
> of collision would be pretty small. but non-zero.
> 

What about the privacy? Leave it alone without thinking at all about privacy and say that other WGs are taking care of this so why we should bother outselves?
Is it a right way to do this!? We all know that, if we are so optimistic and say that Dprive can come up with a good solution very quickly, it takes time that all systems implement and support it (if we say there will be no problem at all or any new attacks), We have seen how fast a security system is deployed and supported , let's not go so far and back to the history of DNSSEC... .

 To be realistic, this will result in either no implementation of this approach in mail system until the privacy is clear or not enabling this approach, although, it is there because it has even no weak privacy protection. Therefore, the old way of key exchange is preferable over this one.

Best,
Hosnieh

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 4 Aug 2015 12:12:45 +0000

On Tue, Aug 04, 2015 at 03:50:32AM -0400, Paul Wouters wrote:

> >2,since some local-parts are longer than 28 octets, are there some collisions after hash?truncated?to?28?octets??
> 

You'd need 2^112 email addresses for an appreciable chance of
collision.  If every person on the planet (say 10^{10} people some
day) each had 100 email addresses in the same domain, that'd be
10^{12} or ~2^{40} addresses.  The collision probability would be
around 2^{80}/2^{112} = 2^{-32} ~ 10^{-6}.  With "just" 10^{10}
addresses, it drops by a factor of 10^4 to 10^{-10}.

So we'd need around 10^10 Gmail sized domains before seeing a
collision in one of them.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 5 Aug 2015 18:49:15 +0000

> addresses, it drops by a factor of 10^4 to 10^{-10}.

For the record, the above vastly overestimates the collision
probability.  I accidentally computed the probability for a 112-bit
hash, not a 224-bit hash.

For a 224-bit hash, the collision probability with 10^{12} addresses
is around 2^{80}/2^{224} or 2^{-144}.  No collisions are likely
before Earth is incinerated by a red-giant Sun around 2^{85}
nanoseconds from now.

-- 
	Viktor.