Cryptographic Right Answers
latacora.singles
Cryptographic Right Answers
1–10 of 243 posts
Re: Cryptographic Right Answers
#2Fight me.
I mean, happy to answer any questions.
By the way: if you're interested in this, you might also be interested in the set of 9 (count them: 9) new cryptopals challenges we sold off to raise money for rural congressional races on Twitter:
https://twitter.com/search?f=tweets&q=set%208%20from%3Atqbf&...
This is Cryptopals Set 8, before this weekend available only on request and after swearing a solemn oath not to share.
Re: Cryptographic Right Answers
#3Fight me. I mean, happy to answer any questions. By the way: if you're interested in this, you might also be interested in the set of 9 (count them: 9) new cryptopals challenges we sold off to raise money for rural congressional races on Twitter: https://twitter.com/search?f=tweets&q=set%208%20from%3Atqbf&... This is Cryptopals Set 8, before this weekend available only on request and after swearing a solemn oath not…
Do you lot have some special insight into the security of ELB, since you are so bullish on it? It's a sweet service but it's one of the more black-boxy, voodoo-ish things AWS offers and always gives me mild, irrational pangs of paranoia as a termination point.
Re: Cryptographic Right Answers
#4>Client-server application security
>Percival, 2009: Use OpenSSL.
Percival actually recommended not using SSL and shipping the server public key with the client.
From http://www.daemonology.net/blog/2009-06-11-cryptographic-rig...
>Client-server application security: Distribute the server's public RSA key with the client code, and do not use SSL.
What are your thoughts on that approach today.
Re: Cryptographic Right Answers
#5>Client-server application security >Percival, 2009: Use OpenSSL. Percival actually recommended not using SSL and shipping the server public key with the client. From http://www.daemonology.net/blog/2009-06-11-cryptographic-rig... >Client-server application security: Distribute the server's public RSA key with the client code, and do not use SSL. What are your thoughts on that approach today.
I think you should just use TLS.
Re: Cryptographic Right Answers
#6Just for reference, here are the source URLs for the quotes from Percival, 2009 [1] and Ptacek, 2015 [2].
I'm not sure about the gist, but it is what I always refer to and it's last revision is May 23, 2015.
[1] http://www.daemonology.net/blog/2009-06-11-cryptographic-rig...
Re: Cryptographic Right Answers
#7Fight me. I mean, happy to answer any questions. By the way: if you're interested in this, you might also be interested in the set of 9 (count them: 9) new cryptopals challenges we sold off to raise money for rural congressional races on Twitter: https://twitter.com/search?f=tweets&q=set%208%20from%3Atqbf&... This is Cryptopals Set 8, before this weekend available only on request and after swearing a solemn oath not…
Do you lot have some special insight into the security of ELB, since you are so bullish on it? It's a sweet service but it's one of the more black-boxy, voodoo-ish things AWS offers and always gives me mild, irrational pangs of paranoia as a termination point.
(Hi I'm not tptacek but I am also a Latacora principal and I co-edited this new version of the document)
When you're setting up ELB today you're probably getting ELBv2, specifically an ALB (since we're discussing TLS termination here). There are a few things I like a lot about the way you do TLS configuration for an ALB, but notably:
* Instead of giving you the ability to configure literally everything, they have a handful of profiles. Even the worst profile you can pick is still great. There's just no way to misconfigure ALB TLS, and there are LOTS of ways to misconfigure TLS in general.
* It is _super easy_ to get a cert for your ALB with ACM. There's somehow even less to do than if you're setting up Caddy or whatever + LE normally.
Remember: the goal of that document is to make the common case as simple as it can be and ALB does a pretty bang-up job there. If you don't have a good reason to keep that infra in-house, ALB is fine.
I don't think we have any special info about the security of ALB, but I think it's fair to say that if someone had a serious vuln in ALBs that'd be News(TM). And, if someone had a serious vuln in nginx or whatever, AWS would fix its infra faster than everyone will patch their nginxs :)
Re: Cryptographic Right Answers
#8Hey, thanks for putting that together, it's a very insightful read. One thing I would mention in the section "Encrypting Data":
KMS is great and very useful but there are limitations, for example the 4kb payload max. Another one is latency (back and forth is OK for a single decryption step, for 10.000 it might become problematic)
In case you have to go around these limitations they recommend a data key that you use to encrypt the data, encrypt the data key, store both encrypted blobs in your DB and throw away away the data key from the memory as quickly as possible.
https://docs.aws.amazon.com/kms/latest/developerguide/progra...
Thoughts?
Re: Cryptographic Right Answers
#9>Client-server application security >Percival, 2009: Use OpenSSL. Percival actually recommended not using SSL and shipping the server public key with the client. From http://www.daemonology.net/blog/2009-06-11-cryptographic-rig... >Client-server application security: Distribute the server's public RSA key with the client code, and do not use SSL. What are your thoughts on that approach today.
Just use TLS.
To quote a little bit more from that 'cperciva article:
> If you're distributing client code which speaks to a server you operate, there is no need to use SSL; instead, you can distribute the server's public RSA key (or its hash) along with the client code, and "bootstrap" the security process that way. I do this in FreeBSD for the FreeBSD Update and Portsnap services, and I also do this in Tarsnap. It's simple; it works; and it's secure.
I'm sure cperciva knows how to start from a hardcoded RSA key and end with a secure wire protocol. The spirit of the document is damage control: prevent less broken software. There's a hell of a lot more in TLS than an RSA key. There are a lot of ways you get from "RSA" to "wire protocol" and not a lot of them are any good.
If you control both ends and you want to be fancy, use TLS with one secure ciphersuite and a hardcoded CA, that's fine.
Re: Cryptographic Right Answers
#10Hey, thanks for putting that together, it's a very insightful read. One thing I would mention in the section "Encrypting Data": KMS is great and very useful but there are limitations, for example the 4kb payload max. Another one is latency (back and forth is OK for a single decryption step, for 10.000 it might become problematic) In case you have to go around these limitations they recommend a data key that you use t…
Enveloppe encryption (what you are describing) is absolutely the way to go, but the caveats described in the document for key generation and symmetric encryption apply.