41–50 of 72 posts
Earlier quoted context omitted.
The same talk is actually being given at PGConf Silicon Valley in just under 2 weeks ( http://www.pgconfsv.com/program ). We will be recording the audio and slides there and that video will be online some weeks after. You could also always come and see it live if you're in the bay area :)
Too sad, Germany is a bit too far away. However, thanks in advance for recording, looking forward to watching it!
Earlier quoted context omitted.
* ECB is not an alternative to 3DES * If you use 3DES or any other 8-byte block cipher you import several additional security concerns you have to code around * If you use CBC you also have to get the IV right, which tons of carefully designed crypto has failed to do * SHA-1 is also insecure * Neither MD5 nor SHA-1 is a MAC * Your choice of MACs brings with it new security pitfalls * How you apply the MAC also has pi…
* Never said AES ECB was an alternative to DES. * I would never use 3DES. * I am aware of that, just TLDRing. SHA-256 is my cup of tea. * Did I say they were a MAC? I would use CBC HMAC + SHA-256 for that. * No idea, since I'm not an expert at AES. I feel like you're offended that I didn't like the article. It's just an opinion, don't take it personally.
> AES CBC instead of ECB or (gasp) Triple DES
What? This entire vein of conversation is nothing but miscommunication.
These are two choices a developer should use:
* crypto_secretbox() and crypto_secretbox_open()
from NaCl or libsodium
* rm -rf code/ && shutdown
> * I would never use 3DES.
Good.
> * I am aware of that, just TLDRing. SHA-256 is my cup of tea.
SHA-384 is mine.
https://blog.skullsecurity.org/2012/everything-you-need-to-k...
Except for passwords. You don't use simple hash functions for passwords.
> * Did I say they were a MAC? I would use CBC HMAC + SHA-256 for that.
I'm assuming you meant AES-CBC + HMAC-SHA-256 here, in an encrypt-then-authenticate mode.
By "assuming" I of course meant "hoping".
> * No idea, since I'm not an expert at AES.
AES expertise isn't the issue here. Composing a secure cryptography protocol out of standard implementations is a rare skill set among software engineers.
So true, which is why I find it kind of awkward when I say to young developers/business owners they should pay for a professional PostgreSQL hosting and they argue it's open source and they can host their DBs on a $25 (or less) Digital Ocean instance. Until it's too late, I guess.
The problem is that younger devs/owners are much less likely to have ever experienced any significant outage, so it's a non-issue for them. They can't see why they should pay good money to prevent it.
We've had much better results with slightly older and more experienced people, who realize that our service is an absolute bargain compared to the cost and risk of attempting to run continuous backups, etc. themselves.
So true, which is why I find it kind of awkward when I say to young developers/business owners they should pay for a professional PostgreSQL hosting and they argue it's open source and they can host their DBs on a $25 (or less) Digital Ocean instance. Until it's too late, I guess.
here's a question - other than RDS, which other PG hosting would you recommend ?
Happy to discuss more details -- pjlegato at databaselabs.io.
I'm not saying I have ever used pgcrypto but it is important to be mindful that pg is logging stuff.
One of the constraints I am working with is that a human is not necessarily in the loop all the time. What is the best way then bootstrap the encryption process?
You basically don't. You're adding a lot of complexity chasing after a very marginal (say, 5%†) fraction of the security application-layer crypto gets you. You can get that fraction closer to 50% without a human in the loop by segregating your crypto code from the application in a virtual HSM, using something like a TLS client certificate to authenticate your application to the HSM, have humans in the loop for restar…
Earlier quoted context omitted.
* Never said AES ECB was an alternative to DES. * I would never use 3DES. * I am aware of that, just TLDRing. SHA-256 is my cup of tea. * Did I say they were a MAC? I would use CBC HMAC + SHA-256 for that. * No idea, since I'm not an expert at AES. I feel like you're offended that I didn't like the article. It's just an opinion, don't take it personally.
> * Never said AES ECB was an alternative to DES. > AES CBC instead of ECB or (gasp) Triple DES What? This entire vein of conversation is nothing but miscommunication. These are two choices a developer should use: * crypto_secretbox() and crypto_secretbox_open() from NaCl or libsodium * rm -rf code/ && shutdown Yes, a privileged few are actually capable of cobbling together a secure cryptosystem out of AES, HMAC, SHA…
> Use a well-known secure algorithm (AES256 is considered the standard). > Never roll your own crypto. Directly using a primitive like AES is pretty much rolling your own crypto. (Creating an actual cipher and using it is just beyond ridiculous.) What you should use is secretbox from NaCl (libsodium or tweetnacl). Or Keyczar, I guess that's still maintained (last commit on github is 21 days ago). Or TripleSec for lon…
Why is using AES-256 directly considered "bad"? Is the issue key management? RNG? Padding? Or what exactly? Genuine question. Or do you mean that re-implementing AES-256 in your own library instead of using a well-tested implementation is "bad"?
https://github.com/search?utf8=%E2%9C%93&q=aes+encryption
I'm not going to call out any project by name, but on the first few pages, I see:
- A project which implements unauthenticated CBC mode AES
- A project that does not, in any way, document its mode or implementation beyond "using AES 256"
- A project with - A project that uses mcrypt
Over all, it is easier to find a project with horrible deficiencies than anything that didn't immediately look concerning. And every one of these boasts "AES 256 encryption".
Earlier quoted context omitted.
Why is using AES-256 directly considered "bad"? Is the issue key management? RNG? Padding? Or what exactly? Genuine question. Or do you mean that re-implementing AES-256 in your own library instead of using a well-tested implementation is "bad"?
You can get a good example of this by simply hitting this link and reviewing the first few hits: https://github.com/search?utf8=%E2%9C%93&q=aes+encryption I'm not going to call out any project by name, but on the first few pages, I see: - A project which implements unauthenticated CBC mode AES - A project that does not, in any way, document its mode or implementation beyond "using AES 256" - A project with - A projec…
Earlier quoted context omitted.
Why is using AES-256 directly considered "bad"? Is the issue key management? RNG? Padding? Or what exactly? Genuine question. Or do you mean that re-implementing AES-256 in your own library instead of using a well-tested implementation is "bad"?
You can get a good example of this by simply hitting this link and reviewing the first few hits: https://github.com/search?utf8=%E2%9C%93&q=aes+encryption I'm not going to call out any project by name, but on the first few pages, I see: - A project which implements unauthenticated CBC mode AES - A project that does not, in any way, document its mode or implementation beyond "using AES 256" - A project with - A projec…