
Linux Cryptography: Speck's real standing with the academic community - zx2c4
https://www.spinics.net/lists/linux-crypto/msg33291.html
======
PerilousD
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?

~~~
simias
Because you don't have to believe them or even trust them, it's maths. If
their design was sound and well justified I don't see why it should be
discarded. As pointed out in this email it seems far from being the case
however.

After all AES is endorsed by the US government as well (although not designed
by them, admittedly), yet we trust it because we have no reason not to.

While the NSA has an obvious incentive to be able to break encryption they
also have an incentive to be able to use ciphers than are fast and not easily
broken. Well, I suppose ideally they'd like a cipher that only they can break,
which might be what's going on here.

So while I don't think NSA's proposals for a new cipher shouldn't be dismissed
merely because it comes from them it should obviously be met with the highest
amount of skepticism and scrutiny. No stone left unturned. Fortunately it
seems that's exactly what happened there and the ciphers were rejected.

~~~
mtgx
> it's maths

That's a joke. First off, we don't even know how NIST obtained this "magical"
large number that we're supposed to trust it creates a safe formula for the
P-256 curve:

y^2 =
x^3-3x+41058363725152142129326129780047268409114441015993725554835256314039467401291

[https://safecurves.cr.yp.to/](https://safecurves.cr.yp.to/)

Second, the NSA _refused_ to reveal certain technical details that they
_should have been able to reveal_ to the ISO:
[https://www.theregister.co.uk/2018/04/25/nsa_iot_encryption/](https://www.theregister.co.uk/2018/04/25/nsa_iot_encryption/)

So it's not all "just maths". Otherwise all of these people wouldn't be so
suspicious about it.

It's not all about the design, either, even if it was 100% transparent. But
about how secure it actually is. We don't really know how secure an algorithm
is, even as it passes a competition or standardization process. We have to see
it in the real world, but once it's in the real world and everyone adopts it,
it could take at least 10-15 years to get rid of it from most places.

The NSA refused to reveal how Simon and Speck would resist against certain
attacks. They kind of did the same with IPSEC, where they made it super-
complex so that the implementers would almost always get it wrong, which means
they'd leave holes in there that the NSA could exploit. This is how they
muddied the waters in the standardization processes. It's their MO when they
can't introduce an actual backdoor - they just design a crypto algorithm that
looks okay on the surface, but hides high potential dangers:

[https://www.mail-
archive.com/cryptography@metzdowd.com/msg12...](https://www.mail-
archive.com/cryptography@metzdowd.com/msg12325.html)

Also this seems to perfectly describe how I've already thought the NSA would
act. Why would anyone ever trust them when they act like this? It's quite
strange to still see so much support here despite of this:

 _> When some of the design choices made by the NSA were questioned by
experts, Ashur states, the g-men's response was to personally attack the
questioners, which included himself, Orr Dunkelman and Daniel Bernstein, who
represented the Israeli and German delegations respectively.

> Ashur further alleged that the NSA had plied the relevant ISO committee with
> "half-truths and full lies" in response to concerns, and said that if the
> American delegation had been "more trustworthy, or at least more
> cooperative, different alliances would have probably been formed."

> Instead, he says, "they chose to try to bully their way into the standards
> which almost worked but eventually backfired."_

[https://www.theregister.co.uk/2018/04/25/nsa_iot_encryption/](https://www.theregister.co.uk/2018/04/25/nsa_iot_encryption/)

~~~
tptacek
The NSA didn't make IPSEC super complex; the NSA didn't design IPSEC. The IETF
did a perfectly serviceable job making IPSEC inscrutable, difficult to
analyze, and complicated to implement all on its own. Accomplishing stuff like
that is one of the IETF's great talents.

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

------
tptacek
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!

~~~
pdkl95
> But NSA doesn't want arbitrary weaknesses; it wants NOBUS backdoors

The NSA's handling[1] of differential cryptanalysis suggests they could
consider an entire analysis technique to be (pseudo-)NOBUS. If they believed
they were the only people that knew of a new cryptanalysis technique, I could
see them recommending a cypher that is weak to it.

(This is only a hypothetical concern. I have not studied the specifics of
Speck/Simon)

[1] Don Coppersmith, in his 1994 paper[2]: "After discussions with NSA, it was
decided that disclosure of the design considerations would reveal the
technique of differential cryptanalysis, a powerful technique that could be
used against many ciphers. This in turn would weaken the competitive advantage
the United States enjoyed over other countries in the field of cryptography."

[2] (pdf)
[http://simson.net/ref/1994/coppersmith94.pdf](http://simson.net/ref/1994/coppersmith94.pdf)

~~~
tptacek
This argument doesn't work. The NSA is pretty universally believed to have
optimized the DES s-boxes for resistance to differential cryptanalysis.
Obviously, at the time differential was a NOBUS _weakness_ \--- NSA would have
deployed it against _competing_ cipher designs, which is sort of the whole
point of employing cryptanalysts in the first place --- but it was never a
NOBUS _backdoor_ in NSA's own design.

~~~
api
Wasn't that a past NSA under different leadership? Today's NSA may behave
differently.

~~~
tptacek
It's not my argument that we should trust NSA. We shouldn't. It's that
differential cryptanalysis isn't an example of how NSA would backdoor a cipher
design, and that the nature of a NOBUS backdoor is more complex than "a
weakness only the NSA knows about". Dual EC doesn't have a "weakness" so much
as it has a cryptographically secure access mechanism.

~~~
api
If I were to place a bet I'd bet that Speck in particular is fine. It's so
damn simple there is just no place to put a lever. But... it would not be a
very large bet. :)

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

~~~
ciphergoth
We have a stream cipher based proposal, but it's a much bigger change and
needs much more review, so it can't be landed for P. A drop-in replacement for
AES is a much simpler change to make.

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

~~~
larkeith
Unfortunately, the NSA also happens to be the single largest, best-funded
collection of cryptographers in the world (probably - who knows how big
3PLA/4PLA are), and do have a history of mostly-beneficial relationships with
the crypto community. If you ignore NSA ciphers, you may just be trading
vulnerability to the NSA for vulnerability to everyone.

~~~
wafflebear
Really? Name one NSA cipher that is better than an equivalent academic-
designed cipher? DES? SHA2?

~~~
evgen
You get original DES, I get DES with the NSA-designed S-boxes. Want to make a
bet about whose messages get cracked first?

~~~
yarrel
By the NSA?

~~~
evgen
By anyone, but if adversary was NSA at the time of adoption of their suggested
S-boxes then I still win.

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

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

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

~~~
MaxBarraclough
I know this one - that's a replay attack, right?

------
brian_herman
Why are they changing?

~~~
lowry
Because Speck is said to be more performant than AES.This is discussed in the
mail.

~~~
mtgx
Why not use ChaCha20? I believe it's twice as fast, at least in software.

~~~
dfox
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
We need a drop-in replacement for AES, and Gimli doesn't have a 128-bit block
size.

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

------
emilfihlman
>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
He is only throwing out Speck and saying it is worse than no-encryption.

~~~
emilfihlman
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
Could you please address and refute his reasoning (probided in the prior
paragraph), so as to encourage discussion?

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

~~~
memory_grep
_the ones that do support HTTPS don’t support SSL (they only support TLS, the
old standard having severe security flaws)_

Isn't TLS the successor to SSL?

~~~
tialaramex
Yes, but I think your parent's point is that the sites which enable HTTPS
_did_ choose to remove support for known-broken protocols versions, so you've
got on the one hand people who cared at all, all doing something vaguely
modern and secure, and people who did nothing (plain HTTP), with no security.

You can think of TLS 1.0 as essentially SSLv3.1, with TLS 1.1 and TLS 1.2 then
as SSLv3.2 and SSLv3.3

And you might think of this as the normal course of any versioned system -
tinnier and tinnier changes, except TLS 1.3 (now awaiting publication) is
basically completely fresh, it only looks similar on the wire until encryption
switches on, in order to maximise compatibility with legacy middleboxes, once
it penetrates the middleboxes it's nothing like SSLv3.

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

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

