kernel/doc_changes From: IPsec <ipsec-boun...@ietf.org> on behalf of "ipsec-requ...@ietf.org" <ipsec-requ...@ietf.org> Reply-To: "ipsec@ietf.org" <ipsec@ietf.org> Date: Wednesday, July 29, 2020 at 3:01 PM To: "ipsec@ietf.org" <ipsec@ietf.org> Subject: [EXTERNAL] IPsec Digest, Vol 195, Issue 22
[EXTERNAL SENDER: This email originated from outside of Stratus Technologies. Do not click links or open attachments unless you recognize the sender and know the content is safe.] Send IPsec mailing list submissions to ipsec@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/ipsec<https://www.ietf.org/mailman/listinfo/ipsec> or, via email, send a message with subject or body 'help' to ipsec-requ...@ietf.org You can reach the person managing the list at ipsec-ow...@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of IPsec digest..." Today's Topics: 1. Re: Teaser for pitch talk at IETF 108 (Scott Fluhrer (sfluhrer)) 2. Re: Teaser for pitch talk at IETF 108 (Scott Fluhrer (sfluhrer)) ---------------------------------------------------------------------- Message: 1 Date: Wed, 29 Jul 2020 18:52:32 +0000 From: "Scott Fluhrer (sfluhrer)" <sfluh...@cisco.com> To: Tero Kivinen <kivi...@iki.fi>, Michael Rossberg <michael.rossb...@tu-ilmenau.de> Cc: Steffen Klassert <steffen.klass...@secunet.com>, "ipsec@ietf.org" <ipsec@ietf.org>, Valery Smyslov <smyslov.i...@gmail.com> Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 Message-ID: <bn7pr11mb2641f1962b9f19097ec2fd1fc1...@bn7pr11mb2641.namprd11.prod.outlook.com> Content-Type: text/plain; charset="utf-8" > -----Original Message----- > From: IPsec <ipsec-boun...@ietf.org> On Behalf Of Tero Kivinen > Sent: Wednesday, July 29, 2020 2:30 PM > To: Michael Rossberg <michael.rossb...@tu-ilmenau.de> > Cc: Steffen Klassert <steffen.klass...@secunet.com>; ipsec@ietf.org; Valery > > > Like written already: An unpredictable value of 32bit size is of no > > real value from a crypto point of view. One could simply guess the > > value and have a realistic chance of being right after a couple of > > thousand tries. I believe it is only in the standard, as with 64 bit > > sequence numbers there where 32 bits left; needing to be filled. > > I think it came from the NIST documents where it was called fixed field. The > idea was to make sure that even if someone accidently used same key twice > for two different SAs, this will not cause issues, as that fixed field is > going to > be unique anyways. No, RFC4106 (June 2005) predated 800-38D (November 2007) by over two years. Instead, it was inserted to harden the system against multitarget attacks, as I said earlier... ------------------------------ Message: 2 Date: Wed, 29 Jul 2020 18:54:19 +0000 From: "Scott Fluhrer (sfluhrer)" <sfluh...@cisco.com> To: Michael Rossberg <michael.rossb...@tu-ilmenau.de> Cc: ipsecme mailing list <ipsec@ietf.org> Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 Message-ID: <bn7pr11mb2641a13a94b9925d6d5f3eb2c1...@bn7pr11mb2641.namprd11.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" > -----Original Message----- > From: Michael Rossberg <michael.rossb...@tu-ilmenau.de> > Sent: Wednesday, July 29, 2020 2:35 PM > To: Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> > Cc: ipsecme mailing list <ipsec@ietf.org> > Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 > > > > > Actually, it does add value from a crypto point of view, at least from a > specific attack. In a multitarget attack, that is, an attack where we assume > that the attacker has encrypted packets from a large number of SAs, and his > goal is to recover the keys for any one of the encrypted packets, here is what > the attacker can do (assuming GCM or ChaCha20-Poly1305); if he has packet > encrypted with each SA with the same nonce, he can guess a key, and > generate the internal GCM/ChaCha20 keystream based on that key/nonce > combination. He can then scan through all the packets to see if the > encryption makes sense (or the ICV tag works out); this can be done far > faster than checking each packet individually. Assuming the packets are > encrypted with AES-128, and the attacker has packets from 2**L SAs, then > against this attack, we have only 128-L bits of security. > > > > By including 32 bits of unpredictable values, we make this attack 4 billion > times harder, and for AES-128, that would give us 160-L bits of security. This > doesn't actually add any security against attacks against a single SA, and the > salt doesn't actually need to be secret. > > Thanks for clarification. I guess I have been thinking too SA centric. > In fact we always discussed AES-256 only. > > Do you agree that starting the window/sender IDs with random offsets > would fix this weakness? Yes, it would address this weakness. On the other hand, with AES-256, you don't really need this anyways... ------------------------------ Subject: Digest Footer _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec<https://www.ietf.org/mailman/listinfo/ipsec> ------------------------------ End of IPsec Digest, Vol 195, Issue 22 **************************************
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
