if someone with a domainname called "collisions" still doesn't understand what a HMAC is, then it is clear what is going on -- that person is simply fighting a war against math they don't understand.
tobias, there is no need for a long explanation of what a HMAC is, you are facing someone with an AGENDA. Tobias Heider <[email protected]> wrote: > Hi Stephan, > > >> "Also: the mentioned sha1 transform is also a HMAC construction and > >> technically > >> safe to use (for now), same as the PRF." > > > > I don't get how this could be ? SHA-1 for signage and hash generation is > > colliding. How can it be that this doesn't apply for iked ? > > It is true that there have been several successful collission attacks against > SHA-1 in the last years and it is NOT safe to use plain sha-1 as a integrity > verification hash nowadays, but there are exceptions. > > So what can an attacker do with these attacks? > Given a sha-1 hash 'h' of some arbitrary bytestring 'a', an attacker utilizing > the attack could in the worst case craft a second bytestring 'b' which would > generate the same sha-1 hash value 'h'. > For this to work, the attacker must be able to control the input to the hash > function, in this case 'b'. > > Why is this not a problem for iked and esp? > ESP and IKEv2 don't use a plain sha-1 hash for the integrity verification but > a so called keyed-hash message authentication code (or HMAC) [1]. > Given a message m, and our hash algorithm H we don't simply hash the message > to get H(m) as the integrity check value (ICV). > > Instead we compute ICV = H(K XOR opad, H(K XOR ipad, m)), where K is a secret > key shared between the two peers (resulting from the previous Diffie-Hellman > exchange) and ipad and opad are constant values of: > > ipad = the byte 0x36 repeated $SHA1-BLOCKSIZE times > opad = the byte 0x5C repeated $SHA1-BLOCKSIZE times. > > This makes things a lot more complicated for the attacker because it requires > knowledge of the key K. This kind of HMAC construction is generally assumed > to be resistant against chosen-prefix attacks as we have seen the for sha-1, > for a more detailed analysis see for example [2]. > Indeed even today there is no known attack against HMAC-MD5 in this same > construction. > > That being said, this doesn't mean it is a good idea to use HMAC-MD5 in new > applications and it is also a good idea to get rid of sha-1 hmacs wherever > we can, which is why your diff is actually perfectly valid. > But for today, there is no known attack and it is technically still considered > safe to use. This means we actually have the time to make the migration as > painless as possible for our users which would require some proper testing and > possible a trial period. > > - Tobias > > [1] https://tools.ietf.org/html/rfc2104 > [2] https://cseweb.ucsd.edu/~mihir/papers/hmac-new.html > > > > > On 02/05/2020 00:03, Tobias Heider wrote: > > > On Fri, May 01, 2020 at 11:35:23PM +0200, Stephan Mending wrote: > > > > Hi *, > > > > > > > > this diff removes SHA1 as default transform for integrity algorithms. > > > > > > > > It's been broken long enough. Let's at least get rid of it in iked's > > > > defaults. > > > > > > > > SHA1 is officially broken since 2011 and there have been doubts about it > > > > since 2005. > > > > > > > > Though using SHA1 in combination with HAMC as pseudorandom function is > > > > perfectly fine as of today. > > > > > > > > > > > > OK? > > > Thank you for the diff. > > > > > > It's not as if we haven't thought about removing this transform, but > > > before > > > doing so we need to do some testing to ensure we don't break existing > > > setups. > > > See this mail from yesterday: > > > https://marc.info/?l=openbsd-tech&m=158828278120230&w=2 > > > > > > Also: the mentioned sha1 transform is also a HMAC construction and > > > technically > > > safe to use (for now), same as the PRF. > > > > > > > > > > > Index: parse.y > > > > =================================================================== > > > > RCS file: /cvs/src/sbin/iked/parse.y,v > > > > retrieving revision 1.99 > > > > diff -u -p -r1.99 parse.y > > > > --- parse.y 30 Apr 2020 21:11:13 -0000 1.99 > > > > +++ parse.y 1 May 2020 21:19:41 -0000 > > > > @@ -144,7 +144,6 @@ struct iked_transform ikev2_default_ike_ > > > > { IKEV2_XFORMTYPE_PRF, IKEV2_XFORMPRF_HMAC_SHA2_256 }, > > > > { IKEV2_XFORMTYPE_PRF, IKEV2_XFORMPRF_HMAC_SHA1 }, > > > > { IKEV2_XFORMTYPE_INTEGR, IKEV2_XFORMAUTH_HMAC_SHA2_256_128 }, > > > > - { IKEV2_XFORMTYPE_INTEGR, IKEV2_XFORMAUTH_HMAC_SHA1_96 }, > > > > { IKEV2_XFORMTYPE_DH, IKEV2_XFORMDH_CURVE25519 }, > > > > { IKEV2_XFORMTYPE_DH, IKEV2_XFORMDH_ECP_521 }, > > > > { IKEV2_XFORMTYPE_DH, IKEV2_XFORMDH_ECP_384 }, > > > > @@ -164,7 +163,6 @@ struct iked_transform ikev2_default_esp_ > > > > { IKEV2_XFORMTYPE_ENCR, IKEV2_XFORMENCR_AES_CBC, 192 }, > > > > { IKEV2_XFORMTYPE_ENCR, IKEV2_XFORMENCR_AES_CBC, 128 }, > > > > { IKEV2_XFORMTYPE_INTEGR, IKEV2_XFORMAUTH_HMAC_SHA2_256_128 }, > > > > - { IKEV2_XFORMTYPE_INTEGR, IKEV2_XFORMAUTH_HMAC_SHA1_96 }, > > > > { IKEV2_XFORMTYPE_ESN, IKEV2_XFORMESN_ESN }, > > > > { IKEV2_XFORMTYPE_ESN, IKEV2_XFORMESN_NONE }, > > > > { 0 } > > > > > > > > ndex: parse.y > > > > =================================================================== > > > > RCS file: /cvs/src/sbin/iked/parse.y,v > > > > retrieving revision 1.99 > > > > diff -u -p -r1.99 parse.y > > > > --- parse.y 30 Apr 2020 21:11:13 -0000 1.99 > > > > +++ parse.y 1 May 2020 21:19:41 -0000 > > > > @@ -144,7 +144,6 @@ struct iked_transform ikev2_default_ike_ > > > > { IKEV2_XFORMTYPE_PRF, IKEV2_XFORMPRF_HMAC_SHA2_256 }, > > > > { IKEV2_XFORMTYPE_PRF, IKEV2_XFORMPRF_HMAC_SHA1 }, > > > > { IKEV2_XFORMTYPE_INTEGR, IKEV2_XFORMAUTH_HMAC_SHA2_256_128 }, > > > > - { IKEV2_XFORMTYPE_INTEGR, IKEV2_XFORMAUTH_HMAC_SHA1_96 }, > > > > { IKEV2_XFORMTYPE_DH, IKEV2_XFORMDH_CURVE25519 }, > > > > { IKEV2_XFORMTYPE_DH, IKEV2_XFORMDH_ECP_521 }, > > > > { IKEV2_XFORMTYPE_DH, IKEV2_XFORMDH_ECP_384 }, > > > > @@ -164,7 +163,6 @@ struct iked_transform ikev2_default_esp_ > > > > { IKEV2_XFORMTYPE_ENCR, IKEV2_XFORMENCR_AES_CBC, 192 }, > > > > { IKEV2_XFORMTYPE_ENCR, IKEV2_XFORMENCR_AES_CBC, 128 }, > > > > { IKEV2_XFORMTYPE_INTEGR, IKEV2_XFORMAUTH_HMAC_SHA2_256_128 }, > > > > - { IKEV2_XFORMTYPE_INTEGR, IKEV2_XFORMAUTH_HMAC_SHA1_96 }, > > > > { IKEV2_XFORMTYPE_ESN, IKEV2_XFORMESN_ESN }, > > > > { IKEV2_XFORMTYPE_ESN, IKEV2_XFORMESN_NONE }, > > > > { 0 } > > >
