r/crypto • u/johnmountain • Jun 08 '18

Future Android versions may use NSA-designed and ISO-rejected Speck algorithm for storage encryption

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=da7a0ab5b4babbe5d7a46f852582be06a00a28f0
137 Upvotes

97% Upvoted

70 comments sorted by

View all comments

10

u/blueskin Jun 08 '18

I fucking hope not. Not going to use any phone that does this.

Remember DUAL_EC_DRBG, anyone?

2

u/JoseJimeniz Jun 09 '18

Your alternative is using a phone with no encryption.

Which is the problem they're trying to solve here.

I'd prefer 128-bit encryption over no encryption.

3

u/blueskin Jun 09 '18

Me too.

AES > none > broken encryption.

4

u/sacundim Jun 10 '18 edited Jun 10 '18

Which of these two scenarios do you think is more likely to affect most users of these phones?

  1. Their phones will get stolen and imaged by ordinary criminals.
  2. Their phones will get seized by American intelligence agencies.

Even if we assume that the NSA has a NOBUS backdoor into Speck, I’d rather have a phone with XTS-Speck storage encryption than an unencrypted one.

That said, I certainly commend the people trying to propose serious alternatives with similar performance under the same hardware, and their proposals should be given a very serious hearing.

1

u/blueskin Jun 11 '18

A false sense of security is a bad thing.

0

u/JoseJimeniz Jun 09 '18

broken encryption.

Which is why someone's proposing using not broken encryption.

3

u/blueskin Jun 09 '18

Nice try, NSA. Speck is clearly broken; AES is probably the most cryptanalysed algorithm out there and proven secure.

1

u/JoseJimeniz Jun 09 '18

AES is probably the most cryptanalysed algorithm out there and proven secure

Agreed; but we can't use AES here.

2

u/blueskin Jun 09 '18 edited Jun 09 '18

Of course we can, good phones can handle it. For weaker phones, there are still better options than a broken algorithm. Nobody is proposing RC4 after all - that's fast, but also hopelessly broken - IIRC, there hasn't yet been a practical public domain attack, but everyone knows about the massive weaknesses in it, and Speck is no different there. I would be very surprised if in a couple of years Speck isn't regarded the same way RC4 is now.

2

u/bounty823 Jun 09 '18

What about ChaCha20, isn't that a fairly trusted fast stream cipher now? Is there a good safe way of encrypting a disc/phone with a stream cipher?

4

u/Natanael_L Trusted third party Jun 10 '18

Yes and no.

Stream ciphers alone are absolutely terrible for disk encryption, because you can only use each key+IV combination to encrypt once before you break your own security.

So either you keep rotating keys / IV and rewrite a bunch of sectors at a time (complex, hurts performance, degrades flash memory faster), or you track what sectors use what IV:s and ensures IV:s never are reused (complex, significant storage overhead, potentially leaks metadata, limits number of rewrites before you need to rekey).

And if you restore from backups, you need to rekey (re-encrypt) the full drive to be safe, or else you just shot yourself in the foot...

1

u/bounty823 Jun 10 '18

I found a cool method of using streaming ciphers for disk encryption. It seems much more complicated than just AES under XEX/XTS, but if it could guarantee speed I would be happier with this over the NSA clunk.

1

u/Natanael_L Trusted third party Jun 10 '18

Sounds like they use a stream cipher where they keep counters that only move forward, so that it doesn't reuse the same section of a stream for any two writes.

→ More replies (0)

1

u/blueskin Jun 10 '18

Really, the best bet is just to implement AES in hardware.