A cipher developed by the NSA just got mainlined

phoronix.com/scan.php?page=news_item&px=EXT4-Fscrypt-Speck-Crypto-4.18
spinics.net/lists/linux-crypto/msg33291.html
Why aren't we talking about this? This is fucking worrying.

Attached: 1511790160345.jpg (246x232, 8K)

Other urls found in this thread:

news.ycombinator.com/item?id=17224150
lkml.org/lkml/2018/4/24/840
marc.info/?l=linux-crypto-vger&m=152459378914647
twitter.com/SFWRedditGifs

explain it to me as if I were a 12yo

>NSA wrote code
>said code got merged into Linux

So why not simply
>choose not to use said code
?

Just because someone made something, doesn't mean you have to use it.

Normally you'd be right but this is literally the big daddy of surveillance we're talking about, the second link I posted is an email by a professional cryptographer advocating against the inclusion of this.

>I would also like to point out that including an algorithm because "it's
better than nothing" result in something that is not
better-than-nothing, but stands in the way of good solutions. Since
there is no acute problem, why do we need to solve it? This is from the
cryptographers' point of view. From the end-user point of view when they
get something bundled into Android, they don't know that it was included
there as something that is "better than nothing". They think of it as
"good enough; endorsed by Android/Google/Linux". What you give them is a
false sense of security because they don't know of all the question
marks surrounding Speck (both technical and political).
>So I think that as a first step, no-encryption is better than using
Speck. Then we can move for a longer term solution. Since this is an
important enough issue I asked around and people are happily willing to
help. For example, Dan Berenstein seems to believe that a solution can
be built using a generic construction along the lines of your discussion
with Samuel (with or without a variant of ChaCha). Even if a generic
construction cannot be used Berenstein told me he's willing to help
design a solution. I also asked Vincent Rijmen and Orr Dunkelman and
they both told me they'd be willing to work in a team to find (or
design) a solution. This is already an impressive cadre and I'm sure it
would not be too much of a problem to solicit other notable
cryptographer because basically, no one in this community thinks it's a
good idea to use Speck.

Then it's peer reviewed and being actively discussed, which will highlight potentially problematic aspects to the experts.

I see no problem with this to be quite honest.

>being actively discussed, which will highlight potentially problematic aspects to the experts.
The discussion has already gone on for 3 years, and the ISO even rejected it.
>Simon and Speck have been severely criticized and ISO standardization has been rejected.
Read the full email.

Every single standard and widely adapted crypto goes through the NSA and the standards are full of funny NSA enforced constants and the widely used crypto libraries are written in C and are unreadable and buggy and yes the Snowden leaks exposed backdoors in some of this shit

Welcome to life, shoot a government official to make it better, that's why you get to have guns in the US

>using NSA cipher instead of djb's cipher with same performance
what are you, stupid?

Google is the one responsible for this addition, apparently they're planning to use this on low-end Android phones that are too slow to employ better ciphers.

Let's stop fueling the panic and start to think rationally for a change:
1. The NSA (or CIA, for that matter) also uses the same cryptographic algorithms as the rest of the world.
2. The NSA is capable of spying on people even without backdoored crypto.
3. The NSA is far more concerned with keeping their secrets than the average Jow Forumsentooman
4. The NSA (or CIA) also suffers from occasional data leak. If the crypto backdoor leaks into the public knowledge, they would be the most damaged by it.

Attached: girls lie.png (558x475, 175K)

ok I will admit I did not check how chacha20 vs speck compare on various hardware, various architectures and various SIMD instruction sets
but I doubt there will be any serious difference, ChaCha20 supports all SSE3, AVX and AVX2

>ChaCha20
I'm no expert in this matter by any stretch of the imagination but it is apparently not fit for disk encryption.
>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.)
news.ycombinator.com/item?id=17224150

The NDA plans to use this algorhithm for their own stuff, so I think I'll trust it. My disks are encrypted with dm-crypt and serpent anyways, so it's not like it really matters to me

did you forget that Red Hat Linux existed

>using any NIST, NSA, GOST, JIS ciphers
there must be an option to turn it off
>it's for android crap anyway
remove cellphone, you are worst chink

so I've found proposed patch to linux kernel by Jason Donenfeld (Wireguard guy) trying to remove Speck after the rejection
lkml.org/lkml/2018/4/24/840
and answer with reasoning by Eric Biggers
marc.info/?l=linux-crypto-vger&m=152459378914647
he compares it with ChaCha20 on specific hardware limitations regarding the Android devices - allegedly storing nonces (in stream ciphers) is issue

>it's for andr*id
fuck phoneposters
go kys you dumb personaltrackingdeviceposter

>it's being added for the "lowest-end Android devices"
where there is no other encryption option supported
Literally nothing

>SELinux was developed by NSA

Attached: pepe worry.png (811x767, 413K)

Read the code.

>HTTPS was developed by NSA

Except the NSA has already been caught multiple times trying to push weakened encryption algorithms (and gotten away with it at least once). There's no reason to read the code, anything the contribute should just be rejected automatically.

>1. The NSA (or CIA, for that matter) also uses the same cryptographic algorithms as the rest of the world.
The three letter agencies know and just use other cipers and know how to read this one.
>2. The NSA is capable of spying on people even without backdoored crypto.
Somewhat. They lack the ability to spy on much traffic that is encrypted though since they don't have a back door. Since this is for IOT, they will be able to spy on personal data without even being in the data center.
>3. The NSA is far more concerned with keeping their secrets than the average Jow Forumsentooman
Doesn't matter what their primary objective is if they spy on and access the personal data of millions of people. Furthermore, their actions are not isolated. Releasing this gives true enemies more power.
>4. The NSA (or CIA) also suffers from occasional data leak. If the crypto backdoor leaks into the public knowledge, they would be the most damaged by it.
You understand they've had crypo leaks before right? No one except Jow Forums and expects give a shit for now than a few days.

You mean like industry and anti-facebook people? The NSA already tried to force this and was told to fuck off. The worry is that adoption will bring validation. The reason it didn't get any traction was because the "tech scary" people didn't get it explained to them like a 4 year old and the decision was riding on the Facebook privacy scare.

No they don't.
See:
Dual ec drbg

At this point I might as well just install Windows; if I'm gonna be spied on anyway might as well be spied on something that just works.

>"The NSA states that Speck and the hardware-focused Simon ciphers were designed for delivering an acceptable level of encryption on low-power IoT hardware. "
"acceptable" on "low-power hardware"
probably weak as shit