Live data from Hacker News

Show HN: Crypt – Secure Configuration Storage in Etcd or Consul

xordataexchange.github.io

11–20 of 25 posts

Re: Show HN: Crypt – Secure Configuration Storage in Etcd or Consul

#11
post #7

As another point of reference an HTTP load balancer that mailgun built and uses, called vulcan[1], uses secretbox[2] to encrypt secrets into etcd. There are no good docs on how to use this in practice with vulcanctl so I will need need to ask them to document that :) [1] https://github.com/mailgun/vulcand [2] http://godoc.org/code.google.com/p/go.crypto/nacl/secretbox

Hi Brandon! - secretbox is another great way to encrypt data, and would have worked for this project too. Ultimately we chose openpgp because it allows us to encrypt the same data with multiple public keys all at once, for multiple consumers.

Re: Show HN: Crypt – Secure Configuration Storage in Etcd or Consul

#12
post #5

"After encryption it is gzipped" is a red flag. After encryption it should be noise, why try to compress it?

Sorry, if I said that in the video. What we do is base64(gpg(gzip(data))) We gzip the data first, then encrypt it, finally base64 encode it.

The article says you encrypt, then compress. You might want to clarify that.

Re: Show HN: Crypt – Secure Configuration Storage in Etcd or Consul

#13

Earlier quoted context omitted.

Sorry, if I said that in the video. What we do is base64(gpg(gzip(data))) We gzip the data first, then encrypt it, finally base64 encode it.

The article says you encrypt, then compress. You might want to clarify that.

My bad - fixed.

Re: Show HN: Crypt – Secure Configuration Storage in Etcd or Consul

#14

Earlier quoted context omitted.

The article says you encrypt, then compress. You might want to clarify that.

My bad - fixed.

In the next paragraph after the one you fixed

> crypt encrypts, compresses, then encodes your value for storage

Re: Show HN: Crypt – Secure Configuration Storage in Etcd or Consul

#16
Awesome project, thanks for sharing.

Looks like it takes a similar approach as the hiera eyaml project (it also encrypts on a per-key basis using gpg) which I've found to be really nice to work with in the past (as opposed to other tools that use symmetric encryption or encrypt the entire blob of all secret keys together). Glad to see a tool that does this with etcd and consul, gives the same benefits without a centralized puppetmaster.

Any plans for clients in other languages? Or if you're not planning to build would you accept PR's for them?

Re: Show HN: Crypt – Secure Configuration Storage in Etcd or Consul

#17
post #16

Awesome project, thanks for sharing. Looks like it takes a similar approach as the hiera eyaml project (it also encrypts on a per-key basis using gpg) which I've found to be really nice to work with in the past (as opposed to other tools that use symmetric encryption or encrypt the entire blob of all secret keys together). Glad to see a tool that does this with etcd and consul, gives the same benefits without a centr…

Yeah, I'm open working with anyone on other client libs. Ideally we can track them in an official doc in the repo. To help others get started I'll document the data we store in etcd/consul in more detail.

Ideally clients only need to store values with the following encoding base64(gpg(gzip(data))) and do the reverse when retrieving data. As long as the public/private keys are available, everything should work.

Re: Show HN: Crypt – Secure Configuration Storage in Etcd or Consul

#18

Earlier quoted context omitted.

In the next paragraph after the one you fixed > crypt encrypts, compresses, then encodes your value for storage

dammit.

In this thread: just talking or writing _about_ encryption can be difficult. To say nothing of correctly implementing it in a project.

Re: Show HN: Crypt – Secure Configuration Storage in Etcd or Consul

#19
post #5

"After encryption it is gzipped" is a red flag. After encryption it should be noise, why try to compress it?

Sorry, if I said that in the video. What we do is base64(gpg(gzip(data))) We gzip the data first, then encrypt it, finally base64 encode it.

Don't compress then encrypt. It doesn't matter in this use case, but it matters very much in others. When attackers have chosen plaintext (which is virtually always), they can exploit compression to create a traffic-analytic side channel. This is the CRIME and BREACH attack on TLS, for instance.

Schneier, in Applied Cryptography (which: avoid) recommended compressing before encrypting. That was bad advice. Compression and encryption interact in treacherous ways. Get of out the habit of combining them.

Re: Show HN: Crypt – Secure Configuration Storage in Etcd or Consul

#20

Earlier quoted context omitted.

Sorry, if I said that in the video. What we do is base64(gpg(gzip(data))) We gzip the data first, then encrypt it, finally base64 encode it.

The article says you encrypt, then compress. You might want to clarify that.

How can you possibly compress encrypted data? An ideal cipher should produce output indistinguishable from randomness, which is inherently difficult (read: near impossible) to compress.
Post reply on HN