[Ach] Cipher-Order: AES128/AES256 - was: Secure E-Mail Transport based on DNSSec/TLSA/DANE

[ianG]

On 9/11/2015 12:27 pm, Alexander Wuerstlein wrote:
> On 2015-11-09T13:06, Terje Elde <terje at elde.net> wrote:
>> There seems to be an implied “the math is solid, therefor AES the algoritm is secure, therefore all uses of AES is secure”.  The first conclusion is solid, but not the second.
>
> Also, "the math" being non-solid might not stem from a problem that is
> shared between AES and Camellia but from their differences. E.g. magic
> constants used in both Ciphers might differ sufficiently in certain
> aspects to make one vulnerable, while the other remains solid. For a
> historical example of what I mean, see the NSA's choice of s-boxes for
> DES.


NSA's choice of the s-boxes improved the strength of them, but the 
choice of 56 bits key was designed to limit the strength.  Historically, 
there is somewhat of a pattern that the NSA prefers to improve the 
crypto but weaken the inputs.  e.g., choosing dodgy primes versus 
Skipjack which was a very elegant 80 bit cipher.


> Disclaimer: I'm not a mathematician and certainly not knowledgable
> enough to make any determination on the matter. But from the extremely
> long time it takes to establish Ciphers, Hashes or other cryptographic
> building blocks out there, I think one needs to pre-establish at least
> one alternative for everything so an alternative is available, should
> things go south. Camellia might not be the ideal AES alternative, but
> its the only one with any current support in protocols. As soon as there
> is another Cipher that can be used, Camellia could be phased out for
> being to similar to AES, but not before.


The mistake that people make typically is to think that ciphers are 
interchangeable.  Although the engineering can be organised that way, 
typically we are better off designing in alignment with the protocol - 
the designer should be balancing the cipher suite across the board, and 
to needs and purposes.  So, this view has it that when a new version of 
the protocol turns up, a new ciphersuite should come with it.  The old 
one should be thrown away.


> For an example of how things might break, just imagine a situation were
> SHA-1 hadn't been introduced as an MD5-replacement, or SHA-2 as a
> replacement for SHA-1. Its still all happening very slowly, but at least
> the alternative is available.


This is a bad example.  SHA-2 was available around 2000 or so, SHA1 in 
1996 from memory.  If a protocol was still using MD5 around now in a 
vulnerable fashion, then it is negligent.  Negligence is not a thing 
that can be solved with additional algorithms.

As a case in point it is only recently - in the last 2 years or so as 
far as I can see - that IETF WGs have started to think about how to 
reduce the algorithm set.

The problem we face is that engineers are peddling the mantra that 
algorithmic agility is a good idea - it is only now that they are being 
forced to come up with some good reasons for it.  Hint - there aren't any ;)

iang