I must be misunderstanding something - why would a standards group (or anyone with a functioning brain) accept a "secure" cipher standard developed by an organization who's foundation in part is to be able to break encrypted communications?

I'm not qualified to challenge Tomer Ashur's analysis of Speck and Simon, and I don't think ISO has any business standardizing those algorithms, so Ashur and I reach the same conclusion about the NSA ciphers.

But I think Ashur is overstating his case.

Ashur repeatedly alludes to the potential for backdoors in Simon and Speck, but never really engages that subject in any detail. That's unsurprising, because the NSA ciphers are both extremely simple, streamlined block cipher designs. There isn't a lot of room in them to insert a "backdoor". Ashur notes that these ciphers were sponsored by the same person that sponsored Dual EC. But Dual EC was self-evidently compatible with backdoors (that was, weirdly, a reason some people --- myself included! I was wrong! --- thought it couldn't be --- the tradecraft was just too clumsy). Dual EC is a PKRNG; embedded in the design is a public key for which we were expected to trust no private key was known. You can't really say that about Speck, or even Simon with its U, V, and W matrices.

Could you deliberately weaken something pretty close to a trivial ARX cipher? I'm sure you could. But NSA doesn't want arbitrary weaknesses; it wants NOBUS backdoors, where it gets cryptographic protection for its own access. It's hard to see how you'd get there with a design as simple as Simon's.

As with previous NSA cipher debates, Ashur takes NSA to task for low security margins. Why so few rounds? Why such simplistic designs? Well, that should be easy to answer: Simon and Speck are "lightweight" ciphers intended for embedded designs. They come with variants with 32-bit block sizes! This also addresses a concern I saw on this HN thread, that NSA was trying to surreptitiously replace AES with a breakable cipher. No, they're not. Even if these had been standardized, you shouldn't be using them; they have a highly specific purpose.

I think the background to this drama is mostly political. I get the sense that NSA has never really complied with the norms of academic cryptography (they're openly derisive of it). Standards groups have, in the past, given some deference to NSA's "alternative norms". That ended with Dual EC, and Simon and Speck are the first post-Dual EC ciphers where NSA is being told they're going to have to follow academic cryptography's norms. Good!

But I'd be careful reaching any conclusions past that.

Corrections welcome!

From the email:

"So I think that as a first step, no-encryption is better than using Speck."

Thats a damned near heretical position to take as a cryptographer, but Tomer did his homework and has done nothing less than nailed his 95 theses to the door of the church of the NSA. ISO is passing on Speck for a very good reason: The NSA still believes it can cash its unapproachable arrogance with Speck in a shroud of paternal intellectualism that Edward Snowden ripped the mask off years ago. The NSA forgets itself. The ISO WG2 is headed by no less than Berenstein and Paillier. They are not the fucking peanut gallery to be fecklessly dismissed with bureaucratic elucidations such as "i will not answer that question."

Can someone point me to a concrete use case for speck? As far as I understand, Speck is designed to use less resources than AES. However, even on very constrained devices I believe one needs at worst hundreds of kB of RAM and even a low end micro controller should be able to deliver 1 kb/s encrypted bandwith. So I have a hard time to think of any application were a chip that is designed now does not have enough power to encrypt using AES, but has a need for somewhat high bandwidth communication.

Just the heritage and reputation of the NSA in such matters should be enough to avoid using NSA ciphers.

You don’t go back to a restaurant if you see someone spitting on your food.

It seems to me that the NSA has someone who came up with this cipher, didn't justify it very well, and then pushed hard for it. The NSA's reputation is so bad that this just won't fly, and unless they justify themselves then they just won't get a look in.

Which is fine really, because it's no different to anyone else proposing a cipher to the ISO committee. In this case, the issue could well be that the NSA tried to use it's preexisting muscle to shove through their standard without a proper design and rationale document.

Of course, it could also be the case that they deliberately weakened their own cipher. Either way, it's not a good look.

There's some missing context if you read just Dr. Ashur's email and not the rest of the thread. The reason I added Speck to the Linux kernel's crypto API is unrelated to the proposed/rejected ISO standard, but rather because Speck128-XTS is being considered for disk/file encryption on low-end Android devices. This is a very important use case which has, regrettably, received much less attention than it deserves. Currently the only options allowed to Android vendors are AES-CBC-ESSIV and AES-XTS, which are much too slow on low-end processors, especially when AES instructions (ARM CE) are absent. Therefore, currently encryption isn't mandatory until 50+ MB/s AES performance. This disproportionately penalizes people who can't afford the higher end devices, who end up with no encryption. This is wrong: encryption should be for everyone.

Some have argued this problem will go away with new CPUs that can do AES faster. This is probably the "right" solution. But in practice this will require ARM CE (AES instructions). Unfortunately, this is an optional processor extension and it will be _at least_ several years before all relevant processors have it, if they ever all do. Note that this requires moving the whole industry, including not just device vendors but also the SoC and processor vendors they rely on; and devices are usually planned years in advance, with price, performance, and power efficiency being the main concerns, rather than encryption. So, it is tough and very slow, and a software solution could be in place much sooner. Plus, in any case it would be valuable to have an efficient cipher in software, in case a weakness is found in AES.

Why Speck128-XTS? Well, after extensive research it actually seems to be the best option from a technical perspective, considering many security and performance aspects; see e.g. https://www.spinics.net/lists/linux-crypto/msg33000.html for details. Again, this is specifically for the disk/file encryption use case on processors without AES instructions. The fact that there isn't a less controversial option is really a consequence of the current state of the art, and not (as far as I can tell) just because we haven't done our homework. Most critically, in the disk/file encryption use case there is no space to store a nonce; thus, stream ciphers such as ChaCha20 are inappropriate, as IVs are reused when data is overwritten, and with flash storage and/or f2fs an attacker may even be able to recover from the "disk" multiple versions of data written to a particular logical block offset, even after only a single point-in-time offline compromise. Stream ciphers fail much more catastrophically than XTS here. (It's unfortunate how many "crypto people" seem to be unfamiliar with the problems and constraints of practical disk encryption.)

Of course, even with kernel support available, no Android device will actually use Speck until it is actually added to the CDD. That may or may not actually happen, and isn't my call. Given the increased level of controversy, it may very well be punted on for this year's Android release. Still, the alternative of no encryption is not okay, so in parallel we've also designed a new length-preserving encryption construction ("HPolyC") based on XChaCha and Poly1305, which will be published soon. Hopefully the wider crypto community will also step up to help review this construction and even publish other new software-optimized disk encryption algorithms, which are greatly needed. (And separately, perhaps the Speck team can better rise to the occasion of the, arguably disproportional but perhaps well-deserved, level of scrutity they are receiving and really set the gold standard for crypto proposals. Although I still find their latest paper to be of higher quality than you find from other designers, it evidently still has room for improvement; and crypto needs to be held to exceptionally high standards in any case.)

The headline should be "Ashur advocates that it is better that a device be unencrypted, than encrypted with Speck". Ashur argues for that position and you can read his reasoning in detail in the above link, but that's the question you want to be thinking about when thinking about this.

Fool me once, same on you. Fool me twice ...

Why are they changing?

There's a common theme in the comment section about the likelihood of a backdoor.

There's really no telling. This kind of capability is definitely within the means of the NSA - so the question is more about one of intent.

In this case, the decision makers at the ISO determined that not enough information had been made available for them to determine the intent. Significant technical questions could/would not be answered by NSA in a satisfactory way.

The ISO committee also believes that the problem is likely to correct itself in a short time window without the need for an additional, if suspicious, standard. They would rather not have to do the legwork to solve a non-problem to acquire and have to deal with a possibly suboptimal or backdoored cipher.

undefined

It seems like everyone wants a set of keys to the world.

>So I think that as a first step, no-encryption is better than using Speck

Yeah so the guy just throws everything out of the window.

So just after ISO rejected Simon and Speck, NIST is announcing new crypto competition just for algorithms like Simon and Speck, how convenient for the NSA, lets see how it goes, maybe this time they will be able to shove it just like DUAL_EC:

"NIST Issues First Call for ‘Lightweight Cryptography’ to Protect Small Electronics"

https://www.nist.gov/news-events/news/2018/04/nist-issues-fi...