Hello,
I had some discussion with Bart Preneel[0] on the use of a 96-bit
MAC for the Finished messages. His comments were:
My general advice to IETF was to keep half the bits of the internal
state of the hash function. For HMAC-MD5 this would be 64 bits, for
HMAC-SHA-1 this would be
80 bits and
On 03/14/2011 05:49 PM, Martin Rex wrote:
The MD5 output is 128 bits = 16 bytes, and the input is *MUCH* larger
than 128 bits. The master_secret should is 48 bytes alone. Even if one is
successful at inverting MD5, one can not undo the collisions from
the Finished computation caused by the
At 8:20 AM +0100 3/11/11, Nikos Mavrogiannopoulos wrote:
...
What Peter probably meant to say was that IPsec chose to truncate the
HMAC value to 96 bits because that preserved IPv4 and IPv6
byte-alignment for the payload. Also, as others have noted, the hash
function used here is part of
Nikos Mavrogiannopoulos wrote:
This sounds pretty awkward decision because HMAC per record is full
(e.g. 160-bits on SHA-1), but the MAC on the handshake message
signature is truncated to 96-bits. Why wasn't the record MAC
truncated as well? In any case saving few bytes per handshake
is
On 03/14/2011 06:28 PM, Martin Rex wrote:
Nikos Mavrogiannopoulos wrote:
This sounds pretty awkward decision because HMAC per record is full
(e.g. 160-bits on SHA-1), but the MAC on the handshake message
signature is truncated to 96-bits. Why wasn't the record MAC
truncated as well? In any
Nikos Mavrogiannopoulos wrote:
On 03/14/2011 06:28 PM, Martin Rex wrote:
That was, what I assume, the fear, based on the second part of this
message from Dan Simon
http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0224.html
and the second part of this message from Hugo
If your question is why did the TLS WG decide to do this back in like
1996 or so?
If so, it would require a real archive search to get a definitive
answer, but my vague
memory is that (a) it was suggested by one of the cryptographers in
the group, e.g.
Hugo Krawczyk or Ran Canetti and (b) it was
Eric Rescorla wrote:
If your question is why did the TLS WG decide to do this back in like
1996 or so?
If so, it would require a real archive search to get a definitive
answer
A very superficial scan of the first ietf-tls 1996 archive I came across
turned out an an interesting thread
On Fri, Mar 11, 2011 at 8:07 AM, Martin Rex m...@sap.com wrote:
I don't recall why 12 bytes rather than 16 bytes or 20 was chosen.
It is not unusual when a two group of folks (IPSEC and TLS) sourcing from
the same pool of engineers and experts (IETF) have to do two very
similar decisions
Eric Rescorla e...@rtfm.com writes:
Overflowing by another 32 bits is hardly the same as there was only room
for
If you've decided that the size is going to be 192 bits and, due to other
changes, you have only 96 bits left, I don't see how this is anything other
than there was only room for.
At 5:08 PM -0800 3/8/11, Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 3:55 PM, Peter Gutmann
pgut...@cs.auckland.ac.nz wrote:
Martin Rex m...@sap.com writes:
Truncating HMACs and PRFs may have become first popular in the IETF within
IPSEC.
It wasn't any may have become first popular,
On 03/11/2011 12:28 AM, Stephen Kent wrote:
It wasn't any may have become first popular, there was only
room for 96 bits of MAC data in the IP packet, so MD5 was
truncated to that size.
This is an odd claim, since:
(a) RFC 1828 (http://tools.ietf.org/html/rfc1828) originally
specified
On Tue, Mar 8, 2011 at 7:51 PM, Eric Rescorla e...@rtfm.com wrote:
Perhaps, but this isn't a digest but rather a MAC, and so the attack
model is different.
You seem to be forgetting that the finished messages have been reused
for other purposes already:
No, I'm not forgetting that. That
Overflowing by another 32 bits is hardly the same as there was only room for
-Ekr
On Wed, Mar 9, 2011 at 1:57 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote:
Eric Rescorla e...@rtfm.com writes:
Can you please point to where in IP there is a limit that requires a MAC no
greater than 96
On Wed, Mar 9, 2011 at 1:10 AM, Nikos Mavrogiannopoulos n...@gnutls.org wrote:
On Tue, Mar 8, 2011 at 7:51 PM, Eric Rescorla e...@rtfm.com wrote:
Perhaps, but this isn't a digest but rather a MAC, and so the attack
model is different.
You seem to be forgetting that the finished messages have
On Wed, Mar 9, 2011 at 3:34 PM, Eric Rescorla e...@rtfm.com wrote:
I'm not a specialist in MAC algorithms but by checking
the ECRYPT II[0] report of 2009-2010, I can try making some points.
A MAC has a security level that depends on the size of the MAC
and the size of the key. That is a
On Wed, Mar 9, 2011 at 7:28 AM, Nikos Mavrogiannopoulos n...@gnutls.org wrote:
On Wed, Mar 9, 2011 at 3:34 PM, Eric Rescorla e...@rtfm.com wrote:
I'm not a specialist in MAC algorithms but by checking
the ECRYPT II[0] report of 2009-2010, I can try making some points.
A MAC has a security
On 03/08/2011 09:59 AM, Martin Rex wrote:
To me, Truncating the output of a SHA-384 PRF to 12 Octets looks like
unreasonable cutdown of the security margin for the Finished messages.
I agree.
Last I looked into it, I came to the conclusion that collisions of any
efficient 96 bit hash
On 03/08/2011 11:33 AM, Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 9:20 AM, Martin Rexm...@sap.com wrote:
Eric Rescorla wrote:
I don't understand this reasoning. Why does the output size of the
pre-truncated PRF
influence the desirable length of the verify_data (provided that the
output
On 03/08/2011 12:45 PM, Martin Rex wrote:
RFC-5746 TLS extension Renegotiation indication
Yes, it would be bad if those could be collided.
I'm sorry, but I think it is a bad idea to use a flawed design for
the TLS finished message by subverting the collision resistence
of stronger
Martin Rex m...@sap.com writes:
Truncating the PRF output to 12 octets for TLSv1.2 seems like an error.
It's not an error, it's IPsec cargo cult design. OK, using cargo cult design
for a security protocol probably rates as an error, but the choice of exactly
96 bits was deliberate rather than
Sean Turner wrote:
Yours was the first document I noticed to use SHA384 as PRF. If there
are other documents that specify that, and don't set the verify_data_length
size then it applies to those as well. (just noticed that applies to RFC5288
as well).
If the verify_data_length default
I don't understand this reasoning. Why does the output size of the
pre-truncated PRF
influence the desirable length of the verify_data (provided that the
output size is than
the length of the verify_data of course).
-Ekr
On Tue, Mar 8, 2011 at 7:59 AM, Martin Rex m...@sap.com wrote:
Sean
Eric Rescorla wrote:
I don't understand this reasoning. Why does the output size of the
pre-truncated PRF
influence the desirable length of the verify_data (provided that the
output size is than
the length of the verify_data of course).
One of the purposes of a cryptographic hash function
On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex m...@sap.com wrote:
Eric Rescorla wrote:
I don't understand this reasoning. Why does the output size of the
pre-truncated PRF
influence the desirable length of the verify_data (provided that the
output size is than
the length of the verify_data of
Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex m...@sap.com wrote:
Eric Rescorla wrote:
I don't understand this reasoning. Why does the output size of the
pre-truncated PRF
influence the desirable length of the verify_data (provided that the
output size is than
On Tue, Mar 8, 2011 at 10:07 AM, Martin Rex m...@sap.com wrote:
Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex m...@sap.com wrote:
Eric Rescorla wrote:
I don't understand this reasoning. Why does the output size of the
pre-truncated PRF
influence the desirable length
On Tue, Mar 8, 2011 at 10:15 AM, Marsh Ray ma...@extendedsubset.com wrote:
On 03/08/2011 11:33 AM, Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 9:20 AM, Martin Rexm...@sap.com wrote:
Cutting down the SHA-384 output from 48 to 12 octets significantly
impairs
its ability to protect from
Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 10:07 AM, Martin Rex m...@sap.com wrote:
Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex m...@sap.com wrote:
Eric Rescorla wrote:
I don't understand this reasoning. Why does the output size of the
pre-truncated PRF
On Tue, Mar 8, 2011 at 10:30 AM, Martin Rex m...@sap.com wrote:
Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 10:07 AM, Martin Rex m...@sap.com wrote:
Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex m...@sap.com wrote:
Eric Rescorla wrote:
I don't understand this
Eric Rescorla wrote:
Marsh Ray wrote:
I think he's arguing that anything cut down to 96 bits represents a lousy
hash function allowing practical collisions on today's hardware.
Perhaps, but this isn't a digest but rather a MAC, and so the attack
model is different.
You seem to be
On Tue, Mar 8, 2011 at 10:45 AM, Martin Rex m...@sap.com wrote:
Eric Rescorla wrote:
Marsh Ray wrote:
I think he's arguing that anything cut down to 96 bits represents a lousy
hash function allowing practical collisions on today's hardware.
Perhaps, but this isn't a digest but rather a
Eric Rescorla wrote:
If we move in a new, stronger crypto-algorithm, then we should not
unreasonably spoil its properties.
Truncating a SHA-384 based PRF to 12 octets is like using
an sha384WithRsaEncryption signature with a 1024 bit RSA key,
it is an imbalanced pairing of
Eric Rescorla wrote:
I'm sorry, but I think it is a bad idea to use a flawed design for
the TLS finished message by subverting the collision resistence
of stronger secure hash functions that are used for the PRF.
Yes, I realize you think that, but until you offer a cryptographic
Martin Rex wrote:
The truncation of hashes/PRFs/HMACs is a trade-off.
A trade-off between collision-resistance and how much clue
is provided about the input.
TLSv1.0 (rfc2246) references RFC-2104 (HMAC)
TLSv1.1 (rfc4346) contains a normative reference to RFC-2104 (HMAC)
TLSv1.2
resend (Sorry, for the typos.)
Martin Rex wrote:
The truncation of hashes/PRFs/HMACs is a trade-off.
A trade-off between collision-resistance and how much clue
is provided about the input.
TLSv1.0 (rfc2246) references RFC-2104 (HMAC)
TLSv1.1 (rfc4346) contains a normative reference
On Tue, Mar 8, 2011 at 12:19 PM, Martin Rex m...@sap.com wrote:
resend (Sorry, for the typos.)
Martin Rex wrote:
The truncation of hashes/PRFs/HMACs is a trade-off.
A trade-off between collision-resistance and how much clue
is provided about the input.
TLSv1.0 (rfc2246) references
On Tue, Mar 8, 2011 at 3:55 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote:
Martin Rex m...@sap.com writes:
Truncating HMACs and PRFs may have become first popular in the IETF within
IPSEC.
It wasn't any may have become first popular, there was only room for 96 bits
of MAC data in the IP
38 matches
Mail list logo
