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>] [thread-next>] [day] [month] [year] [list]
Date: Sun, 19 Nov 2006 21:44:21 -0500
From: "Omirjan Batyrbaev" <batyr@...ecuritycorp.com>
To: <bugtraq@...urityfocus.com>
Cc: <dm@...urityfocus.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ