bugtraq - New Correction: Re: Serious crypto problem fixed by envelope HMAC method instead of currently used prefix

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Tue, 21 Nov 2006 09:31:32 -0500
From: "Omirjan Batyrbaev" <batyr@...patico.ca>
To: <bugtraq@...urityfocus.com>
Subject: New Correction: Re: Serious crypto problem fixed by envelope HMAC method instead of currently used prefix

Hi,
The problem/bug that I described below still affects SSLv2 servers and
clients.
SSLv2 (still an option in the browsers) is vulnerable to this extension
attack. SSL v3 and TLS are not affected.

Thanks.
Regards,
Omirjan Batyrbaev, CTO B3 Security Corp.
batyr@...ecuritycorp.com

----- Original Message ----- 
From: "Omirjan Batyrbaev" <batyr@...patico.ca>
To: <bugtraq@...urityfocus.com>
Sent: Monday, November 20, 2006 1:45 PM
Subject: Correction: Re: Serious crypto problem fixed by envelope HMAC
method insteadof currently used prefix


> Hi,
> This would have been a problem if the HMAC was just SHA-1(...) or MD5
(...)
> or similar type of prefix HMAC. However, the HMAC used in TLS is more
> involved construct (see RFC 2104) and the attack is not applicable.
> ----- Original Message ----- 
> From: "Omirjan Batyrbaev" <batyr@...ecuritycorp.com>
> To: <bugtraq@...urityfocus.com>
> Cc: <dm@...urityfocus.com>
> Sent: Sunday, November 19, 2006 9:44 PM
> Subject: Serious crypto problem fixed by envelope HMAC method insteadof
> currently used prefix
>
>
> > Hi,
> >
> > I propose to use envelope method instead of currently used prefix method
> in
> > HMAC used in TLS/SSL. The measure is important especially since it was
> > pointed out that the
> > NULL cipher suites have a real use and since some ciphers are
> intentionally
> > weak. With the NULL cipher (or the easily broken 40 bits cipher) the
> current
> > HMAC
> > construct is exploitable by an active attacker who appends to the
message
> > and substitutes the new message and the newly generated HMAC value for
the
> > originals. On the server side the HMAC operation will succeed. Of course
> it
> > can be the server message that gets compromised this way. This attack is
> > well known in the crypto community and is well documented in HAC
(Handbook
> > of Applied Cryptography). The book is available online and I can send
you
> a
> > page reference if you are not familiar with the attack on the HMAC
prefix
> > method.
> >
> > I quote TLS 1.2:
> > "The MAC is generated as:
> >
> >        HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
> >                      TLSCompressed.version + TLSCompressed.length +
> > TLSCompressed.fragment));
> >
> >    where "+" denotes concatenation."
> >
> > This is subject to the above mentioned attack.
> >
> > Instead I propose the HMAC construct which is not prone to the above
> stated
> > exploit:
> >
> >        HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
> >                      TLSCompressed.version + TLSCompressed.length +
> > TLSCompressed.fragment + MAC_write_secret));
> >
> > addition of the MAC_write_secret as the last bits of the input to the
HMAC
> > makes it envelope method which is secure against the above stated
exploit.
> >
> > Versions affected Products that implemented TLS 1.2; 1.1; 1.0 and SSL
v3,
> > v2, v1.
> >
> > PS: it makes no difference if the plaintext compressed or not I just
> quoted
> > from the draft/specs.
> >
> >
> > Thanks.
> > Regards,
> > Omirjan Batyrbaev, CTO B3 Security Corp.
> > batyr@...ecuritycorp.com
> >
>