Re: [IPsec] Teaser for pitch talk at IETF 108

2020-07-30 Thread Valery Smyslov
Hi Scott,

> > > 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.

Thank you for the good explanation.

> > 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...

What's your opinion - if we consider quantum computers (so that the real 
strength of AES-256 is 128 bit),
then does addition of unpredicted salt to AES-256 make sense?

Regards,
Valery.

> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


Re: [IPsec] Teaser for pitch talk at IETF 108

2020-07-30 Thread Scott Fluhrer (sfluhrer)
> -Original Message-
> From: Valery Smyslov 
> Sent: Thursday, July 30, 2020 4:07 AM
> To: Scott Fluhrer (sfluhrer) ; 'Michael Rossberg'
> 
> Cc: 'ipsecme mailing list' 
> Subject: RE: [IPsec] Teaser for pitch talk at IETF 108
> 
> Hi Scott,
> 
> > > > 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.
> 
> Thank you for the good explanation.
> 
> > > 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...
> 
> What's your opinion - if we consider quantum computers (so that the real
> strength of AES-256 is 128 bit), then does addition of unpredicted salt to 
> AES-
> 256 make sense?

That is a surprisingly deep question; however since you specified "my opinion", 
I would say "it doesn't appear to be needed" (but wouldn't hurt anything)

Here are some of the complexities (and unknown factors):

- We have Grover's algorithm (which is an algorithm that runs on a Quantum 
Computer that supposedly does "key halving" of symmetric ciphers; that is, it 
searches for an n bit key in 2*(n/2) time)

- However, if we insert the assumption of bounded quantum circuit depth; that 
is, we insist that we get the result of the search quickly, say, within 1000 
years, then the attacker using Grover's algorithm needs to significantly more 
computation resources to search for a large key, that is, the level of security 
is significantly higher then what "halve the key" would indicate.  With a 
conventional computer, we can perform parallel searches without increasing the 
cost (total amount of computation performed); with Grover's, performing the 
search in parallel cuts into the advantage that Grover's brings to the table.

- How expensive is a multitarget comparison for a Quantum Computer (as opposed 
to a conventional one, where it is cheap)?  After all, the entire point of this 
effort is to use a multitarget comparison to search against a large number of 
targets at once.  This is relevant because if it is of significant cost, it 
would require more computational resources, which against, would effectively 
raise the security level achieved.  I did glance at a similar scenario a while 
back; I came to the conclusion that a multitarget version of Grover's would cut 
circa 10-12 bits from the security level (by searching against circa a million 
targets - increasing the targets beyond that started to increase the cost most 
than just adding additional parallel searchers); however this was a fairly 
informal study, and I never published it.

- How costly (in terms of performance and expense) is a Quantum Gate (of 
various different flavors) compared to conventional gates?  This is a constant 
factor; however if it is large constant (e.g. a Quantum Gate is as expensive as 
one billion conventional gates), well, a factor of 2**30 really can't be 
ignored in practice.

However, when I plug in plausible numbers to the above unknowns (especially the 
last; for the previous, we do have some reasonable guesses), I still get that a 
quantum multicollision attack against AES-256 is still not feasible...

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


Re: [IPsec] multiple windows need multiple SPIs

2020-07-30 Thread William Allen Simpson

On 7/24/20 2:28 PM, William Allen Simpson wrote:

Therefore, I'd recommend that IPsec instead implement a block of related SPIs.
Each SPI should have its unique session-key as usual, but all would have the
same next protocol header and TCP/UDP port associated with the same flow.

In the Photuris Extended Attributes internet-draft circa July 1997, we defined
the SPI-Block option.  Without the overhead of multiple negotiations, a single
exchange could generate a list of many related SPIs.

You could send on several SPIs concurrently.


Although there has been some pushback, have we agreed that instead of multiple
windows (however defined), a more general solution is multiple SPIs?

Who is going to write the SPI block/group extension for IKEv2?

Would it be best to add to an existing draft already in the pipeline?

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


[IPsec] leading versus trailing ICV

2020-07-30 Thread William Allen Simpson

The comments thus far seem to be mixed.  This is a perennial topic.
We spent much time on it in PIPE/SIPP/IPv6.

We agreed on leading for AH and trailing for ESP.

When I wrote the KA9Q NOS code implementing Van Jacobson's packet
buffers that eventually was ported to Linux by Alan Cox, the code knew
it had an incoming Ethernet or PPP frame, and offset the head on a
16-bit or 32-bit boundary as needed with enough space at the tail for
all trailing bytes.  The IP header was always on a 64-bit boundary.
Hopefully, that code is still present.

In modern CPUs, there's always an issue with cache lines.  But for a
parallel implementation, it really isn't going to matter.  The CPU
that finishes last and needs to check the ICV isn't particularly
likely to be the CPU that processed the initial header anyway.

As a matter of historical record, this was also a long debate for TCP.
The default is leading, and there is a TCP option for trailing checksum.

Might it be a non-default option negotiated per SPI?

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec