All the crypto code you've ever written is probably broken

http://tonyarcieri.com/all-the-crypto-code-youve-ever-written-is-probably-broken

by bascule • 14 years ago

112 128 14 years ago

tptacek39• 14 years ago

NACL and Keyczar are two viable alternatives to DIY crypto. I'd use NACL before I considered trying to DIY an AEAD secure transport; there are more things to get wrong than properly authenticating your data!

You are always better off not working directly with crypto at all. For that, consider using PGP/GPG for data-at-rest (if you're in a JVM language, you can use Bouncycastle to get access to PGP) and SSL/TLS for data-in-motion.

In our practice, password reset tokens and encrypted session cookies continue to be the top source of exploitable crypto vulnerabilities in web applications. You don't need encryption to build either of these features; send 128 bit random numbers that key a database row instead.

Jabbles• 14 years ago

Could you explain why "encrypt then MAC" is the right option please? It isn't obvious why the other two are broken. Luckily I don't work in crypto :)

tptacek39• 14 years ago

It allows you to use MAC validation as a screen for incoming messages and so prevents attacks that depend on ciphertext manipulation.

dchest2• 14 years ago

cperciva wrote a blog post about this: http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac....

forgotusername2• 14 years ago

If I'm not mistaken (and haven't read up on this stuff in years, so probably), the majority of encryption modes rely on XORing the stream of bits from the cipher with your plain text.

In that way, both sender and receiver need only generate the same cipher bits and apply XOR to encrypt and decrypt (meaning encryption and decryption are actually identical operations!). A side effect of XOR is that a single bit flip in the ciphertext corresponds exactly to a single bit flip in the cleartext. An attacker with knowledge of your cleartext can therefore modify it without ever needing to know the cipher parameters.

Imagine a session cookie that contains a single 32bit integer, the user ID. Now attacker knows his user ID, so he merely needs to XOR the cookie with his ID, then XOR it again with his desired ID and voila admin privileges. Wrapping the cookie in a MAC prevents this kind of manipulation.

agwa• 14 years ago

Moxie Marlinspike wrote a great blog post about this: http://www.thoughtcrime.org/blog/the-cryptographic-doom-prin...

cdjk• 14 years ago

Short answer - it lets you verify the data before decrypting so you can reject invalid data earlier.

femto113• 14 years ago

Missing from this blog post, but made clear here (http://blog.cryptographyengineering.com/2012/05/how-to-choos...) is that you need to USE TWO DIFFERENT KEYS, one for the cipher, the other for the MAC. This makes it practically impossible to forge a valid message, since even if someone forged an apparently valid cipher section they'd be unable generate the corresponding MAC (unless they already had your keys, in which case you're already toast).

sweis• 14 years ago

Here's a slide deck by Bellare talking about some of the differences between encrypt-and-MAC, MAC-then-encrypt, and encrypt-then-MAC:

http://cseweb.ucsd.edu/~mihir/cse207/s-ae.pdf

marshray2• 14 years ago

The simplest way to think about it is during the receiving process: checking the MAC before decrypting catches and rejects evil messages earlier so there are fewer things that can (and will) go wrong. Even if you tell the world that the message wasn't invalid, you don't reveal any new information to the attacker.

OTOH, if the receiver must decrypt before checking the MAC, any information leaked to the attacker (success or failure, timing, etc) is very likely to give the attacker a systematic method to decrypt some or all of your secret plaintext.

dchest2• 14 years ago

BTW, there's NaCl port to Go in the official go.crypto repository: http://go.pkgdoc.org/code.google.com/p/go.crypto/nacl/

If you use Go, instead of hacking together things with AES from the standard library to encrypt something, just `go get code.google.com/p/go.crypto/nacl/secretbox` and call secretbox.Seal with unique [randomly generated is okay] nonce and your key to get the encrypted and authenticated "box". secretbox.Open with the same key and nonce will open it.

Bonus: on amd64 it's extremely fast (portions are written in assembly, and even pure Go versions for other platforms are hand-optimized), faster than what you can get from any non-hardware AES implementation (let alone authenticated with HMAC), and provides better security margin.

jamwt• 14 years ago

We ( http://bu.mp/company/ ) used NACL client and server side when we built our new app ( https://theflockapp.com/ ). It's a pretty great library--a shame it's not more widely used.

lifeisstillgood3• 14 years ago

  In our practice, password reset tokens and encrypted 
  session cookies continue to be the top source of 
  exploitable crypto vulnerabilities in web applications. 
  You don't need encryption to build either of these 
  features; send 128 bit random numbers that key a database  
  row instead.

That's what I wanted to hear - thank you.

languagehacker• 14 years ago

Well thanks for scaring my pants off, Tony.

Nursie9• 14 years ago

Hmm, well it's a bit sensationalist, but not wrong. It's not exactly news either.

Is the guy going for hits on his first blog entry or somesuch?

bascule3• 14 years ago

First entry on the svbtle network sure. I've blogged extensively here before http://unlimitednovelty.com

And while it shouldn't be news to anyone using crypto, I still feel like it's a poorly-known subject.

Nursie9• 14 years ago

Oh certainly.

I learned a lot by doing the coursera course on it earlier this year including an intro to a whole new area of mathematics. Some sort of intro to crypto techniques and uses really ought to be mandatory for a lot of devs, certainly anyone tempted to use anything other than a well-coded TLS API or pre-provided GCM interface.

--edit--

In fact it's also very important that even when you do know what you're doing (to a greater extent than the entirely uninitiated), you don't implement this stuff yourself, because there are more attacks than you can possibly imagine.

tptacek39• 14 years ago

In my experience it's news to something like 90% of all developers, who can generally be counted on to say things like "we used AES so not even the US military can break our encryption".

ricardobeat3• 14 years ago

Acronym overdose.

So, why should I use authenticated encryption and how can I use it on Node.JS/Rails/PHP/etc?

tptacek39• 14 years ago

Because if your ciphertext isn't authenticated attackers can modify it to launch adaptive attacks against you. Also, obviously, they can potentially rewrite messages.

This is one of those situations where if you have to ask why you'd use authenticated encryption or how you'd do it, you simply shouldn't be using cryptography primitives directly at all. Use PGP/GPG instead.

ricardobeat3• 14 years ago

Good, so the fear mongering is only targeted at crypto library authors.

krapp• 14 years ago

Well crapbaskets.

Authentication and crypto are areas where I know I'm nowhere near good enough to tell if what i'm doing works or not, other than trying to find out what the best practices happen to be and use what seems to have a good reputation. But the only constant in this field seems to be that everything I thought I knew was fatally horribly flawed from the start and that I might as well have just stuck all of my passwords in a plaintext file called "passwords.txt" because the only thing keeping my site from getting rooted was just having a terrible site nobody ever goes to.

Still this should be an informative thread.

Crushingly depressing and informative.

noonespecial• 14 years ago

Crypto: If you don't know exactly what you're doing, you're not doing it at all, no matter how hard you try. It's very hard to know if you know.

It's so hard that even when you try to "leave it to the experts" you often do that wrong as well. There seems to be no other place in programming where best practices are more important to study and observe.

anonymouz2• 14 years ago

It's very good that the author is trying to get the word out, but it would help tremendously if he tried to at least give some indication (or links to further material), of why certain modes are insecure.

The people who already know this information don't need this blog posts, and the ones that don't get no information that helps them to understand the problem. I think stating what can go wrong with, for example, ECB, would make it much easier for people to remember which mode is good and which is bad. As it is at the moment one would have to remember a few cryptic acronyms as "good" and others as "bad", without any context. (Or go look it up somewhere, but the people looking these things up are not the ones in need of being alerted...)

tptacek39• 14 years ago

If you have to explain to someone why they shouldn't be using ECB, it's hopeless. Instead, you need to be educating them as to why they should be using someone else's whole cryptosystem, like NACL or Keyczar or PGP.

Crypto is a place where a little knowledge is often harmful. You tell someone not to use ECB, so they use CBC instead. Now they're vulnerable to a bunch of new practical attacks. You list those off, and they switch to CTR, and their stuff is as trivially decryptable as simple XOR encryption.

What's the point? It's better to give people the (honest, accurate) impression that they don't know anything resembling enough to build a cryptosystem so they won't try, fail, and screw over their users.

anonymouz2• 14 years ago

I think educating people about some pitfalls and then recommending them a "full package" solution will stick better.

For example, for ECB it's trivial to explain, that it allows reordering of encrypted blocks, an attack that someone not familiar with cryptography has probably never thought about. Of course they won't gain a full understanding of cryptography in this way, but they will hopefully start to appreciate how difficult it is to get right, and how many attacks there are that they have never thought about. This hopefully includes an understanding that possibly other modes that they think would be safe might also have problems that they have never considered, and that they should really use a full package solution.

I think this will drive the point home better than, say, listing three opaque possibilities on how to use a MAC and then saying "no 1 is the right one", without any explanation whatsoever.

just2n• 14 years ago

You're interpreting these posts all wrong. There are plenty of things within the field of CS that are sufficiently complex and difficult to get right that your average Joe Coder shouldn't be attempting to write them in production code. There isn't some shroud of difficulty around crypto in particular. For instance, in just about any project, getting ANY security right, not even considering crypto, is typically an overwhelming task.

The point is that when people read this blog on the front-page of HN, they expect to learn something. 99.99% of us aren't writing our own crypto. But this is a way of learning. I've been told from basically everyone in the industry since a young age that you shouldn't write your own crypto. As a result, I educated myself to understand how I might get it wrong so I can understand when things are wrong, and so that I could understand crypto news. Similarly, as a web dev, I educated myself heavily on common vulnerabilities. The end result is that no, I can't say that everything I make is 100% secure, but it's certainly a lot better than if I didn't do those things. At least now I can actually see when myself and others might be causing a vulnerability.

You seem to be hand-waving things and telling people "STAY AWAY." Maybe, just maybe, instead of treating people like they're all idiots, enlightening them might work a little better. You've put a warning on the label, the blog post is NOT a guide on how to make crypto, but a guide in how you'll probably get it wrong. Now proceed with the juicy details. Maybe I don't know why I shouldn't be using ECB because I don't know what it is because I don't do crypto. Maybe I'm not implementing my own block cipher, or maybe I'm just curious about the different modes of block ciphers and which are good/bad and why. Maybe with a better understanding I can even explain it to other people rather than just telling them "you shouldn't do your own crypto," and look like an idiot when I have nothing to say when they ask "why?"

Applying your reasoning to computer science -- some people end up as negative productive engineers. They create more bugs and problems than they solve. Obviously, we should just STOP TEACHING CS to anyone because such people exist, right?

serge2k2• 14 years ago

So do you have to be born a crypto expert then?

I get what you are saying but the idea that people should not try to learn is ridiculous. If someone is truly interested they need to be told to go ahead. Encourage caution, but not ignorance. When someone asks why ECB is bad then tell them, or tell them to go read up on it.

benregenspan• 14 years ago

This post does not go at all into the "why" of authenticated encryption. If you're interested in more of the reasons for authenticating, including actual attacks it protects against, I found http://blog.cryptographyengineering.com/2012/05/how-to-choos... to be a good explanation of this.

digsmahler• 14 years ago

Congratulations on your first blog post! It looks pretty good, very attention grabbing. Please follow up with some more focus on the positives. I will be very interested to read more information on the correct way to implement crypto in all its subtle contextual glory.

wonnage2• 14 years ago

Security is a series of tradeoffs. Remember the Debian SSL fiasco? Turns out even when every Debian/Ubuntu user's SSH keys were essentially useless, the world did not explode. Or consider the state of the internet in the 90-early 2000s - security was basically a joke, article author would've bust an artery raving about all the ways YOU ARE PWNED RIGHT NOW. Oh, and it looks like people are okay with Dropbox even though it occasionally fails horribly and lets you see other peoples' files.

It turns out for the vast majority of use cases, even broken crypto is Good Enough. That has to do with two things.

For you to be worrying about initialization vectors and block modes you need to first have a reason to be working at that level - answer "no" for most webapp use cases.

Secondly, and ignored by security fearmongerers: you need to have something of value commensurate with the efforts you've put toward security.

This is the mindset of a cryptography professional: true, chances are what you're using is broken. But whether that's a problem depends on who you are. If you're the NSA, you might be concerned with crazy shit like China building quantum computers and factoring all your primes (I'm making this up). Whereas you might be the latest social.ly startup, your users have no privacy anyway, security is more of an image concern (it looks bad to be on the front page of HN with security bug) than a real one.

tptacek39• 14 years ago

No, it does not turn out that for the vast majority of cases, broken crypto is good enough.

It turns out that for the vast majority of cases, broken crypto schemes don't have enough users for the tiny minority of software security people who look at crypto to bother beating up.

Once one of those systems becomes popular, crypto pentesters finally get around to poking at them, and, lo and behold, thousands of users are discovered to have been communicating effectively in the clear for years.

It's one of the more pernicious evil memes in our field that "if you're not the NSA, everything you do is broken, so just try the best you can". No. The attacks we're talking about take 50-200 lines of Ruby code and less than 30 seconds to run. There's no excuse for being exposed to them. We mercilessly mock people who screw up SQL queries, but then act like it took a network of intelligence service supercomputers to break our amateurish cryptosystems. We'd all be better off if fewer people tried their hand at building these systems in the first place. Use PGP, or Keyczar, or NACL. If you're typing the letters "A-E-S" into your code, you're doing it wrong.

ajross5• 14 years ago

Right. To paraphrase: it turns out that for the vast majority of cases the "security holes" in the system aren't due to broken crypto. So what's the practical difference?

wonnage2• 14 years ago

Well, we're in agreement there - and I'd go further to say if you find yourself concatenating strings and feeding them to hash algorithm you're probably doing it wrong too. It's insecure and it's more work, and it's stupid.

I just wanted to point out the more general notion that, from a business perspective, even a colossal failure like Dropbox's is more of a PR disaster than anything else. And until that equation changes, security will be at the bottom of the totem pole.

ajross5• 14 years ago

I tend to view things like this the same way. Yes, all that advice is good. But all the effects that the listed minutiae deal with are way, way down the priority list of any real-world application. Specifically they're well below the threshold where a compromise of the user's computer via other means and/or a compromise of the human communication processes involved is a bigger threat.

The MAC example is a good one. You're at the point where you're trying to protect your app against a chosen ciphertext attack (pretty far up the sophistication scale), and trying to decide the MAC mode. The text in the article makes you sound like a total idiot for not knowing what the "right" choice is and making you worry that you might not get it right.

And then you get hacked because one of your admins had a ssh key on her phone and it got stolen.

Too much security analysis is missing Big Picture issues...

tptacek39• 14 years ago

How is this helpful? How does it help to point out that so many of the people who are deploying crypto are so boned that their systems are compromised before the crypto even comes into play? Help me understand this. If you can't get the basic systems programming concerns of your software right, what business does your system have telling users that it's "cryptographically secured"?

Nursie9• 14 years ago

That's kind of the point though. If you're trying to decide your MAC mode you're already doing it wrong and should be looking at something higher level that does it for you.

acabal4• 14 years ago

OK, I get it. Encryption is hard. But just look at that post--there's so many acronyms and tech-talk that my head is spinning and I'm not halfway through. How can you expect anyone to do encryption properly when it's presented like that? In fact I'd say this post is literally useless FUD for anyone without a crypto background. It's unreadable unless you're an enthusiast.

Worse still is the huge amount of conflicting advice and methods available on the internet. If you had asked me today if AES-256 was the best there was, I would have said yes, because that's what I've read, and I'm not a crypto expert; but now this posts makes it seem like I'm wrong. The truth is that now I have no idea.

Crypto is hard, but it's so important today that it shouldn't be presented in such an obtuse way. There should be one resource that in big, bold headings and simple sentences outlines the best available crypto methods for each particular use case. Hashing password? Bcrypt. Asymmetrically encrypting plaintext? Algo XXX. Etc. Bonus points for step-by-step instructions on how to use those methods in common programs like GPG.

Without a human-readable, trusted, official resource, it's just going to be crypto scientists shoving acronyms down our throats till we don't care any more. Please simplify it and eliminate the bad choices for us, because you know better! I want to be as secure as possible, but it's outrageously hard to do with the way things are presented today.

tptacek39• 14 years ago

That's the point. The post is hard to read because the subject is hard. If that post --- which is pretty breezy --- is too hard for you to grok, the message you should be taking away with it is "I shouldn't be designing systems with crypto". The headline is good enough for you.

acabal4• 14 years ago

Yeah but how do I use systems with crypto? What if I want to encrypt some text? Do I worry about a MAC? Does GPG do MACs? How do I know? Do I worry about EAX? GCM? CCM? AES-CTR? CMAC? OMAC1? AEAD? NIST? CBC? CFB? CTR? ECB?

Programmers have to use crypto libraries all the time. The 3rd sentence in this post is "Chances are whenever you have tried to use a cryptographic library you made some sort of catastrophic mistake." Crypto is hard, but humans have to use it--this post is ridiculously complex and utterly unhelpful for anyone who's not already an expert, and that's not uncommon in crypto documentation, I think.

That's not how it should be. Something so important and widespread should be written about and explained in a human manner. My point is we need some resource to de-obfusticate the technobabble for those of us who need security but have day jobs that aren't developing the latest and greatest hash algorithm.

phogster• 14 years ago

Yeah, acabal. Fuck you for trying to learn anything.

tomjen32• 14 years ago

And with that attitude nobody ever learns anything.

To me it sounds like a bad excuse for security guys to stroke their own egos. 'Puny mortal, you are nothing. Repent your ways of sin and obey your gods.

Honestly, fuck that.

Nursie9• 14 years ago

Crypto is hard.

The point of this is you shouldn't even be using algorithms directly. If you need to touch crypto at all you need to learn about it, and the more you learn about it the more you'll realise just how damned hard it is.

Absolutely use common programs like GPG and common libraries like OpenSSL. In fact don't use anything else, and don't even think about implementing this stuff yourself.

I agree some sort of authoritative set of info would be good. Very hard to do though.

troymc• 14 years ago

"Dr. Hoenikker used to say that any scientist who couldn't explain to an eight-year-old what he was doing was a charlatan."

- from Kurt Vonnegut's novel Cat's Cradle

lawnchair_larry• 14 years ago

Correction, absolutely do not use OpenSSL.

0xABADC0DA• 14 years ago

The real problem is the software libraries are just as hard.

Take OpenSSL for example... it's almost easier to learn the crypto than to figure out the API. Here's a good one: an SSL read/write operation can fail with more than one error, and if you don't clear or loop through all the errors then the next operation will fail because of the previous errors -- even if it succeeded. Or just try getting it to work with non-blocking sockets, you finally believe it is working and surprise it fails only once the network gets saturated. Or hours later when it renegotiates the crypto.

And you still have to know all the crypt terms to use it. What's a PEM? A BIO? PKCS? DHparams? What's "ASCII armor"? X509? Did SSL_library_init() add weak algorithms? Why do I have to know this just to create a secure connection?

Most of blame for crypto problems belongs to the libraries not the developers using them.

baddox• 14 years ago

Except that one point in this article seems to be that you're still screwed even if you're using a well-respected library.

jarrett2• 14 years ago

Quite a few of the replies to acabal's comment amount to "yes, it's hard, suck it up and learn it."

But the crypto community has told us time and again that we shouldn't be trying to learn the fine details of crypto. If we are, it's a warning sign we're wading into the dangerous world of actually implementing crypto. We're just supposed to use pre-built, peer-reviewed crypto systems and understand at a very high level how they work. E.g. knowing what a hash is versus symmetric keys vs asymmetric keys, knowing which algorithms are still acceptable (Bcrypt) and which aren't (md5). And this, I think, is the right message for developers.

But the OP has a valid point. If it's true that many of the high-level, crypto-layman-friendly libraries do bad things like using all-zero IVs, then we have a real problem. But here's where I disagree with the OP: It should not fall on the average developer to understand this stuff and override a crypto library's insecure defaults.

Instead, authors of crypto libraries need to step up and implement secure defaults, as well as provide solid documentation on the do's and don'ts of their libraries. (Assuming of course the OP is correct about the flawed defaults in existing libraries.)

In any case, the solution is not to urge normal developers to learn crypto at the level the OP describes. I'm a smart guy, but I know better than to trust myself with things like initialization vectors. This is, after all, what the broader crypto community has been telling people.

Nursie9• 14 years ago

"But the crypto community has told us time and again that we shouldn't be trying to learn the fine details of crypto."

I really disagree with this, and there are now good free courses available online.

Implementing as anything other than a toy is dangerous, but learning should never be discouraged. Besides which it's fascinating.

acabal4• 14 years ago

I agree with you completely, and perhaps to clarify my comment (the one you've replied to): As you say, developers shouldn't have to worry about the fine details of crypto. What I mean by that is: Common tasks like hashing a password, creating a secure http connection, encrypting plaintext asymmetrically, etc., should be obvious, clear, and as secure as technology allows.

But, there are so many different crypto libraries with so many varied defaults, that in the end, we need some basic education on what is secure and what isn't. This particular blog post states in the 3rd sentence that developers using libraries are already making a grave mistake. How can we know which libraries to trust? If we can't trust libraries, what can we trust? Which magic combination of alphabet-soup abbreviations is the most secure, and how can I, a layman, be sure? For example: For asymmetric encryption, GPG on Ubuntu 12.04 defaults to the CAST5 algorithim. Is this better or worse than AES-256? I hear about AES-256 all the time, but I've never heard of CAST5. How can I, a layman, know it's the best default choice, considering that I only hear about more popular algorithms?

I feel like there should be a single best answer for most possible use cases. For example, today the best answer to storing password hashes would be to use the bcrypt library for your language of choice. But there's just so many options and so little clarification and consensus to a lot of these things (for regular developers, at least), that it's nigh-impossible to be confident about what you're doing. People are still MD5'ing passwords to this day--and it's not because they're idiots, because even knowing about MD5 means they had to have the initiative to Google "how to hash a password".

If I've misread the intention of this blog post, then perhaps I'm arguing the wrong point. If I am, I submit that this blog post might be better located in "crypto-researcher-news", not "hacker-news".

bascule3• 14 years ago

While I think that people should learn the cryptographic primitives as much as possible, the point of my post was to use a well-reputed open source authenticated encryption library. In addition to NaCl, there's also Keyczar: http://www.keyczar.org/

Imbue3• 14 years ago

Why is a proper MAC preferred over simply encrypting the plaintext after appending a checksum or hash.

tptacek39• 14 years ago

Among other things, because the system you just described is vulnerable to chosen ciphertext attacks.

Imbue3• 14 years ago

But if someone chooses a ciphertext (without knowing the key), how could they get the checksum right (which is also encrypted)? If the checksum was wrong, the system would refuse to decrypt the corrupted message.

pfortuny2• 14 years ago

The real problem is the lack of a REAL crypto API which does not suck as an interface for security and with which, <b>using default parameters</b>, you get good security. That is the problem. All the ones I know are too low level.

That is an engineering problem: there are the pieces but there is no real engine.

But this is my biased and humble opinion after using OpenSSL.

I am not advocating a 'just works one way' API. I am asking for a real engineering effort to create a 'dumb people can use this safely as long as they follow the simple instructions'.

If you (developer) need to know why encrypt+mac != mac+encrypt, then the security engineers have not done their job. If you need to know the difference between ECB and CBC, the security engineers have not done their job. If you need to know about the IV in AES, then ... (just repeat).

tptacek39• 14 years ago

This is the whole problem Keyczar and Nacl were designed to solve.

pfortuny2• 14 years ago

Wow, that looks impressive, really (NaCl). However, the online doc is a bit scarce, is it not?

steve89182• 14 years ago

Not that it will avoid errors on the part of the implementor, but if you do a thorough reading of the classic "Applied Cryptography" by Schneier, he pretty much covers all these problems. He covers all the issues such as ECB vs CBC, IVs, HMACs, etc. It's the definitive book on the topic and anyone who is interested in cryptography should buy this book.

tptacek39• 14 years ago

No, he famously and openly admits to not doing this. _Applied_ is not a definitive book, and _Practical Cryptography_ (now _Cryptography Engineering_), which he co-authors, starts out with a disclaimer to this effect.

steve89182• 14 years ago

Interesting, I'm admittedly a few years out of date, the last time I used the book heavily was about 10 years ago... I'll have to pick up this new(er) book.

jacquesm• 14 years ago

You could make a much simpler and more powerful statement:

  All the code you've ever written is broken.

Since cryptographic code is harder than most code and getting simple stuff right is impossible there is an extremely small chance that you'd get crypto code right 100%.

With most code the consequences are not all that bad, with cryptographic code the consequences can be disastrous.

tomjen32• 14 years ago

Hyperbole. It depends on what you are doing, what you are encryting for and what you do with the data.

zx2c42• 14 years ago

Surprised OP didn't mention OCB which has advantages over his suggestions:

http://en.wikipedia.org/wiki/OCB_mode http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#what-is-o...

tptacek39• 14 years ago

OCB has IP issues and so isn't commonly implemented.

zx2c42• 14 years ago

GPL, just like the kernel.

salem• 14 years ago

The tone is not very constructive. I would say, at the very least you should read "Applied Cryptography" by Bruce Schneier and the most recent NIST recommendations.

All the crypto code you've ever written is probably broken

Related Stories