[Cryptography] [cryptography] NIST Workshop on Elliptic Curve Cryptography Standards

[ianG]

On 13/05/2015 21:46 pm, dj at deadhat.com wrote:
>>
>>
>> On 05/12/2015 05:00 PM, dj at deadhat.com wrote:
>>
>>> Alas, the world isn't just the internet and smart cards. We are throwing
>>> crypto on silicon as fast as we can to address the many threats to
>>> computer hardware. No one block size is correct.
>>
>> Well, maybe...
>>
>> How about "The block size is exactly the same as the message
>> size no matter what the message size happens to be?"
>>
>
> I'm coming from a place where many data sizes are fixed. I.E. Data fields
> on chip. But they might be 256 or 512 bits instead of 64 or 128. So my
> world view may be different.


This is the prevailing view in software as well, but it's still wrong. 
Most of the old timers here also come from a world when hardware 
dictated many concerns.  It's still the prevailing view in software for 
protocol negotiation that hardware enforces the basic numbers, most 
protocols are still using hardware notions of "32 bit integers" and so 
forth, without understanding that we don't need to do that anymore 
inside protocols, and doing so results in complication that leads to 
insecurity.

In short, any protocol that sends a "32 bit hardware number" is out of date.


>> I know, it's a laughable idea when talking about "lightweight"
>> cryptography.  I can't think of any way to actually do it that
>> wouldn't take at least LogN times longer than a standard block
>> cipher with fixed-length blocks.


Mmmphh... SHA3... sponge... AE mode... can't wait...


>> And the idea of encrypting a
>> "stream" is right out unless you have a higher level of the
>> protocol breaking the stream up into packets of known size,
>> in which case you have a standard block cipher again.


That's how stream ciphers such as Chacha/Salsa work - they are block 
ciphers underneath with a stream API.  I do not know if that has changed 
for CAESAR, but maybe, maybe.

It's also how my software works - higher layer delivers datagrams 
throughout, but when it comes to sending them over UDP, it breaks them 
up and delivers them in smaller packets so as to be assembled at the 
other side.  This is because some of the datagrams are huge - photos, 
which can be up to a meg, say - but we don't reliably know which ones 
are huge beforehand.  It's also a tunable because some networks handle 
small packets (older networks are limited to 1500 bytes) and some 
networks handle up to jumbo UDP packets (64k), but there are also 
networks (cell) that top out between 20-40k.

But in short:  application software SHOULD treat datagrams as being of 
infinite size, and network delivery software SHOULD have a facility to 
break up MonsterGrams into BabyGrams.



> The published lightweight ciphers are interesting in that their real
> design feature is they disperse and non-linearize more per gate than say
> AES. In hardware this lets you do more with fewer gates. It doesn't
> dictate the key or block size of the cipher at all. Yes under the
> lightweight title, they self limit themselves to small block and key
> sizes.
>
>> But in a brute kind of way, it's very interesting for just
>> plain freezing out most  of the attack methodologies I'm aware
>> of.
>>
>> No block boundaries inside the message, and every bit of the
>> ciphertext depending on every bit of the plaintext, means
>> entire classes of attacks just don't have anything to work
>> with.
>
> I would like such a thing to exist. Do you have an algorithm handy? The
> closest thing I can think of is format preserving encryption, like
> Rogaway's Sometimes Recurse Shuffle. That can work on arbitrary string
> sizes.
>>
>> It's a random idea.  It may have occurred to me due to lack
>> of sleep, or because I'd been looking at C++ template code
>> for a block cipher that takes block size as a parameter.
>>
>> 				Bear
>
> That would be nice, but hardware implementation parameters are usually
> tied to the size required for the application. So probably more of a
> software thing, which isn't my gig.


Is this world about hardware talking to hardware?  If so, why should the 
software world care?

If the world of hardware requires to talk the software world, what is 
the balance whereby we make things worse for software, while making 
things fast for (some) hardware buyers?

It's clear that in the hardware world, the economic incentives are much 
more clearly aligned.  People actually get paid for each unit delivered! 
  But it's also the case that hardware world pushing a more efficient 
solution - for them - can create externalities that cause costs for the 
software world.


> Orthogonally I have been thinking of ciphers taking the number of rounds
> as a parameter. Then use that in protocol negotiation. Algorithm gets
> weak, increase the rounds. It beats undeleteable cipher options.


That might make sense if there was a way to communicate the extra number 
of rounds needed.  But in practice, most of the experience we've had has 
been to upgrade the entire software suite.  In which case it would be 
just as easy to up the protocol number to a better algorithm.

There's something intellectually fraudulent about predicting that in 10 
years we will need to upgrade the algorithm from X to Y, but we won't 
need to replace the rest of the software.  Experience shows that 9 out 
of 10 security blunders are with the protocol, not with the algorithms, 
so let's deal with the big cases first, and then we can also sweep up 
the occasional algorithm weakness at the same time.


> I spoke with a block cipher designer about this and his argument against
> was that if you can run the same data and key through with a different
> number of rounds, it's trivial to break. However I see this as just
> another constraint, like 'never use the same key and IV twice'. Never use
> the same key and iteration count twice.


Right, it's not as if you're providing a dynamic capability.  Although 
there is the obvious complexity argument leading to a downgrade attack.



iang