[ropman76]

I can understand about being suspicious of the NSA after the whole Dual_EC_DRBG fiasco. However these designs are not unknown throughout the industry (ARX having gotten some heat lately from the Keccak people). Is there some technical reasons these designs should be disallowed aside from "We don't like the NSA".

[dfox]

My technical (but probably mostly insignificant and unexploitable) issue with speck/simon is with the key schedule, which has somewhat slow diffussion with key length >2 words.

[dfox]

Also the key schedule is trivially invertible (I intended to include that fact in my original comment, but wasn't sure of that, now I'm).

On the other hand this seems like deliberate design choice in order to remove any unexplained constants from the design (the counter in the key schedule seems "explainable"). Alternative with the same design would be to supply the key into the key schedule as subkeys (cyclically or so), which would then mean that initial state is some kind of unexplained constant (there is good reason why {0,0} is not good initial state and given the fact that it comes from NSA any other value will seem suspect)

Edit: the fact that key schedule is invertible does not decrease the security as long as it is used as block cipher (in fact on this level of analysis it slightly increases the confidence in the design as long as it is only meant as block cipher). On the other hand it means that insecure constructions of hash function from block cipher are probably not only theoretically insecure, but readily breakable by NSA. (I wouldn't be surprised if this was the motivation of NSA, because for many IoT applications one is more interested in authentication than in confidentiality)

[kbutler]

Do you buy a shiny new car from a dealer who knowingly sold you a lemon?

What record of inspections and promises would convince you to buy?

The NSA provides that record https://eprint.iacr.org/2017/560.pdf

We currently know of no technical reason to reject the ciphers.