Quick update though: for client-server security, I copy-paste misquoted Colin and just now noticed it (because Colin noticed it for me). The 2015 document correctly says Colin's client-server recommendation is "custom RSA protocol", but when I formatted this document I managed to accidentally make it say the same as his recommendation for "website security".
I regret the error (but not the recommendation; don't make your own custom RSA-based transport protocol).
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:
This guide is amazing. It's incredibly useful to be offered one happy path that lets non-experts (myself included) get started easily.
BUUUUUT I can't help reading these and being reminded of Vernor Vinge's "Net of a Million Lies", where people looking for shortcuts end up getting traps. We know that state actors have haunted academic and industry efforts to disseminate info and implementations of cryptography, inserting weaknesses -- resulting confusion is part of why we need guides like this.
How do we know when we can trust a "new media" guide like this one? Can non-practitioners adopt tests that inexpensively verify validity of suggestions like these? Is HN (now with "fight me" threads!) state of the art social proof, or are there other ways to incentivize expert review (without exposing those same experts to centralized influence)?
For clarity, I'm explicitly NOT suggesting this guide is a trap -- I sure has heck wouldn't know, but I don't think so and will be using it :) Just getting meta.
Is it problematic that we're moving to a djb crypto monoculture, with 25519 and ChaCha and Poly1305 and even NaCl all as recommendations? Or is he the hero we need to fight bad or weakened crypto?
I've loved the CryptoPals series, even just reading the challenges for the more advanced parts while I poke at the easier stuff. Please keep them up, and hopefully I'll get all the way through "Shackling the Masses with Drastic Rap Tactics" someday!
Can you elaborate a bit on the recommendation of KMS (Amazon or Google's key management service)? It seems to me that bringing in a new external service as a dependency, and trusting that external dependency with your encryption keys, adds a risk that isn't necessary or present with NaCL or other well-reviewed cryptography libraries. How can you independently audit the correctness of KMS? What if Google or Amazon becomes evil, or incompetent, or are put under nation-state pressure, etc?
I'm working on some open source hardware, and I'm considering embedding the SSL keys into a cheap hardware crypto element[1]. The element I'm considering [2] only offers ECDH and ECDSA with the NIST P256 curve.
However, this article says "Don’t do ECDH with the NIST curves" and "really, especially avoid conventional DSA and ECDSA".
How bad is it really? I mean, the article's pretty unequivocal, it sounds like using that crypto element isn't a very good idea?
I ask experts about this every few years, but I don't seem to write down what they tell me and I've encountered a bit of a range of opinion, but:
What's bad about cipher cascades?
(No, I don't current encourage people to use them and I tell people that there's some expert sentiment discouraging them; I want to remember the basis of that sentiment.)
I think the most useful parts of the document are the 'really try hard to use TLS for any comms problem' or 'try to use Amazon's key management for encryption' answers, and pointers to good libraries.
Beyond that: developers aren't normally tasked with building systems out of cryptographic primitives. Those that do are typically (hopefully!) experienced enough to pick a solid primitive.
Those who need to look-up which primitive to use need to know that the security of the final system is primarily going to pass or fail on the _composition_ of those primitives rather than the particular choices.
What would be really cool would be a document that takes common use cases and describes how best to build in the cryptographic aspects of the security. Edit: e.g. a good list of OpenSSL ciphersuites and SSL_CTX_config() blah calls for server auth and mutual auth is probably the biggest bang for buck you can get.
I don't want to come across as critical of the effort or correctness --- but I do I think people really need to hear the danger klaxon when they're doing more than just editing a TLS configuration file. Composition of primitives is really hard.
What right answers exist for code that has to run in phone apps? As javascript in a web browser?
If I want to do asymmetric encryption/signatures and am terrified of the security implications of non-memory-safe languages and/or libraries written in them, do I have any good options? (i.e. is there something I could use from a JVM or an OCaml unikernel or the like?)
(I would ask the same thing about website security and transport encryption, but honestly I'm going to stick with ocaml-tls whatever you say)
I was slightly surprised to see scrypt so high up the list, given its vulnerability to cache timing side channels.
Is this because you think the side channel isn't that important, or that getting the params for argon2 right is complex enough that you're cautious about recommending it more strongly, or is there something else that I'm missing? Apologies if you answered this elsewhere - I had a look and didn't find anything.
I recently ran into some HMAC-based crypto that I thought was pretty sketchy based on the "no custom crypto" principle, but I'm wondering if my concerns were overblown. I haven't found any obvious holes in it, but I'm not an expert so I don't know if that means much.
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.
Hey, can you share some crypto advice for limited embedded systems (let's say minimum being 32bit cortex-M0). Say for firmware updates, user data uploading, etc.
What about the disadvantageous aspect of djb’s curves, like that they have a non-unit cofactors? That’s a huge foot-gun that has already maimed a few people.
Also, deterministic signing nonces have NOTHING to do the DSA/ECDSA vs alternative signatures scheme. The library you recommend just uses its own deterministic signer internally, just as any ECDSA implementation can and should (e.g. bitcoin’s does).
I find the recommendations for HMAC to be somewhat imprecise. Latacora states for symmetric signtures to use "HMAC". But then under "Avoid" for the same category lists HMAC-MD5, HMAC-SHA1.
RFC 2014 defines HMAC with different hash functions such as HMAC-MD5 and HMAC-SHA1. All are valid HMACs. There are other versions of HMAC with for example SHA-256, SHA-224, SHA-512/256 etc defined.
I love Cryptopals almost as much as I love Microcorruption, although I'm not anywhere close to being ready for set 8 yet. Are these challenges going to be available somewhere I can find them months after I've forgotten about this HN thread? Or should I just send the mail once I get to that point?
What about libhydrogen's NORX construction with the Gimli permutation for AEAD and hashing? Seems like it checks a lot of boxes (from a layman's perspective.)
Would propose one amendment to "Random IDs": if you can rely on it being available, getentropy() is preferable to /dev/urandom.
(1) It blocks if the system has just booted and the kernel has not yet collected enough entropy to initialize the entropy pool. (Good on VMs, embedded systems, etc., where there's a risk that the initial state might be identical.) It would be nice if Linux had a file-based /dev/uxrandom that waited for the CSPRNG to be properly initialized and then behaved like /dev/urandom, but, it doesn't.
(2) Unlike getrandom(), you don't have to read the long section on "Interruption by a signal handler" or know about the special-casing for small buffers or even think about what to put in the flags argument -- getentropy() doesn't have a flags argument.
(3) Performance is a bit better than opening /dev/urandom, reading some bytes, and closing the fd, and you don't have to be careful about making sure the fd gets closed no matter the control flow. Performance is probably similar to keeping a persistent /dev/urandom fd open, except that has its own minor hygienic issues (especially in library code or multithreaded code). There are a lot fewer error-checking steps in one call to getentropy() than in opening, reading, and closing /dev/urandom.
(4) getentropy() and getrandom() are available even if /dev isn't available or whatever (like in a sandbox, etc.)
Sure. FWIW, my favorite is APIs like Python's os.urandom which just always does the right thing already (including, IIRC, in very recent versions, getentropy()/getrandom()/arc4random_buf() or whatever where available).
I feel like currently there are slightly fewer ways you could open up /dev/urandom and screw it up (you mention a few valid ones -- but now you're doing feature detection) and it's incidentally cross-platform (dev on macOS, deploy on Linux: super common) so I'm pretty comfortable with it still being the default. Maybe not in the 2020 version -- we'll see. I mean sure you can run out of fds and maybe /dev/urandom isn't (1, 9) but if those things happen you're already on your last legs :-)
> It would be nice if Linux had a file-based /dev/uxrandom that waited for the CSPRNG to be properly initialized and then behaved like /dev/urandom, but, it doesn't.
It could even do that for urandom already. IIRC that's what BSDs do.
The longevity of Tarsnap is quite astonishing. Congrats to Colin Percival.
---
Edit: Note to self: don't promote your home made crypto around famous people. (I'm way past home made at this point, but since there is no way to tell from the outside…)
Edit2: Seriously though, why? It can't just be because I veered off topic.
---
Shameless plug: glad my own https://monocypher.org satisfies most of this, but we do have a couple departures:
Encrypting data: Monocypher provides an XChacha20 + Poly1305 AEAD construction (copied straight from the RFC 7539). Why not XSalsa20? Because XChacha20 has a little bit more security margin, and is a little bit easier to optimise.
Symmetric "signatures": Monocypher provides Blake2b, which provides a keyed mode for this. Blake2b doesn't need HMAC.
Hashing Algorithm: Blake2b again, because it's faster and immune to length extensions attacks. I'm not sure why they still recommend SHA-2. Isn't Blake2 mature enough by now?
Password Handling: Monocypher provides Argon2i. Close to the top of the list, but not quite.
Asymmetric encryption: Monocypher doesn't have a box-like construction, but it does have a key exchange function, which combined with AEAD does the same thing as NaCl's crypto_box(). This makes the library more orthogonal, and I assumed combining key exchange and AEAD wasn't error prone.
Asymmetric signatures: Monocypher defaults to EdDSA, with curve25519 and Blake2b. Why no SHA-512 instead? Because I already have Blake2b, which is faster, and I didn't want the bloat. (Ed25519 is provided as an option)
Just 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.
Hey, 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.
Curious - why is argon2 still second to scrypt on this list?
I'd also question the backup solution, I think Restic is a better option due to its flexibility, I can do cheap backups to B2 and fairly reputable people seem to be approving of its cryptography:
This article was worth writing, and I'm glad you wrote it. It is helpful. You might not realise it but:
> If you could use KMS but encrypting is just a fun weekend project and you might be able to save some money by minimizing your KMS usage, use KMS. If you’re just encrypting secrets like API tokens for your application at startup, use SSM Parameter Store, which is KMS. You don’t have to understand how KMS works.
Paragraphs like this come across quite condescending, and the tone might have more to do with the lack of adoption of the ideas herein than the content does.
Security Professionals seem to have an unfortunate habit of talking down to everybody else.
Can anyone recommend some good cryptography books/links for someone that would like get up to speed on best practices for building secure systems? Ideally the full gamut of beginner to advanced.
What are the classic/authoritative texts in this space?
> Encrypting Data Percival, 2009: AES-CTR with HMAC.
I just found that AES-CTR + HMAC is very simple and doable in in languages like Go and Javascript for large objects which can't (or shouldn't) all be put into memory at the same time. In fact, a popular google drive client uses this: https://github.com/odeke-em/drive/wiki/End-to-End-Encryption
(assuming standard secure key generation for both the AES-CTR stream and the HMAC - along with a unique IV)
However, reading this article it seems this might no longer be recommended.
Good stuff! One minor nit suggested by someone far smarter than myself is that "it is incorrect to describe the polynomial evaluation MACs like Poly1305 and GHASH as ‘cryptographic CRC’. There _are_ cryptographic CRC-like MACs, but nobody uses them because they're more of a pain than polynomial evaluation."
Can you expand on the DSA/ECDSA problems? One this I greatly dislike is having "only one option" of RSA. In my opinion, it's better to have a variety of secure algorithms available and that are well studied, so if a new attack emerges we're not completely hosed.
Also, while I don't believe NIST is a mouthpiece for the NSA, I'm curious why they haven't proposed some alternatives to P-256, given some of the difficultly implementing it correctly. Is anyone aware if they are working on this?
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.
Where might people see the path forward as far as adoption of some of these "right" solutions in the larger side of the enterprise?
In September 2017 I had an executive pay Gartner a lot of money for a report on encryption and the result was I was directed to use Blowfish. This is obviously a ridiculous example but it's nigh impossible to get libsodium past a marketing team because they want to hear the letters "AES".
Is that just historical - i.e. a tiny chance somebody is still using the broken Debian version from a decade ago - or is there actually something still insecure, or at least suspicious, even in 1.1.0+?
I ask only because getentropy() is not widely available in the Linux world yet, and getrandom() - and direct use of the /dev files - do have some caveats of their own.
A bit tired with "Just use HMAC". HMAC makes you pull a hash dependency, which is not much if you do software, but can be a waste of silicon if all you want is a MAC. If you already spent real estate on AES, then CMAC becomes a lot more attractive...
This is the reasons it's at the core of SCP03, the smartcard world is very sensitive to transistor count...
> Avoid: designing your own encrypted transport, which is a genuinely hard engineering problem; using TLS but in a default configuration, like, with “curl”; using “curl”, IPSEC.
I'm not sure what they're saying here. Is there a problem with the way curl handles TLS?
[+] [-] weinzierl|8 years ago|reply
[2] RSASSA-PSS with SHA25 or MGF1+SHA256 in tricolor systemic silicate orientation
[3] 2048-bit Group #14 with a generator or 2
[+] [-] tptacek|8 years ago|reply
I regret the error (but not the recommendation; don't make your own custom RSA-based transport protocol).
[+] [-] tptacek|8 years ago|reply
I love that I can't instantly tell which of those three footnotes is a real thing.
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] tptacek|8 years ago|reply
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.
[+] [-] evrydayhustling|8 years ago|reply
BUUUUUT I can't help reading these and being reminded of Vernor Vinge's "Net of a Million Lies", where people looking for shortcuts end up getting traps. We know that state actors have haunted academic and industry efforts to disseminate info and implementations of cryptography, inserting weaknesses -- resulting confusion is part of why we need guides like this.
How do we know when we can trust a "new media" guide like this one? Can non-practitioners adopt tests that inexpensively verify validity of suggestions like these? Is HN (now with "fight me" threads!) state of the art social proof, or are there other ways to incentivize expert review (without exposing those same experts to centralized influence)?
For clarity, I'm explicitly NOT suggesting this guide is a trap -- I sure has heck wouldn't know, but I don't think so and will be using it :) Just getting meta.
[+] [-] web007|8 years ago|reply
I've loved the CryptoPals series, even just reading the challenges for the more advanced parts while I poke at the easier stuff. Please keep them up, and hopefully I'll get all the way through "Shackling the Masses with Drastic Rap Tactics" someday!
[+] [-] throwaway1619|8 years ago|reply
[+] [-] michaelt|8 years ago|reply
However, this article says "Don’t do ECDH with the NIST curves" and "really, especially avoid conventional DSA and ECDSA".
How bad is it really? I mean, the article's pretty unequivocal, it sounds like using that crypto element isn't a very good idea?
[1] Motivation: Users can completely reprogram application processor without wiping (or being able to extract) the private key. [2] https://www.microchip.com/wwwproducts/en/ATECC508A
[+] [-] schoen|8 years ago|reply
What's bad about cipher cascades?
(No, I don't current encourage people to use them and I tell people that there's some expert sentiment discouraging them; I want to remember the basis of that sentiment.)
[+] [-] asd2r23dasd|8 years ago|reply
Beyond that: developers aren't normally tasked with building systems out of cryptographic primitives. Those that do are typically (hopefully!) experienced enough to pick a solid primitive.
Those who need to look-up which primitive to use need to know that the security of the final system is primarily going to pass or fail on the _composition_ of those primitives rather than the particular choices.
What would be really cool would be a document that takes common use cases and describes how best to build in the cryptographic aspects of the security. Edit: e.g. a good list of OpenSSL ciphersuites and SSL_CTX_config() blah calls for server auth and mutual auth is probably the biggest bang for buck you can get.
I don't want to come across as critical of the effort or correctness --- but I do I think people really need to hear the danger klaxon when they're doing more than just editing a TLS configuration file. Composition of primitives is really hard.
[+] [-] alexkon|8 years ago|reply
[+] [-] lmm|8 years ago|reply
If I want to do asymmetric encryption/signatures and am terrified of the security implications of non-memory-safe languages and/or libraries written in them, do I have any good options? (i.e. is there something I could use from a JVM or an OCaml unikernel or the like?)
(I would ask the same thing about website security and transport encryption, but honestly I'm going to stick with ocaml-tls whatever you say)
[+] [-] jfindley|8 years ago|reply
Is this because you think the side channel isn't that important, or that getting the params for argon2 right is complex enough that you're cautious about recommending it more strongly, or is there something else that I'm missing? Apologies if you answered this elsewhere - I had a look and didn't find anything.
[+] [-] andrewflnr|8 years ago|reply
I recently ran into some HMAC-based crypto that I thought was pretty sketchy based on the "no custom crypto" principle, but I'm wondering if my concerns were overblown. I haven't found any obvious holes in it, but I'm not an expert so I don't know if that means much.
[+] [-] pvg|8 years ago|reply
[+] [-] suf|8 years ago|reply
[+] [-] bsder|8 years ago|reply
> you can use STROBE and a sound, modern, authenticated encryption stack entirely out of a single SHA-3-like sponge constructions.
Or I can go grab TweetNaCl. Is there any reason to use something else?
> Speaking of AKEs, there are, like, 30 different password AKEs you could choose from.
Each with it's own specific (often multiple) footguns. I haven't found any good AKE implementation that I trust for embedded devices.
[+] [-] garmaine|8 years ago|reply
Also, deterministic signing nonces have NOTHING to do the DSA/ECDSA vs alternative signatures scheme. The library you recommend just uses its own deterministic signer internally, just as any ECDSA implementation can and should (e.g. bitcoin’s does).
[+] [-] JoachimS|8 years ago|reply
RFC 2014 defines HMAC with different hash functions such as HMAC-MD5 and HMAC-SHA1. All are valid HMACs. There are other versions of HMAC with for example SHA-256, SHA-224, SHA-512/256 etc defined.
[+] [-] marknadal|8 years ago|reply
Advice/pointers? Here is our setup:
ECDSA sign/verify P-256;
ECDH enc/dec P-256;
PBKDF2 password + salt = extension, using SHA-256, 5000 iterations, 64 ks;
private key encrypted with PBKDF2 extension via AES-CBC
But it isn't like WebCrypto gives you access to much else. So given browser constraints, what are your thoughts?
Thanks!
[+] [-] indigochill|8 years ago|reply
[+] [-] arkadiyt|8 years ago|reply
[+] [-] gshayban|8 years ago|reply
[+] [-] iamwil|8 years ago|reply
[+] [-] gue5t|8 years ago|reply
[+] [-] keithwinstein|8 years ago|reply
(1) It blocks if the system has just booted and the kernel has not yet collected enough entropy to initialize the entropy pool. (Good on VMs, embedded systems, etc., where there's a risk that the initial state might be identical.) It would be nice if Linux had a file-based /dev/uxrandom that waited for the CSPRNG to be properly initialized and then behaved like /dev/urandom, but, it doesn't.
(2) Unlike getrandom(), you don't have to read the long section on "Interruption by a signal handler" or know about the special-casing for small buffers or even think about what to put in the flags argument -- getentropy() doesn't have a flags argument.
(3) Performance is a bit better than opening /dev/urandom, reading some bytes, and closing the fd, and you don't have to be careful about making sure the fd gets closed no matter the control flow. Performance is probably similar to keeping a persistent /dev/urandom fd open, except that has its own minor hygienic issues (especially in library code or multithreaded code). There are a lot fewer error-checking steps in one call to getentropy() than in opening, reading, and closing /dev/urandom.
(4) getentropy() and getrandom() are available even if /dev isn't available or whatever (like in a sandbox, etc.)
[+] [-] lvh|8 years ago|reply
I feel like currently there are slightly fewer ways you could open up /dev/urandom and screw it up (you mention a few valid ones -- but now you're doing feature detection) and it's incidentally cross-platform (dev on macOS, deploy on Linux: super common) so I'm pretty comfortable with it still being the default. Maybe not in the 2020 version -- we'll see. I mean sure you can run out of fds and maybe /dev/urandom isn't (1, 9) but if those things happen you're already on your last legs :-)
[+] [-] loup-vaillant|8 years ago|reply
On which systems is getentropy() available? My Ubuntu 16.04 doesn't seem to have it.
[+] [-] masklinn|8 years ago|reply
It could even do that for urandom already. IIRC that's what BSDs do.
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] loup-vaillant|8 years ago|reply
---
Edit: Note to self: don't promote your home made crypto around famous people. (I'm way past home made at this point, but since there is no way to tell from the outside…)
Edit2: Seriously though, why? It can't just be because I veered off topic.
---
Shameless plug: glad my own https://monocypher.org satisfies most of this, but we do have a couple departures:
Encrypting data: Monocypher provides an XChacha20 + Poly1305 AEAD construction (copied straight from the RFC 7539). Why not XSalsa20? Because XChacha20 has a little bit more security margin, and is a little bit easier to optimise.
Symmetric "signatures": Monocypher provides Blake2b, which provides a keyed mode for this. Blake2b doesn't need HMAC.
Hashing Algorithm: Blake2b again, because it's faster and immune to length extensions attacks. I'm not sure why they still recommend SHA-2. Isn't Blake2 mature enough by now?
Password Handling: Monocypher provides Argon2i. Close to the top of the list, but not quite.
Asymmetric encryption: Monocypher doesn't have a box-like construction, but it does have a key exchange function, which combined with AEAD does the same thing as NaCl's crypto_box(). This makes the library more orthogonal, and I assumed combining key exchange and AEAD wasn't error prone.
Asymmetric signatures: Monocypher defaults to EdDSA, with curve25519 and Blake2b. Why no SHA-512 instead? Because I already have Blake2b, which is faster, and I didn't want the bloat. (Ed25519 is provided as an option)
I hope those departures are boring enough.
[+] [-] weinzierl|8 years ago|reply
[1] http://www.daemonology.net/blog/2009-06-11-cryptographic-rig...
[2] https://gist.github.com/tqbf/be58d2d39690c3b366ad
[+] [-] victork2|8 years ago|reply
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?
[+] [-] piracykills|8 years ago|reply
I'd also question the backup solution, I think Restic is a better option due to its flexibility, I can do cheap backups to B2 and fairly reputable people seem to be approving of its cryptography:
https://blog.filippo.io/restic-cryptography/
If anyone sees a reason why Tarsnap would be better (other than Percival's brand), I'd be quite interested.
[+] [-] jstanley|8 years ago|reply
> If you could use KMS but encrypting is just a fun weekend project and you might be able to save some money by minimizing your KMS usage, use KMS. If you’re just encrypting secrets like API tokens for your application at startup, use SSM Parameter Store, which is KMS. You don’t have to understand how KMS works.
Paragraphs like this come across quite condescending, and the tone might have more to do with the lack of adoption of the ideas herein than the content does.
Security Professionals seem to have an unfortunate habit of talking down to everybody else.
[+] [-] ryan-c|8 years ago|reply
[+] [-] jamesdsadler|8 years ago|reply
What are the classic/authoritative texts in this space?
[+] [-] Xeoncross|8 years ago|reply
I just found that AES-CTR + HMAC is very simple and doable in in languages like Go and Javascript for large objects which can't (or shouldn't) all be put into memory at the same time. In fact, a popular google drive client uses this: https://github.com/odeke-em/drive/wiki/End-to-End-Encryption
(assuming standard secure key generation for both the AES-CTR stream and the HMAC - along with a unique IV)
However, reading this article it seems this might no longer be recommended.
[+] [-] vandot|8 years ago|reply
True for so many things.
[+] [-] raesene9|8 years ago|reply
with https://crypto.stackexchange.com/questions/56448/can-keyed-c... as a reference :)
[+] [-] exabrial|8 years ago|reply
Also, while I don't believe NIST is a mouthpiece for the NSA, I'm curious why they haven't proposed some alternatives to P-256, given some of the difficultly implementing it correctly. Is anyone aware if they are working on this?
[+] [-] RcouF1uZ4gsC|8 years ago|reply
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.
[+] [-] lvh|8 years ago|reply
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.
[+] [-] tptacek|8 years ago|reply
[+] [-] technion|8 years ago|reply
In September 2017 I had an executive pay Gartner a lot of money for a report on encryption and the result was I was directed to use Blowfish. This is obviously a ridiculous example but it's nigh impossible to get libsodium past a marketing team because they want to hear the letters "AES".
[+] [-] chme|8 years ago|reply
[+] [-] rphlx|8 years ago|reply
Is that just historical - i.e. a tiny chance somebody is still using the broken Debian version from a decade ago - or is there actually something still insecure, or at least suspicious, even in 1.1.0+?
I ask only because getentropy() is not widely available in the Linux world yet, and getrandom() - and direct use of the /dev files - do have some caveats of their own.
[+] [-] brohee|8 years ago|reply
This is the reasons it's at the core of SCP03, the smartcard world is very sensitive to transistor count...
[+] [-] charonn0|8 years ago|reply
I'm not sure what they're saying here. Is there a problem with the way curl handles TLS?