So, what do you propose replacing it with? Nothing. I am usually not one to argue for maintaining the status quo and I sure am in favor of encryption-for-all but this case is

Reconsidering Speck (subscribers only for another few days): https://lwn.net/Articles/761992/ Above article discusses why Speck was added and relatively soon, removed, from Linux. The NSA has burned some serious bridges and enough ISO guys know enough crypto to be able to decisively tear the NSA a new one in the following example 'So, just to let you know what's been going on at our end ...' email to the LKML (also linked in the comments to the above article) : https://www.spinics.net/lists/linux-crypto/msg33291.html which email concludes with some (thankfully) common sense: Which bring us to the million dollar question: the text book example for employing the Precautionary Principle. You yourself are not fully convinced that Speck is secure and does not contain any backdoors. If it was really secure, it could have been used in all cases and not only on low-end devices where AES is too slow. AES is slower than Speck on most platforms. … 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). True dat. ----------- On Mon, Jun 19, 2017 at 06:20:30PM +0000, Salz, Rich via cryptography wrote:

It has recently come to my attention that "Notes on the design and analysis of Simon and Speck" was published.

You might also find this useful, lots of links: https://github.com/iadgov/simon-speck

which BTW is part of https://nationalsecurityagency.github.io/

_______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

From: Ryan Carboni <ryacko@gmail.com> To: cypherpunks@lists.cpunks.org, Crypto <cryptography@metzdowd.com> Date: Mon, 19 Jun 2017 10:49:26 -0700 Subject: Predictions regarding Simon and Speck for 2019 It has recently come to my attention that "Notes on the design and analysis of Simon and Speck" ( https://eprint.iacr.org/2017/560.pdf ) was published. Thus I have decided to encrypt a message using this page ( https://web.archive.org/web/20161211164439/http://www.movable-type.co.uk/scr... ) with a key generated by keypass pattern "H(15)" (15 lowercase hexadecimal). I plan on releasing the key in the early part of 2019 Block XXTEA is not trivially bruteforced with no "cribs" so here's my predictions for 2019: