This raises the question of why all the thousands of implementations of pseudo-random number generators and hash functions don’t use strong crypto?

You answered:

1. unnecessary (in the case of random generators not meant for crypto, hash functions not meant for security)

So you agree that there are legitimate reasons to not use strong crypto (for the record, I consider md5 strong crypto- not that it isn’t broken, but it wasn’t designed to be broken). So if you aren’t going to be using strong crypto for legimate reasons, why not use weak crypto?

There has been a hell of a lot of thought and effort, by a large number of exceedingly bright people, put into making crypto systems both fast and secure. Now, I’m not Bruce Schneier or Ron Rivest. I’m not good enough to try my hand at making my own strong crypto. But I’ve read a fair bit of the literature and know the “rules of thumb” that have been learned over the years on what things make a good and fast crypto system. And the question arose- why aren’t we taking advantage of this knowledge, even in situations where we’re not going to use strong crypto? “Cryptographic sensibilities” was a bad turn of phrase- “Cryptographic experience” would be a better one. Why aren’t Feistel Networks more popular in pseudo-random number generators and hash functions?

One other point- you keep seeming to assume crypto=communication. That’s one use, yes. There are others. If you’re doing communication, use strong crypto, the strongest you can. Generally, the crypto isn’t going to be the bottleneck (modern crypto systems are fast, especially compared to the growing disparity between modern CPUs and modern communication channels), and using a broken crypto system is no better than not using one at all. But that doesn’t mean there isn’t a use for broken crypto systems- pseudorandom number generation and hash functions for hash tables being two obvious examples where “broken” in the cryptographic sense isn’t a problem.

1. unnecessary (in the case of random generators not meant for crypto, hash functions not meant for security)
2. ignorance (not invented here, “its not that hard”, etc)
3. legacy (md5)

> the status of exporting cryptographic algorithms out of the US is still at best ambiguous

Sure. But many algorithms have been exported. Concentrate on building _systems_ out of those blocks. ECC doesn’t get you any new capabilities over Elgamal with multiplicative groups.

The last thing I want to do is _discourage_ people getting interested in crypto. But designing your own (already broken) low-level algorithms is just needlessly spinning your wheels.

> But a major one is performance

Do you have examples? Pidgin-encryption creates a noticeable performance hit, but that’s because it does a public key operation for every message. Heavy traffic websites forgo encryption for performance, but I doubt they want _any_ performance hit, especially for already deployed crypto.

> The point of the whole manifesto is that if we’re going to be using these weak cryptographic protocols anyways, we might as well use weak cryptographic protocols designed with at least some cryptographic sensibilities.

“cryptographic sensibilities” involve not using weak algorithms. there really is no middle ground. If your goal is to simply not be shipping around the original message, you should be calling your goal “obfuscation”.

I agree that the perfect can be the enemy of the good. But if you’re looking to compromise to get more adopting, look at the PKI. Both Certificate Authorities and PGP web of trust completely suck. They set up serious usability issues which discourage adoption. (My comments here are kind of penance for advocating anonymous diffie-hellman over on reddit)

> The other problem is the installed base of insecure, non-crypto, protocols.

Most definitely. I just don’t think that replacing them with insecure crypto protocols helps things. If you’re looking to get anything moderately adopted, one of the key points is “not broken”. Else, it’s just a curious toy.

> ditch the Republicans, and those Vichyist Democrats who side with them

you’ve just included the last _28 years_ of presidents there. good luck

There are a number of reasons. One is legal- the status of exporting cryptographic algorithms out of the US is still at best ambiguous. It’s certainly not worth the hassle for a simple pseudo-random number generator or hash algorithm in some utility library. Another is complexity. But a major one is performance. Strong cryptographic properties are not necessary in these situations, and the cost in performance for using an unnecessarily strong crypto is paid for by all users of the library, and all users of all programs using the library.

The point of the whole manifesto is that if we’re going to be using these weak cryptographic protocols anyways, we might as well use weak cryptographic protocols designed with at least some cryptographic sensibilities.

As for making cryptography so easy my kid sister can use it. the best way to do that is to just have it builti-in. There are two main impediments to building strong crypto in. The political end I’ve mentioned. The other problem is the installed base of insecure, non-crypto, protocols. The first one I have a solution for (ditch the Republicans, and those Vichyist Democrats who side with them). The second one I have no idea how to tackle.

“standard” crypto is *not* too slow. advocating a broken algorithm because it’s faster is (premature optimization)^256.

take the key and xor its repetition with the plaintext if you’re looking for a fast, broken system.

But the main reason I didn’t define an endianess is because the two main uses for KSC that I see (pseudo-random number generation and hash functions for hash tables) don’t need or want a defined endianess. For the pseudo-random number case, both the state and the output would be stored as unsigned longs in the native endianess. Converting to and from some foreign endianess would be pointless. For hash functions, the problem breaks down into two parts- a hash algorithm (for which KSC is a good choice), and a serialization algorithm, which converts arbitrary data structures into a stream of bytes or words which can then be run through the hash algorithm.

The serialization problem encompasses endianess issues, and a whole lot more. How do you serialize a tree? Or an array? How about short integers? Do you sign extend them, or not? Expand each short integer into a full sized word, or pack multiple short integers into a single word? How about multi-word “bignum” integers? Floats present all sorts of problem, given than there’s no standard I know of that defines which bits in a float are the exponent, which are the mantissa, and which the sign (IEEE 754 says how many bits of each a float will have, but not where in the word they are). Plus you’ve got the issue of NaNs and Infinities (both positive and negative), all of which have multiple different encodes, all of which are in some sense equal (or not, in the case of NaN). Even strings can having surprising serialization problems- UTF-8 or UTF-16? Or code points? Include the nul at the end of the string or not? How about the length? And if you include the length, as what size integer?

None of these problems are particularly hard to solve, just pick an answer and move on. Any set of decisions I might try to make would probably be a bad choice somewhere. For example, if I were implementing a hash functions using KSC in Java, I’d probably do strings as UTF-16 encoding, which is natural in Java. In C or Ocaml, I’d probably use the natural UTF-8 encoding. Am I going to disallow using KSC simply because how the algorithm serializes strings is different? The point here is that defining a serialization algorithm was beyond the scope of what I was trying to do.

As for copyright, I really hadn’t thought about it. I’ve placed the document itself under a permissive CC license. The code has the same copyright- just throw in a comment like “Kid Sister Crypto by Brian Hurt” and you’re good to go. Although this probably isn’t the code you want to use- I wrote the code in the example explicitly to be easy to understand, not to be fast or small. There are several obvious optimizations that probably should be made, like inlining the subround function. The algorithm is public domain- it’s not patented as far as I know, and as far as I’m concerned it’s not patentable. My whole point was to use well known, well understood, common components and structures. The only novel idea in the whole work is the problem itself.

If patents or copyrights still worry you, change the algorithm. Change the constants- which are halfway arbitrary anyways. Replace the PHT in the key schedule with a rotate, maybe. Etc. The main strength of KSC comes from it’s Feistel Network strucuture- and Feistel Networks come out of the 1960′s and DES, they’ve been around since the begining of time (1 Jan 1970). You’ll likely end up with an algorithm more or less as good as KSC, but it’s a different algorithm, and thus not covered by and patents or copyrights on KSC.