
Red October: Go server for "two man rule" file encryption by Cloudflare - aram
https://github.com/cloudflare/redoctober
======
evgen
Shamir 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
They 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
To 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_B...](https://groups.google.com/d/msg/golang-
nuts/0za-R3wVaeQ/M8_BiuaZ_2YJ)

Why do crypto people only want there to be a single C implementation of
everything?

~~~
Ygg2
Apparently 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
> A kind of test harness or program prover.

I suppose they need to solve the halting problem, too?

~~~
Ygg2
Well 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.

------
sneak
Why 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?

~~~
rsc
It's the same command line flag design used by other programs at Google. The
C++ library, which Rob had nothing to do with, is at
[https://code.google.com/p/gflags/](https://code.google.com/p/gflags/).

The major benefit is that different parts of the program can declare their
flags separately, and they all get put together. When you're doing distributed
flag definition like this, single-letter flags don't make much sense: you'd
get collisions very quickly. Instead, a flag only has a long name, not long
and short. At that point, there is no need to distinguish between - and --, so
the parsers (both C++ and Go) do not.

You wrote that the parser insists on -key=value, but that's not true. Because
all flags are "long names", all of these are equivalent:

-key value -key=value \--key value \--key=value

If you prefer one over the others, use that one.

Rob and I came from the Plan 9 (really, early Unix) world of only single-
letter flags, no long names at all. That may work for small programs, but it
doesn't scale very well. The GNU "short and long" is a compromise to keep
backwards compatibility with the short flag world, but it ends up creating two
names for many things. There's no need for that compatibility if you're not
trying to recreate Unix (like GNU is). Keep it simple: one name, don't bother
caring whether people type - or --.

As others have pointed out, if you need GNU getopt compatibility or even Plan
9 compatibility, it is possible to implement as a separate library. I haven't
looked recently, but I've been waiting for someone to implement such a library
but using the actual flag registration from the standard flag package, so that
moving from one flag syntax to the other is just a matter of calling a
different parser in package main. All the actual flag creation need not
change.

~~~
peterwwillis
One could argue that -key value is much less simple than -X[=optional value].

Why would you ever need to "scale" a command to more than 30 options? At that
point you have a command line string that's 200 characters long, which is
completely impractical for a command line. And in terms of distributed flags,
who says one command wouldn't end up with the same flag name as another
command?

Look at the gcc man page. It's ridiculous! They use a mix of longnames and
short, and it's still confusing as hell. Why do they need this many options?
Because for any given operation they want to be able to specify the overall
options, language options, warning options, debugging options, optimization
options, preprocessor options, assembler options, linker options, directory
options, machine-dependent options, platform options, code gen options, etc.
As if all of those options would relate to every single GCC operation!

They seem to have a mandate that input from ARGV is the only way to determine
how to run their program. And it works for them; using autoconf and Makefiles
you can configure the options each command will use in a very fine-grained
way. But the end result is that for 99% of these cases, you have to use
autoconf and Makefiles to make sense of anything! So what the hell is the
point of stuffing them all in ARGV if a human isn't even going to use them
anyway? They could have just as easily set environment variables and been done
with it (lord knows why; probably some 30-year-old backwards compatibility
issue)

I prefer the 'cvs' model of command-line processing. The creators knew they
wanted one command which would let them do everything, but they also knew that
there would be separate operations with their own options. So you specify a
command, and then you specify your options. In this way, you know -a for 'ls'
is probably going to be different than -a for 'diff' \- but you can also look
up these options incredibly easy using 'cvs --help command'. Now instead of
having a soup of options to browse through, you know exactly what options
relate to the specific operation you want to do.

The program's execution and options become easier to understand using this
option hierarchy. It also distributes well because your commands have unique
names. And no more looking up the 1000-page manual to find the one option you
wanted.

~~~
jzwinck
Did you know about GCC's --help=CLASS syntax, like --help=warnings ? I didn't
either, but your post motivated me to look it up. That's a bit like what you'd
want--help only for specific types of things--but it has some bizarre aspects,
such as no apparent CLASS defined by operation [-c|-S|-E], so there is still
no obvious way to know from the docs that the only option relevant with -E is
-D (I think!). Another fun quirk is --help=undocumented, to "Display only
those options which are undocumented."

------
eastdakota
Here are further details on how Red October works and why it was created:

[http://blog.cloudflare.com/red-october-cloudflares-open-
sour...](http://blog.cloudflare.com/red-october-cloudflares-open-source-
implementation-of-the-two-man-rule)

------
peterwwillis
I 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/se...](https://github.com/psypete/public-bin/blob/public-
bin/src/security/twoman.sh)

------
pbnjay
I'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
I'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
Presumably 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?

------
cloudify
By the way, isn't the "famous scene" from "War Games", not "The hunt for Red
October", isn't it?

~~~
peeters
It'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.

