30 ms·

Linux Cryptography: Speck's real standing with the academic community

230 points by zx2c4 8y ago

tptacek 8y ago
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!
- consp 8y ago
  > Well, that should be easy to answer: Simon and Speck are "lightweight" ciphers intended for embedded designs. You are providing rationale which the NSA is, according to Ashur, unable to provide in the design documentation/rationale. So I think you are missing the point he's trying to make: If you can't tell me why and are doing hand waving you are either incompetent or deliberately dismissive in which case you should not be trusted.
  - dfox 8y ago
    I think that part of the issue is that people (probably including the WG2) hear NSA and then ignore the lightweight part. To some extent the lightweightness implies lower standard for the security margins. This is in this case compounded by the fact that WG2 had thrown out most of the truly useful NSA recommended Speck/Simon parameter combinations (things like 32b blocks) even before the current turmoil on the basis that they obviously provide insufficient level of security, which is obviously true for general purpose block cipher, but not for lightweight ("IoT-ish" ;)) applications. On the other hand I somewhat wonder what motivation exactly NSA had for trying to push these algorithms through ISO.
    - notveryrational 8y ago
      No. They hear the lightweight part. The author clearly understands this. It's the actual designs of the cipher, security margins, motivations for the key schedule, and others he has an issue with. The issues include lies and misleading omissions in publications.
  - tptacek 8y ago
    No, if you re-read my first sentence, you'll see that I'm not suggesting we should trust NSA.
- bo1024 8y ago
  - I wonder how the NSA's compute resources translate into an inherent advantage over academics in terms of ability to break these codes. Especially if we are talking about pushing the limits of small margins. - I don't think it's fair to say the background is "political" if NSA is currently not cooperating with the process. Calling it political makes it sound like their treatment is a function of the broader context or history, but it sounds like they are being treated fairly given how they have acted in this situation.
brian_herman 8y ago
Why are they changing?
- lowry 8y ago
  Because Speck is said to be more performant than AES.This is discussed in the mail.
  - mtgx 8y ago
    Why not use ChaCha20? I believe it's twice as fast, at least in software.
    - dfox 8y ago
      Because ChaCha20's block migh not even fit into memory on platforms that is Speck/Simon meant for. The question should be: Why not use XTEA or RC5/6. And the answer (ignoring the NSA and it's opaqueness) is that Speck (in its reference implementation form) is slightly faster than both XTEA and RC5 and can be trivially implemented such that it is twice as fast and also uses 64b words in 128b block size variants which on typical 64b platforms leads to another essentially free 2x speedup. (Not that it makes sense to use Speck for bulk encryption on typical 64b CPU) On the other hand team related to DJB published algorithm called Gimli (https://gimli.cr.yp.to/ https://gimli.cr.yp.to/) whis is essentially narrower ChaCha 20 transformation with intentionally slow diffusion as to fit onto registers of register-constrained CPUs (like Thumb) that is intended as Keccak-style sponge permutation. On the other hand in my opinion authors' paper and slides also have similar issue as what part of the original article criticizes NSA for, the security arguments for Gimli are considerably better than NSA's arguably non-existent ones but then the bigest issue I intuitively have with Speck is slow (and somewhat one-way) diffussion of the key schedule and Gimli's 4-round function is somewhat similar or even worse in this manner (although it does not have the "onewayness", for lack of a better word).
      - ciphergoth 8y ago
        We need a drop-in replacement for AES, and Gimli doesn't have a 128-bit block size.
setquk 8y ago
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.
- mindslight 8y ago
  No, no. You don't understand. That's the other side of the kitchen that was spitting in people's food last week. Your friendly waiter obviously got your food from the clean side this week! And it's clearly offensive to even ask whether your plate could have gotten near the known spitters, which is why he refuses to answer.
  - zer00eyz 8y ago
    LOL -- you didn't read the article did you? > The NSA (in particular, the exact same person who previously promoted DUAL_EC in ISO) proposed to include Simon & Speck The author is pointing out that the same person spit in your food before.
    - vengefulduck 8y ago
      I'm nearly certain the parent commenter was being sarcastic.
      - zer00eyz 8y ago
        The original analogy was good - the commenter diminishes it by trying to portray the NSA person responsible as a different actor. This is the same person who has burned the community before. That old adage about fooling someone once applies here, and for good reason.
        mindslight 8y ago
        Focusing responsibility on the individual NSA agent is a red herring - the entire organization is the hostile party. Would you judge the situation differently if it were a different operative pushing Speck? The asset themselves probably isn't even privy to the actual existence of a backdoor, due to compartmentalization and for the sake of their own sincerity. They're more akin to the waiter. A waiter that doesn't want to think too hard about whether your food was spit in, as their job depends on not knowing. How are you doing today? smile
johnflan 8y ago
It seems like everyone wants a set of keys to the world.
PerilousD 8y ago
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?
- _wmd 8y ago
  Because if it is possible to ascertain they are acting in good faith, there is no better collection of minds, money and official secrets suited to the task of designing a robust cipher. The problem is that it's somewhere between difficult and impossible to ascertain whether they are acting in good faith.
  - api 8y ago
    There is also no real need. Reduced round Salsa/ChaCha (12 rounds) is tiny and likely fast enough for the quantities of data any microcontroller would need to push over a network. Those ciphers were designed in the open and have been heavily analyzed with no attacks known against more than a few rounds. Why not use those?
    - makomk 8y ago
      In general that's true, but if I understood the discussion correctly the reason Speck was being considered here is because this specific application needed a fast block cipher - stream ciphers like Salsa/ChaCha were not suitable.
  - craftyguy 8y ago
    Their recent behavior suggests that they are not acting in good faith and, even if they were, the "between difficult and impossible to ascertain" bit should mean that they are, by default, not trustworthy.
    - _wmd 8y ago
      It's important to remember the desired goal - secure cryptography, and in that case even if the NSA is a known-bad actor, they might still be the best option to achieve an optimal outcome. There is a name for the kind of table below but I have forgotten it. Essentially on the balance of outcomes, a situation (of engineered choices, of course!) where the NSA is involved still produces, given unknown factors, a potentially better outcome than a situation where the NSA is excluded. Bad = 0.1, Fair = 0.5, Excellent = 1.0 Cipher Author | Known Weak | Security | Likelihood | Security*Likelihood | Academia | No | Excellent | Bad | 0.1 Academia | Nationally | Fair | Fair | 0.25 Academia | Internationally | BAD | Fair | 0.05 NSA | No | Excellent | Fair | 0.5 NSA | Nationally | Fair | Fair | 0.25 NSA | Internationally | BAD | Bad | 0.01 SUM(academia) = 0.31 SUM(nsa) = 0.76 (Does anyone know what this kind of table is called? Can someone do a version that makes more sense? It's 4am and quite a few beers were involved :))
emilfihlman 8y ago
>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.
- bhouston 8y ago
  He is only throwing out Speck and saying it is worse than no-encryption.
  - emilfihlman 8y ago
    He's throwing out all of his reputation with that claim also. He should not hold any Senior Researcher positions if this message is anything to go by.
    - larkeith 8y ago
      Could you please address and refute his reasoning (probided in the prior paragraph), so as to encourage discussion?
      - drostie 8y ago
        Oh there are so many reasons. The easiest is the adoption problem, the same as hit HTTPS: at least 40% of top websites are still unencrypted even after a massive push from browsers to muscle them into submission; compare to the fact that with no massive push 90% of the ones that do support HTTPS don’t support SSL (they only support TLS, the old standard having severe security flaws). In other words there are concrete numbers to back up the point that when an algorithm is learned to be broken, it is easy to convince panicking folks to upgrade it. But when it simply doesn't exist and hasn't ever, it is harder to convince folks that they need it. Even more to the point, attacks do not exist in isolation and there is no “secure/insecure” dichotomy. You can see this with AES where the AES-256 key schedule is much weaker than the AES-192 key schedule, but the place where this really shines is in related-key attacks, where AES-192 has about twice the bit-strength of AES-256. Does that mean you should switch over? Well, probably not: related key attacks are structurally harder to pull off. The qualitative differences make comparison hard. Probably if the NSA had an exploit for Speck for example, it would take the form of "steal the device running Speck for an hour to get some carefully chosen challenge-response pairs, return it back to the user, budget a day or two of time on the supercomputer to look for patterns in that data, and finally you can recover the key." (I say this in part because it’s hard to hide backdoors in symmetric crypto.) Many applications would be more secure than nothing if that were the only applicable threat model. But even quantitatively, in theory security is not a binary. It's much closer to a dollar amount: here is how much it costs to launch attacks against this system. And $0 on this scale is certainly lower than a serious vulnerability at the $100,000 level. Basically this is a solid argument why you should not roll your own crypto but those arguments are categorically not transferable to crypto whose specifications are known openly and subjects of active cryptanalysis.
MrBingley 8y ago
Fool me once, same on you. Fool me twice ...
- MaxBarraclough 8y ago
  I know this one - that's a replay attack, right?
- chris_wot 8y ago
  That's not the saying. Its, "Fool me once, shame on — shame on you. Fool me — you can't get fooled again." It's an old Tennessee saying. Or I think it's in Tennessee, I know it's in Texas somewhere...
john8899 8y ago
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-first-call-lightweight-cryptography-protect-small-electronics https://www.nist.gov/news-events/news/2018/04/nist-issues-fi...
- tptacek 8y ago
  Since it's unlikely that Simon and Speck will win this competition, given that there are other credible lightweight designs which will probably be better-analyzed since they're open, it's hard for me to see this as anything but a good thing.
chris_wot 8y ago
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.
yk 8y ago
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.
- arghwhat 8y ago
  AES is extremely slow when implemented in software. Many mobile and embedded processors do not have AES hardware acceleration. With hardware acceleration, AES becomes crazy fast, but that's because hard silicon can do crazy things. However, Speck does not have a user-case, as there are sensible options available. If you don't have AES hardware acceleration, ChaCha20 can get very close in software, which is one of the primary reasons ChaCha20Poly1305 is being adopted as a common TLS cipher suite. Cloudflare has some nice benchmarks on it.
  - the8472 8y ago
    The linked mail talks about XTS constructions, so the thread is about block encryption commonly used in disk encryption schemes. They also mention that they'd have to handroll such a scheme with ChaCha. I assume that Speck offers a native wide block mode which would make a better candidate for software disk encryption if it weren't for the backdoor concerns.
    - arghwhat 8y ago
      That is fair, but that is by no means an argument for Speck, but instead just an argument for a block mode cipher. What they would need to do would be to find a different sensible block mode cipher, rolling a cipher-text stealing operation mode like XTS for a stream cipher (which is not that complicated, although one should do their homework first), or using a construct to convert a stream cipher to a block mode cipher so it can use XTS directly (which is possible, but care must be taken). #2 would probably be best. I am not sure if it a trend, but I seem to mostly see new stream ciphers popping up, so this solution is likely more sensible.
deleted 8y ago
[deleted]
notveryrational 8y ago
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.
nimbius 8y ago
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."
- _hl_ 8y ago
  I'm normally not the type to embark on wild conspiracy theories, but in this case I don't think the NSA actually believed it could push Speck into the ISO. The way Tomer depicts it, it sounds as if they almost wanted the process to fail; they made it a point to behave especially shadily. Perhaps, and here begins my wildy unfounded speculation, perhaps Speck was an attempt at setting a carefully crafted example of how the NSA pushes a compromised algorithm in an attempt to lower the expectations of shady NSA operations - thus making their next, real attempt more credible. But who knows.
  - api 8y ago
    Possible but unlikely. Bureaucracies generally aren't that subtile. It is a good idea to be paranoid in crypto though. If I thought my adversary would be a nation state or anything else so powerful I would take a defense in depth approach of layering multiple independently developed systems using different algorithms and constructions.
ebiggers 8y ago
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 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.)
ciphergoth 8y ago
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.

230 points by zx2c4 8y ago

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!

consp 8y ago
> Well, that should be easy to answer: Simon and Speck are "lightweight" ciphers intended for embedded designs. You are providing rationale which the NSA is, according to Ashur, unable to provide in the design documentation/rationale. So I think you are missing the point he's trying to make: If you can't tell me why and are doing hand waving you are either incompetent or deliberately dismissive in which case you should not be trusted.
- dfox 8y ago
  I think that part of the issue is that people (probably including the WG2) hear NSA and then ignore the lightweight part. To some extent the lightweightness implies lower standard for the security margins. This is in this case compounded by the fact that WG2 had thrown out most of the truly useful NSA recommended Speck/Simon parameter combinations (things like 32b blocks) even before the current turmoil on the basis that they obviously provide insufficient level of security, which is obviously true for general purpose block cipher, but not for lightweight ("IoT-ish" ;)) applications. On the other hand I somewhat wonder what motivation exactly NSA had for trying to push these algorithms through ISO.
  - notveryrational 8y ago
    No. They hear the lightweight part. The author clearly understands this. It's the actual designs of the cipher, security margins, motivations for the key schedule, and others he has an issue with. The issues include lies and misleading omissions in publications.
- tptacek 8y ago
  No, if you re-read my first sentence, you'll see that I'm not suggesting we should trust NSA.
bo1024 8y ago
- I wonder how the NSA's compute resources translate into an inherent advantage over academics in terms of ability to break these codes. Especially if we are talking about pushing the limits of small margins. - I don't think it's fair to say the background is "political" if NSA is currently not cooperating with the process. Calling it political makes it sound like their treatment is a function of the broader context or history, but it sounds like they are being treated fairly given how they have acted in this situation.

brian_herman 8y ago

Why are they changing?

lowry 8y ago
Because Speck is said to be more performant than AES.This is discussed in the mail.
- mtgx 8y ago
  Why not use ChaCha20? I believe it's twice as fast, at least in software.
  - dfox 8y ago
    Because ChaCha20's block migh not even fit into memory on platforms that is Speck/Simon meant for. The question should be: Why not use XTEA or RC5/6. And the answer (ignoring the NSA and it's opaqueness) is that Speck (in its reference implementation form) is slightly faster than both XTEA and RC5 and can be trivially implemented such that it is twice as fast and also uses 64b words in 128b block size variants which on typical 64b platforms leads to another essentially free 2x speedup. (Not that it makes sense to use Speck for bulk encryption on typical 64b CPU) On the other hand team related to DJB published algorithm called Gimli (https://gimli.cr.yp.to/ https://gimli.cr.yp.to/) whis is essentially narrower ChaCha 20 transformation with intentionally slow diffusion as to fit onto registers of register-constrained CPUs (like Thumb) that is intended as Keccak-style sponge permutation. On the other hand in my opinion authors' paper and slides also have similar issue as what part of the original article criticizes NSA for, the security arguments for Gimli are considerably better than NSA's arguably non-existent ones but then the bigest issue I intuitively have with Speck is slow (and somewhat one-way) diffussion of the key schedule and Gimli's 4-round function is somewhat similar or even worse in this manner (although it does not have the "onewayness", for lack of a better word).
    - ciphergoth 8y ago
      We need a drop-in replacement for AES, and Gimli doesn't have a 128-bit block size.

setquk 8y ago

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.

mindslight 8y ago
No, no. You don't understand. That's the other side of the kitchen that was spitting in people's food last week. Your friendly waiter obviously got your food from the clean side this week! And it's clearly offensive to even ask whether your plate could have gotten near the known spitters, which is why he refuses to answer.
- zer00eyz 8y ago
  LOL -- you didn't read the article did you? > The NSA (in particular, the exact same person who previously promoted DUAL_EC in ISO) proposed to include Simon & Speck The author is pointing out that the same person spit in your food before.
  - vengefulduck 8y ago
    I'm nearly certain the parent commenter was being sarcastic.
    - zer00eyz 8y ago
      The original analogy was good - the commenter diminishes it by trying to portray the NSA person responsible as a different actor. This is the same person who has burned the community before. That old adage about fooling someone once applies here, and for good reason.
      - mindslight 8y ago
        Focusing responsibility on the individual NSA agent is a red herring - the entire organization is the hostile party. Would you judge the situation differently if it were a different operative pushing Speck? The asset themselves probably isn't even privy to the actual existence of a backdoor, due to compartmentalization and for the sake of their own sincerity. They're more akin to the waiter. A waiter that doesn't want to think too hard about whether your food was spit in, as their job depends on not knowing. How are you doing today? smile

johnflan 8y ago

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

PerilousD 8y ago

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?

_wmd 8y ago
Because if it is possible to ascertain they are acting in good faith, there is no better collection of minds, money and official secrets suited to the task of designing a robust cipher. The problem is that it's somewhere between difficult and impossible to ascertain whether they are acting in good faith.
- api 8y ago
  There is also no real need. Reduced round Salsa/ChaCha (12 rounds) is tiny and likely fast enough for the quantities of data any microcontroller would need to push over a network. Those ciphers were designed in the open and have been heavily analyzed with no attacks known against more than a few rounds. Why not use those?
  - makomk 8y ago
    In general that's true, but if I understood the discussion correctly the reason Speck was being considered here is because this specific application needed a fast block cipher - stream ciphers like Salsa/ChaCha were not suitable.
- craftyguy 8y ago
  Their recent behavior suggests that they are not acting in good faith and, even if they were, the "between difficult and impossible to ascertain" bit should mean that they are, by default, not trustworthy.
  - _wmd 8y ago
    It's important to remember the desired goal - secure cryptography, and in that case even if the NSA is a known-bad actor, they might still be the best option to achieve an optimal outcome. There is a name for the kind of table below but I have forgotten it. Essentially on the balance of outcomes, a situation (of engineered choices, of course!) where the NSA is involved still produces, given unknown factors, a potentially better outcome than a situation where the NSA is excluded. Bad = 0.1, Fair = 0.5, Excellent = 1.0 Cipher Author | Known Weak | Security | Likelihood | Security*Likelihood | Academia | No | Excellent | Bad | 0.1 Academia | Nationally | Fair | Fair | 0.25 Academia | Internationally | BAD | Fair | 0.05 NSA | No | Excellent | Fair | 0.5 NSA | Nationally | Fair | Fair | 0.25 NSA | Internationally | BAD | Bad | 0.01 SUM(academia) = 0.31 SUM(nsa) = 0.76 (Does anyone know what this kind of table is called? Can someone do a version that makes more sense? It's 4am and quite a few beers were involved :))

emilfihlman 8y ago

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

bhouston 8y ago
He is only throwing out Speck and saying it is worse than no-encryption.
- emilfihlman 8y ago
  He's throwing out all of his reputation with that claim also. He should not hold any Senior Researcher positions if this message is anything to go by.
  - larkeith 8y ago
    Could you please address and refute his reasoning (probided in the prior paragraph), so as to encourage discussion?
    - drostie 8y ago
      Oh there are so many reasons. The easiest is the adoption problem, the same as hit HTTPS: at least 40% of top websites are still unencrypted even after a massive push from browsers to muscle them into submission; compare to the fact that with no massive push 90% of the ones that do support HTTPS don’t support SSL (they only support TLS, the old standard having severe security flaws). In other words there are concrete numbers to back up the point that when an algorithm is learned to be broken, it is easy to convince panicking folks to upgrade it. But when it simply doesn't exist and hasn't ever, it is harder to convince folks that they need it. Even more to the point, attacks do not exist in isolation and there is no “secure/insecure” dichotomy. You can see this with AES where the AES-256 key schedule is much weaker than the AES-192 key schedule, but the place where this really shines is in related-key attacks, where AES-192 has about twice the bit-strength of AES-256. Does that mean you should switch over? Well, probably not: related key attacks are structurally harder to pull off. The qualitative differences make comparison hard. Probably if the NSA had an exploit for Speck for example, it would take the form of "steal the device running Speck for an hour to get some carefully chosen challenge-response pairs, return it back to the user, budget a day or two of time on the supercomputer to look for patterns in that data, and finally you can recover the key." (I say this in part because it’s hard to hide backdoors in symmetric crypto.) Many applications would be more secure than nothing if that were the only applicable threat model. But even quantitatively, in theory security is not a binary. It's much closer to a dollar amount: here is how much it costs to launch attacks against this system. And $0 on this scale is certainly lower than a serious vulnerability at the $100,000 level. Basically this is a solid argument why you should not roll your own crypto but those arguments are categorically not transferable to crypto whose specifications are known openly and subjects of active cryptanalysis.

MrBingley 8y ago

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

MaxBarraclough 8y ago
I know this one - that's a replay attack, right?
chris_wot 8y ago
That's not the saying. Its, "Fool me once, shame on — shame on you. Fool me — you can't get fooled again." It's an old Tennessee saying. Or I think it's in Tennessee, I know it's in Texas somewhere...

john8899 8y ago

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-first-call-lightweight-cryptography-protect-small-electronics https://www.nist.gov/news-events/news/2018/04/nist-issues-fi...

tptacek 8y ago
Since it's unlikely that Simon and Speck will win this competition, given that there are other credible lightweight designs which will probably be better-analyzed since they're open, it's hard for me to see this as anything but a good thing.

chris_wot 8y ago

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.

yk 8y ago

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.

arghwhat 8y ago
AES is extremely slow when implemented in software. Many mobile and embedded processors do not have AES hardware acceleration. With hardware acceleration, AES becomes crazy fast, but that's because hard silicon can do crazy things. However, Speck does not have a user-case, as there are sensible options available. If you don't have AES hardware acceleration, ChaCha20 can get very close in software, which is one of the primary reasons ChaCha20Poly1305 is being adopted as a common TLS cipher suite. Cloudflare has some nice benchmarks on it.
- the8472 8y ago
  The linked mail talks about XTS constructions, so the thread is about block encryption commonly used in disk encryption schemes. They also mention that they'd have to handroll such a scheme with ChaCha. I assume that Speck offers a native wide block mode which would make a better candidate for software disk encryption if it weren't for the backdoor concerns.
  - arghwhat 8y ago
    That is fair, but that is by no means an argument for Speck, but instead just an argument for a block mode cipher. What they would need to do would be to find a different sensible block mode cipher, rolling a cipher-text stealing operation mode like XTS for a stream cipher (which is not that complicated, although one should do their homework first), or using a construct to convert a stream cipher to a block mode cipher so it can use XTS directly (which is possible, but care must be taken). #2 would probably be best. I am not sure if it a trend, but I seem to mostly see new stream ciphers popping up, so this solution is likely more sensible.

deleted 8y ago

[deleted]

notveryrational 8y ago

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.

nimbius 8y ago

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

_hl_ 8y ago
I'm normally not the type to embark on wild conspiracy theories, but in this case I don't think the NSA actually believed it could push Speck into the ISO. The way Tomer depicts it, it sounds as if they almost wanted the process to fail; they made it a point to behave especially shadily. Perhaps, and here begins my wildy unfounded speculation, perhaps Speck was an attempt at setting a carefully crafted example of how the NSA pushes a compromised algorithm in an attempt to lower the expectations of shady NSA operations - thus making their next, real attempt more credible. But who knows.
- api 8y ago
  Possible but unlikely. Bureaucracies generally aren't that subtile. It is a good idea to be paranoid in crypto though. If I thought my adversary would be a nation state or anything else so powerful I would take a defense in depth approach of layering multiple independently developed systems using different algorithms and constructions.

ebiggers 8y ago

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

ciphergoth 8y ago

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.