11 ms·
Red October: Go server for "two man rule" file encryption by Cloudflare
- evgen 13y agoShamir secret sharing was "complicated" so instead they built a bespoke system that basically replicates the same effect but in a less trustworthy manner? Hey CloudFlare, how about just linking to libgfshare instead of rolling your own crypto?
- ivanvanderbyl 13y agoThey didn't roll their own crypto, if you read the source you'll find this is a solid implementation in top of the Go stdlib crypto packages.
- timclark 13y agoTo incompletely quote Rob Pike: "If crypto is so hard that only one implementation is allowed to exist, it's crypto that needs to be rethought" https://groups.google.com/d/msg/golang-nuts/0za-R3wVaeQ/M8_BiuaZ_2YJ https://groups.google.com/d/msg/golang-nuts/0za-R3wVaeQ/M8_B... Why do crypto people only want there to be a single C implementation of everything?
- 16s 13y agoAmen. All these people who parrot, "Don't roll you own crypto" need to get out of the math/programming kitchen and go get a crypto burger from some national fast food joint. My advice would be don't roll your own primitives, but other than that, have at it.
- Ygg2 13y agoApparently yes, Rust also asked crypto people about rolling their own crypto. And their answer was - "Don't." Crypto is just so mind boggling hard from what I gather, there are probably hunderds of ways attacker can mess up the system. But overall I agree - there shouldn't be a single implementation of anything ever. Crypto people need to come up with some kind of test or prover, or something that can tell programs if they are safe enough, and where they aren't. A kind of test harness or program prover.
- rlpb 13y ago> A kind of test harness or program prover. I suppose they need to solve the halting problem, too?
- Ygg2 13y agoWell something that deals with basic problems first. I don't think having a way to test for timing attacks is too far out. I guess you should aim for good enough and not perfect.
- gnuvince 13y agoThey can only test for flaws that they can think of.
- Ygg2 13y agoThat would be enough for starters. A dedicated enough enemy will bypass your defenses sooner or later.
- jerf 13y ago"Crypto is just so mind boggling hard from what I gather, there are probably hunderds of ways attacker can mess up the system." One of the problems that is really hard to get around is the "timing attack"; by passing various values into a crypto system and seeing how long it takes to either return or error out, you can learn things, often entirely decoding a message in surprisingly short amounts of time. To defend against this, a crypto system must make pervasive use of operations that take the same amount of time whether they succeed or fail. For instance, if you are comparing one string against another, you must compare the same amount of string regardless of the input; you can't bail out at the first difference, which is what you would normally do. Unfortunately, as hardware gets more and more complicated this gets harder and harder to guarantee. Surprisingly small differences have been demonstrated to crack messages. And the worst part is, this is all advantage attacker; the attacker does not need to know why he's seeing timing differences, he can just figure out what they mean and exploit them. It's the defender that has to figure out (for example) that some predictive algorithm on the CPU sometimes preloads the next chunk of RAM and sometimes doesn't according to the alignment that your buffer happened to receive, depending on the (attacker-controlled) size of the first packet, and then figure out what to do about it. The upshot of this is that crypto implemented in darned near anything other than assembler is probably flawed. C is the standard because that just isn't practical, but almost anything higher than C is dangerous. Many of the things that a high-level language consider a feature make programming proper industrial-strength crypto either difficult, or simply impossible. (Good luck preventing timing attacks in Haskell. The language and runtime fights you with every fiber of its being. And the ways in which it is fighting you are good thing the vast majority of the time... just not this one.) It's relatively easy to produce a crypto library that emits the correct streams and decodes the incoming streams into the proper values, but that is merely the beginning of creating a truly robust crypto library; it's not even the halfway point. It's the easy part. Go's crypto is built by people who know this stuff, so for instance: http://golang.org/pkg/crypto/subtle/ http://golang.org/pkg/crypto/subtle/ However, they do not claim it has been vetted by anybody in particular. Proving their implementation correct is very difficult, and I'd still worry about whether GC is going to bite somebody somehow in the implementation, nor is there any particular proof that they didn't miss a place they should use one of those functions, and I wouldn't bet my life the functions are 100% correct in all cases, either. (They're simple, they look good, but one stray compiler optimization and.... who knows?)
- rmc 13y agoWhy do crypto people only want there to be a single C implementation of everything? Because it's hard, and if you make a mistake, it means there is no security.
- lmm 13y agoMost languages, go included, are hopelessly unsuited for writing crypto code, which cares about precise processor behavior in a way that no other problem does. Honestly I suspect with the current state of C compiler optimizations the only language suitable for writing crypto primitives is assembler.
- sacado2 13y agoOr just turn off compiler optimizations.
- pjmlp 13y ago> Why do crypto people only want there to be a single C implementation of everything? It doesn't need to be a C implementation, but crypto is very very easy to get wrong. So never try a new implementation if you don't fully understand existing ones.
- mwsherman 13y agoA crypto monoculture seems dangerous, too. A single implementation sounds naively attractive but it also represents a single point of failure. I’d rather have many imperfect-and-actively-improving implementations, than a single implementation that is widely relied upon and fails.
- kenkam 13y agoThe other side of the argument is that the more people that are creating/working with and disseminating/peer reviewing crypto projects, the better we will be educated on crypto collectively. An example is web technology: plenty people have made plenty html/css/js mistakes in the past but there is also an overwhelming amount of evolving best practices on this topic, no doubt because of the mistakes made before. If all we do is decry crypto is hard, don't roll your own, then no one would be learning anything, and cryptography will be left to the a few select mathematicians and organisations that are referred to with acronyms. It should be: crypto is hard, learn it and experiment with it, share your thoughts, and don't roll your own for critical applications. Edit: clarity of argument in my example and grammar
- sneak 13y agoWhy the hell does the go argument parser insist on that silly single-dash-then-key-then-equals-then-value syntax? Is it Rob Pike doing that thing that "different because I said so" thing that he and djb have been pioneering for years?
- dscrd 13y agoWhat's silly about it?
- plorkyeran 13y agoIt's pointlessly different from the syntax everything else uses.
- nknighthb 13y agoUm, no, it's not. The equals sign is not required, it is simply supported (as it is with many if not most other command line flag parsers), and single-dash is hardly unusual outside GNU tools. It may be different from what you are accustomed to, but you are not omniscient.
- icebraining 13y agoOn what systems is single-dash plus word (instead of single letter) common? Not trying to argue, I barely use anything besides GNU/Linux, but even in the Plan9 docs I only remember seeing single letter options after a dash.
- nknighthb 13y agoBSD, Windows. By the way, it's not exactly unknown in GNU land, either. Ever looked at the GCC flags? Here are a few: http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
- 13y ago
- cloudify 13y agoBy the way, isn't the "famous scene" from "War Games", not "The hunt for Red October", isn't it?
- tcbawo 13y agoI immediately thought of Crimson Tide (Denzel Washington & Gene Hackman), but War Games is definitely a memorable one. "Turn your key, sir!"
- peeters 13y agoIt's a common theme. In The Hunt for Red October, the Russian captain (who holds one missile key) murders the political officer (who holds the other missile key) and publicly holds both keys for himself. Just prior to that, they use their keys to jointly open a safe containing the file with their orders (analog to decryption?). Maybe that's what the name is alluding to.
- deleted 13y ago[deleted]
- eastdakota 13y agoHere are further details on how Red October works and why it was created: http://blog.cloudflare.com/red-october-cloudflares-open-source-implementation-of-the-two-man-rule http://blog.cloudflare.com/red-october-cloudflares-open-sour...
- peterwwillis 13y agoI threw together an alternative to Red October that only requires bash, coreutils and openssl. Because it uses existing applications there's virtually no risk of the crypto implementation having bugs (or only openssl's bugs, anyway). And because it's so simple you can add whatever functionality you want to fit your system. For example, you can modify it to require a passphrase on the keys; I left it out for simplicity. https://github.com/psypete/public-bin/blob/public-bin/src/security/twoman.sh https://github.com/psypete/public-bin/blob/public-bin/src/se...
- deleted 13y ago[deleted]
- pbnjay 13y agoI'm not a crypto researcher in any way, but if someone had access to the vault, wouldn't the fact that there are multiple stored (encrypted) representations of the same data encryption key present an attack point? This image for example: http://blog.cloudflare.com/static/images/cryptography2.png http://blog.cloudflare.com/static/images/cryptography2.png stores identical plaintexts under different encryptions.
- peterwwillis 13y agoI'm not a crypto research either, but this paragraph explains basically what keeps the data secure against vault capture: > Red October is backed by a database of accounts stored on > disk in a portable password vault. The server never stores > the account password there, only a salted hash of the > password for each account. For each user, the server > creates an RSA key pair and encrypts the private key with > a key derived from the password and a randomly generated > salt using a secure derivation function. Breaking this down: 1. Create database 2. Create user 3. Store salted/hashed user password 4. Create pub/priv keypair for user 5. Encrypt keypair using password and a new salt If you get the vault, you need the user's password to decrypt their keypair. Trying to crack their password is really hard (they use scrypt). Trying to crack an encrypted keypair is really hard because they also use scrypt (i assume?). Even if it is cracked, all the other encrypted keypairs have a different salt, so even one cracked still leaves all the others to be cracked again. So even if the same plaintext data is encrypted by multiple people, it'll be substantially different each time because of all the different keypairs and salts.
- pbnjay 13y agoPresumably any attacker only cares about the encrypted data, not the user's credentials. The data is encrypted with a single data-key - so the attack would focus on cracking that key. The attacker knows that identical processes are used to encrypt that data-key. Even with multiple keys and nested encryptions, it seems that at the very least that the reduced entropy of search space around the data-key can be used to optimize a brute-force search. This would be further compounded if at least one user's key-encryption-key were known. I'm probably missing something important, but if I've learned anything from the cryptopals challenges its that you don't want to reduce your entropy in any way. Would a simple solution be to add a random salt at each level of the nested key encryptions?