Subject: Re: [IPsec] [EXTERNAL] IPsec Digest, Vol 195, Issue 22

From: "Robinson, Herbie" <[email-masked]>
Date: Wed, 29 Jul 2020 19:19:21 +0000

kernel/doc_changes

From: IPsec <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Date: Wednesday, July 29, 2020 at 3:01 PM
To: "[email-masked]" <[email-masked]>
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
[email-masked]

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
[email-masked]

You can reach the person managing the list at
[email-masked]

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)" <[email-masked]>
To: Tero Kivinen <[email-masked]>, Michael Rossberg
<[email-masked]>
Cc: Steffen Klassert <[email-masked]>, "[email-masked]"
<[email-masked]>, Valery Smyslov <[email-masked]>
Subject: Re: [IPsec] Teaser for pitch talk at IETF 108
Message-ID:
<[email-masked]>

Content-Type: text/plain; charset="utf-8"

> -----Original Message-----
> From: IPsec <[email-masked]> On Behalf Of Tero Kivinen
> Sent: Wednesday, July 29, 2020 2:30 PM
> To: Michael Rossberg <[email-masked]>
> Cc: Steffen Klassert <[email-masked]>; [email-masked]; 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)" <[email-masked]>
To: Michael Rossberg <[email-masked]>
Cc: ipsecme mailing list <[email-masked]>
Subject: Re: [IPsec] Teaser for pitch talk at IETF 108
Message-ID:
<[email-masked]>

Content-Type: text/plain; charset="us-ascii"

> -----Original Message-----
> From: Michael Rossberg <[email-masked]>
> Sent: Wednesday, July 29, 2020 2:35 PM
> To: Scott Fluhrer (sfluhrer) <[email-masked]>
> Cc: ipsecme mailing list <[email-masked]>
> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec<https://www.ietf.org/mailman/listinfo/ipsec>

------------------------------

End of IPsec Digest, Vol 195, Issue 22
**************************************