Van de Ven: Deprecating old crypto

[Posted March 24, 2015 by corbet]

Worth a read: this post from Arjan van de Ven on the difficulty of removing old, insecure cryptographic algorithms from a Linux distribution. "But more, and this is a call to action: If you're working on an open source project that uses crypto, please please don't opencode crypto algorithm usage. The algorithm may be outdated at any time and might have to go away in a hurry."

Van de Ven: Deprecating old crypto

Posted Mar 24, 2015 21:05 UTC (Tue) by epa (subscriber, #39769) [Link] (6 responses)

It's a pity there is no easy way to compile out encoding but not decoding. Of course for a symmetric cipher the same code will be used, but it would be neat to guarantee that (for example) you will never again encrypt new content with DES, but you can still read older archived data.

Similarly if hashes like MD5 provided two interfaces: make_hash(data) and check_hash(data, expected_hash) then you could compile out support for generating new MD5 digests while still working with existing signed data.

Van de Ven: Deprecating old crypto

Posted Mar 25, 2015 0:25 UTC (Wed) by jeff_marshall (subscriber, #49255) [Link] (1 responses)

Encryption and decryption are usually defined separately at the block-cipher level, so it would be possible to remove one but not the other.

However, the mode with which the cipher is used may not make this possible. For example, counter mode only uses the block-cipher encryption primitive to implement both encryption and decryption of messages.

At the api/implementation level, the problem tends to be that make_hash (or equivalent) often takes a struct with function pointers to the implementation of the actual cryptographic method. This is done because the decision of which hash function to use is often a result of header parsing (offline case) or session negotiation (online case) and lives in a different module from the code that actually invokes the hash function. If you want to ditch a cipher completely you'd have to either reject it at selection time (more code to inspect for correctness), or remove the cipher completely and give up decryption as well as encryption. Add to the fact that someone might call make_hash() and do memcmp() themselves instead of calling check_hash() while still getting correct results, and automated checking of the source code becomes more difficult.

Van de Ven: Deprecating old crypto

Posted Mar 25, 2015 3:02 UTC (Wed) by ncm (guest, #165) [Link]

It doesn't matter if the code is still there, as long as the public entry points you don't want are gone. Nobody writes crypto calls by accident.

Counter modes only appear in relatively modern cryptosystems, so are not in most of the systems you don't want.

Van de Ven: Deprecating old crypto

Posted Mar 25, 2015 21:46 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (3 responses)

> Similarly if hashes like MD5 provided two interfaces: make_hash(data) and check_hash(data, expected_hash)

Well, if the interfaces were that easy, maybe people wouldn't have thought they needed to reimplement them in their own projects. Really, the code to get hashes of data out of these things is absurd.

Van de Ven: Deprecating old crypto

Posted Mar 25, 2015 23:41 UTC (Wed) by cesarb (subscriber, #6266) [Link] (2 responses)

A "make_hash(data)" interface is useless for streaming data, since it needs the whole data in memory. Good luck trying to hash a 5 GiB file on a 32-bit machine!

The traditional hashing API is pretty simple: an "init" function, an "update" function to be called repeatedly as data arrived, and a "finish" function to be called at the end to finish the computations and return the hash. The code to get a hash out of this API is not "absurd"; in fact, if you have all the data already in memory, it's three straight calls (init, update passing all the data at once, finish).

I can see, however, the value in providing two variants of the "finish" call: one which simply returns the hash, and one which does a constant-time compare with a passed hash. A lot of people forget the "constant-time" part, and it's important!

Van de Ven: Deprecating old crypto

Posted Mar 30, 2015 13:47 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (1 responses)

So the problem isn't just that. The problem is all the crap you have to go through to prep the *library*. NSPR_Init() and that zoo of functions. And then find a way to shut it down properly. If hash_ctx_init(), hash_ctx_update(), and hash_ctx_destroy() were *all* that were necessary, that'd be great. But AFAIK, it isn't (though I admit I haven't looked at OpenSSL *too* much because I'd rather not deal with GPL-incompatibilities).

Van de Ven: Deprecating old crypto

Posted Mar 30, 2015 19:24 UTC (Mon) by dkg (subscriber, #55359) [Link]

If you just want a simple hashing interface without a lot of unnecessary library initialization and shutdown overhead, i recommend looking at nettle. The nettle manual's example code even shows that workflow explicitly.

Van de Ven: Deprecating old crypto

Posted Mar 25, 2015 3:01 UTC (Wed) by imgx64 (guest, #78590) [Link] (3 responses)

Coincidentally, OpenSSH just disabled SSH-1 protocol: http://undeadly.org/cgi?action=article&sid=2015032420...

Van de Ven: Deprecating old crypto

Posted Mar 25, 2015 6:34 UTC (Wed) by epa (subscriber, #39769) [Link] (2 responses)

I remember patching OpenSSH to add support for 'none' encryption. This was for running it on a 16Mhz 386SX where encryption ran slowly and I only wanted to talk over a LAN of two computers. ssh is higher quality code than rsh or telnet in many ways, so I wanted to keep using it, but have an option to talk unencrypted.

Conceivably a similar setup could be used for virtual machines to talk to other VMs on the same supervisor, where the virtual network interface has no risk of eavesdropping or MITM (unless deliberately configured to do so by the machine's owner). You might not want to do it on Microsoft Azure, but for your own compute farm it could be handy.

Van de Ven: Deprecating old crypto

Posted Mar 25, 2015 7:24 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Also 'nones' are quite useful for debugging, so you can actually see what's happening inside your application.

Van de Ven: Deprecating old crypto

Posted Mar 25, 2015 13:56 UTC (Wed) by arjan (subscriber, #36785) [Link]

"none" encryption certainly has its uses... as long as it for 400% sure it's never in any automated downgrade negotiation path and can only be used by explicit command line (or I suppose config file) configuration.