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).
I regret the error (but not the recommendation; don't make your own custom RSA-based transport protocol).
I think this is our largest point of divergence. If the world had sane TLS libraries, I would absolutely say "run TLS with all the backwards compatibility crap turned off" -- but we don't have sane TLS libraries. I am not confident in my ability to turn off all the unwanted "features" of SSL/TLS stacks, and I'm not confident that anyone can write code which will turn off all the unwanted features and keep them turned off in future library versions. It's not much of an exaggeration to say that I consider the OpenSSL maintainers to be actively hostile; if I have to run their code at all I really want it to be inside a sandbox.
Yes, writing your own transport protocol is nontrivial. But if you write your own transport protocol, you don't need to worry about "the user upgraded to a new version of OpenSSL and now your connections are all HeartBleeding". A sane library would have had this feature turned off by default; OpenSSL is not a sane library.
Password handling: I skip bcrypt because the only reason to not use scrypt is if you need a US Government endorsed scheme. But yeah, it's (slightly) better than PBKDF2.
Cryptographic primitives: I think "use NaCl" is cheating a bit as far as answers go; that may be reasonable advice to implementors but it's not a protocol specification. So I'm reading those as "use foo, via the NaCl library".
As for what the foo in question should be: I'm gradually becoming more comfortable with curves, and 25519 in particular; similarly with sbox-free symmetric crypto (e.g., djb's dances and Keccak). At this point I'd say it comes down to how conservative you are; I wouldn't say that someone using XSalsa20+Poly1305 is wrong to do so.
To be pedantic, Keccak does have a 5 to 5 bit S-box. But like 3-Way, NOEKEON, Serpent, etc, it's disguised---bitsliced---as a short sequence of boolean operations.
Is there not a recommended replacement library for OpenSSL? I'm thinking of LibreSSL for example that has leaner API but probably not the same amount of resources as OpenSSL.
Go's tls library is fine, but that's not really an OpenSSL replacement. Just use OpenSSL. BoringSSL is fine if you're its audience, but if you are you don't need me to tell you that :) Finally: LibreSSL is the result of a set of circumstances that have changed.
If you're looking for a recommendation: just use OpenSSL and keep it up to date.
It's a joke. The joke is that RSA seems familiar, comfortable. Except actually there's a bunch of super subtle ways to mess it up, like padding, or primegen bugs. The bzzrt pop is just a reference to all of the exceptions and caveats, which all sound like arcane incantations instead of straightforward recommendations and are therefore no longer in this document.
Percival 2009 is http://www.daemonology.net/blog/2009-06-11-cryptographic-rig... - the actual summary recommendation is "Use RSAES-OAEP with SHA256 as the hash function, MGF1+SHA256 as the mask generation function, and a public exponent of 65537. Make sure that you follow the decryption algorithm to the letter in order to avoid side channel attacks."
I assume the misquote is making fun of how long that description is compared to, like, "Use 256-bit AES keys." or "Use OpenSSL." (What specific thing in the decryption algorithm should I be making sure I don't misread in order to avoid side channel attacks?)
That, and the fact that nobody who uses RSA appears to follow that recommendation --- by far the most common RSA construction is (broken) P1v15 padding.
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.
I don't think HN is good enough. On the (rare) occasions when tptacek does post something wrong, it gets massively upvoted anyway because it's tptacek. (I've even seen posts that boil down to "don't you know who I am?" get upvoted)
No-one is trustworthy enough to outsource the whole industry's security to - not tptacek, not djb, not AWS, and certainly not me. I think the key is to take not just the recipe but also the rationale. Someone who tells you "Don’t use RSA." might as well be working for the NSA. Someone who tells you "RSA has too many knobs. In modern curve systems, like Curve25519, everything is pre-set for security." is at least making a coherent argument that others can criticize - they might still be wrong, but the fact that they're being substantive is a positive step.
I think the time to bring up erroneous posts, is in the thread in which they occur. And as long as we are talking "substantive," how about citing tptacek's incorrect posts instead making vague references?
Even the dumbest of us know tptacek is not infallible, though I do hope cperciva and tptacek revisit this thread.
> I think the time to bring up erroneous posts, is in the thread in which they occur. And as long as we are talking "substantive," how about citing tptacek's incorrect posts instead making vague references?
I did bring them up in the threads they occurred in. Not wanting to reopen those old discussions is precisely why I didn't talk about specific examples or give links.
Surely HN counts as some form of public scrutiny. If all of us are compromised, then yeah, you're fucked. But we've tried not speaking up and telling people to leave it to the pros and we got like a decade of CBC padding oracle bugs so that didn't work out and now we're trying to at least give people a fighting chance to stay on our professional opinion of the straight and narrow.
Disclaimer: I'm a co-editor of the new version of the document and also a principal at Latacora and therefore clearly an NSA stooge ;-)
Yeah, I'm mostly thinking about about taking what works about HN and naming it or even extracting / concentrating it. Some thoughts about what that is:
- individual views and reps
- open to competing interests
- signal / noise ratio
There are waaaayyyy easier and cheaper ways to get your private information than by a massive, distributed covert operation designed to make your encryption implementations slightly easier to brute-force.
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!
DJB's primitives are generally simpler than what came before. They're easy to implement, pretty easy to immunise against timing attacks, and relatively easy to review.
So we're not just trusting DJB here. We're trusting a sizeable community that reviewed his work.
I don't think there's a problem with djb monoculture, and I geerally agree that the real enemy is "yet another !@#$%! CBC padding oracle attack". It's not like these things haven't been analyzed by third parties.
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?
These services offer hardware bound keys, are maintained by O(hundreds) person security orgs (read managed auth[n/z], audit, intrusion/tamper detection, backup, etc...), stored in data centers with strict physical security. For the majority of private sector, the benefits of these services outweigh the cost of trusting the key holders.
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?
Invalid curve attacks will leak your secret key, which most old implementations (i.e. the ones likely to end up in your hardware) don't protect against.
If you reuse an ECDSA nonce, you will leak your secret key.
If you have even the smallest timing leak, guess what.
Essentially, a bunch of ECC implementations didn't do proper bounds checking and leaked data. ECC still offers a lot of benefits in terms of key size, performance, and security, however, so do your research carefully.
The reason for the recommendation is this: if you're using $SAFE_RECO, I don't need to think twice if what you're doing is fine.
If you're doing ECDSA or ECDH over P256, it might be fine. It might also be a complete disaster. So, we don't recommend it -- and if you must, you should have someone audit it for you, because you're not in the safe zone anymore.
(Examples of disastrous failures: P256 off-curve attacks, unsafe k choices for ECDSA.)
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.)
The dangerous part about implementing payload encryption isn't the cipher; mainstream modern ciphers are quite strong and bear few caveats. What's dangerous about encrypting are the constructions you use to apply ciphers to actual data (the "modes", though this is a terrible term that needs to go away).
Cascading ciphers does nothing to address the dangerous part of encrypting (order of operations for authenticating, authenticating all the security-sensitive components of the message, validating authenticators safely, randomizing encryption, safely handling truncation of authentication tags, providing adequate headroom for nonces, &c &c). In fact, since the best modern authenticated encryption constructions tend to be built up from a single cipher core (usually AES), cascades make encrypting safely harder.
You could "cascade" authenticated constructions, but different constructions have different failure modes. The poly MAC constructions fail and cough up authentication keys. Some gracefully handle truncation and some don't. Some constructions fail somewhat resiliently if nonces get repeated; some explode; some purport not to seriously fail at all. Some of them can reliably be implemented in software on any platform, but the binary field stuff really wants hardware extended carryless multiplication or you get new side channels. These things aren't designed to snap together in cascades and smushing them together doesn't make a lot of design sense.
It's hard to get this stuff right even when you're making the conventional, boring choices. Cascades involve a lot of "not boring" stuff, and the payoff for that not-boringness is arguably homeopathic.
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.
Usually, when I think composition of primitives I think MtE vs EtM vs M&E; but that feels like something that's covered. There's also protocol design, but that's also covered ("use TLS"). Can you give an example of the sort of composition you're talking about?
FWIW I'm more hopeful that I can make mTLS work immanently as part of the environment than everyone getting it right in their app. Less httpd more caddy, if that makes sense :)
Maybe an quick example off the top of my head would be: you know you need to authenticate and perhaps additionally 'encrypt' something --- for say a software update, fancy over-Bluetooth authentication scheme etc.
You need to pick: symmetric or asymmetric schemes? Auth then encrypt? What does replay of an old signature or MAC mean for your system? Key usage limitations? Key re-use? Quite a few ways you can err where the choice of e.g Ed25519 over P-256 ECDSA pales in comparison.
Or in other words: most people are trying to build a secure system, and where security is only achieved by the combination of the protocols, primitives used.
W.r.t TLS, yeah, bake in default configs as part of an environment where you can, although there'll always be plenty of people developing directly against the software API, and compatibility issues will typically play a part.
When I figure out how to pour that in a document I'll let you know :-D Until then it's one small bite at a time. But yeah, you're right: this is the style of audit and design work we do for clients.
General reco from your list: the answer is always symmetric unless you literally can not accomplish the same thing any other way. (And you probably can.)
Asymmetric crypto (RSA, curve25519, etc.) and Diffie-Hellman (including ECDH) are both in danger, thanks to Shor’s algorithm. I think the only thing remaining is large-enough quantum computers.
If I remember correctly, hashes and symmetric crypto are generally safe, and so those recommendations shouldn’t change.
The effective keysize for symmetric crypto can be cut in half by quantum computers by Grover's algorithm, so just make sure you use 256-bit keys rather than 128-bit keys.
> I think the only thing remaining is large-enough quantum computers.
That’s a very, very big “only” :).
In any case, there are several compelling computational problems which are (as of current research) post-quantum resistant. They’re based on lattices, error correcting codes, hashes, multivariate polynomials and supersingular elliptic curve isogenies (the latter one being the hot new thing).
Each of those problems has at least a few (but generally many) viable contenders for actual cryptography. Hashes give us very nice signatures, from old-school Winternitz one time signature to merkle trees to current frontrunners like SPHINCS (and its variants). Unfortunately hash-based cryptography can only be used for signatures so far, but they really excel at that.
The ring-LWE problem (and more generally, module-LWE) in lattice cryptography is pretty versatile: we can get fast encryption, signature and encapsulation schemes. The tradeoff is that key sizes run larger. But there is a lot of research into provable security in average-case and worst-case lattice assumptions. The NTRU problem is the other large “school” of lattice cryptography, which mostly has the same problem: very fast, but with larger key sizes.
Error correcting codes give us fewer computational problems to work with than lattices (essentially general decoding and syndrome decoding), but they are extremely well-studied. McEliece remains secure (for binary Goppa codes), which is incredible because it was published only two years after the notion of Diffie-Hellman PKE. Unfortunately most types of error correcting codes are not suitable for cryptography because they have excessive structure. We’ve been mostly stuck with binary Goppa codes for 40 years, though there is exciting work on quasi-cyclic and quasi-dyadic codes in the NIST PQ CFP. Otherwise, similar story as lattices: relatively fast, but very large key sizes.
Isogenies are extremely new and only have a few credible cryptosystems based on them. The most prominent researchers leading this domain are Jao, Longa, de Feo, Plut and Galbraith. The two contenders are SIDH and the NIST proposal succeeding it, SIKE. These have the opposite advantage to lattices and codes, because their key sizes are incredibly small (the smallest among all post-quantum cryptosystems), but their key exchange time is commensurately slower. The additional benefit is that they use much of the same mathematics as traditional elliptic curves, which means you could design hybrid ECDH-like and SIDH-like schemes with a relatively small library.
There are some wonkier proposals (such as Joux’s Mersenne prime one), but these are the ones receiving the most research attention. I wouldn’t say it’s a solved problem, but I’m personally confident there will be mature cryptography available when quantum computers can practically break our current state of the art.
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 get it. But libcrypto is less likely to have some insane UAF bug than, say, libtiff or whatever. If you're going to use unsafe code, libcrypto and libsodium are pretty great choices. I wrote a Clojure (so JVM) library that binds libsodium FWIW.
- I hear nice things about Rust's ring lib. Still gotta FFI from OCaml or the JVM though.
- A lot of the recommendations on this list are algorithms designed to be safe to implement. For example, it's unlikely that a JVM impl of XSalsa20 + Poly1305 is suddenly unsafe because of the environment you're running in. This is NOT TRUE for things like AES-GCM; firstly a lot of naive AES implementations are insecure, and good luck doing GHASH safely in software.
My advice regarding crypto code that needs to run in Javascript in a web browser has not changed: don't design systems that depend on crypto running in a web browser.
The rest of this should be fine in a native phone app.
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.
Any of them are fine. I don't think cache timing side channels or any of the other fun scrypt trivia (like PBKDF2-induced trivial collisions) are how you're gonna get popped.
I guess that's fair - thanks. I'd previously stayed away from scrypt as a password hash because of these attacks (although I've used it a bunch as a KDF for other things) - but on reflection I think you're probably right and if this is the worst issue you have you're doing fairly well overall.
I don't get the rationale for Argon2id. If you don't expect (cache) timing attacks, Argon2d is computationally stronger. If you do, Argon2i is immune. Argon2id is partially immune, so if someone can do timing attacks, they can crack half the algorithm, and need to do the rest the hard way.
What is the rationale behind the assumption that this middle ground is better than straight up Argon2i for general purpose password derivation? I've never seen it explained anywhere.
Not everyone who needs to store a password is in a position to judge if cache timing attacks will never be in their threat model. Sane recommendations for people who would like to just not mess up their password database matter.
I'm assuming you're familiar with the Argon2 RFC sections on Argon2id? I think it goes into quite a bit of detail between the two.
OK, the latest version of the RFC is much better than what I had initially read. Still, I see no discussion of side channel attacks with Argon2id. When they discuss the "best attack", it looks like they're discussing offline attacks that makes no use of timing information.
Assuming timing attacks breaks Argon2d entirely at relatively little cost, the attacker advantage for a 1-pass Argon2id would be twice that of a one-pass Argon2i: about 10. A three pass Argon2i with a third of the memory looks better: about 3. Not that it matters that much, but still.
Or is my threat model of timing attacks (which assumes they could recover whatever they can at little cost) too paranoid?
I think the RFC suggests sufficiently conservative parameters that it doesn't matter much. And, more generally: I don't think Argon2i vs Argon2d vs Argon2id vs scrypt is where people should be racking their brains.
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.
HMAC will, hell or high water (assuming you're not doing HMAC-CRC32 or whatever :-)) give you a MAC. (It'll do slightly better; unlike, say, GMAC -- but that's a boring detail for now.)
You can shoot yourself in the foot with HMAC but it won't be because of HMAC; for example: if your messages don't contain a nonce or timestamp they might be replayable or something. But that's not an HMAC flaw.
So to answer your question: maybe? You can get in plenty of trouble with HMAC, but it won't be HMAC's fault.
Also if you don't use an unambiguous encoding if you're signing multiple aggregated fields. Either by using field separators that can't occur in the data, or by using a format that prefixes fields with their lengths.
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 :)
Does this hold for other AWS services that manage https endpoints? Especially Cloudfront which seems to be the de facto solution for anything serverless. Integration with ACM obviously also comes out of the box, but I haven’t looked under the hood at the implementation (besides IIRC a « you can have any color provided it’s black » approach to security options)
I'm not sure I follow with Cloudfront <-> serverless but generally: sure? I don't like giving blanket recommendations when I haven't audited everything I'm recommending but generally speaking: yes.
By cloudfront and serverless, I mean that if you want S3 hosting + https you need a Clousfront distribution. If you use a custom domain name with your API GW there’s a Cloudfront distribution created behind the scenes. And I believe the same holds for Lambda@edge. In other words, if you’re not relying on VMs + ELB (or Elastic Beanstalk) to host your application, it seems that the only way to use an https certificate is through Cloudfront.
I've been working on ELB day-to-day since 2013, first as Principal engineer and now as one of the AWS services I focus on and help out. I do have some special insight - feel free to AMA.
I can get pretty deep on the TLS/SSL side if you have specifics; I'm also the main author of s2n, our Open Source implementation of TLS, and a participant in the TLS1.3 process.
Hey, this is largely off-topic but worth a punt: do you have any info on when AWS IoT (maybe other AWS services as well?) will move off the dependency on the Verisign RSA/SHA-1 CA? I'd love to get a certificate chain that was ECDSA or RSA sigs only (and would also love to be able to turn off SHA-1 for the obvious reason).
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.
Monocypher is portable (C99/C++), pretty fast, and has low memory footprint (generated binary between 30kB and 60kB). Problem: it isn't trusted yet. (I'd like to run a bug bounty, but I'm not sure how I should go about it.)
TweetNaCl is portable (C89), has low memory footprint, and is made by trustworthy professional cryptographers. Problem: it is slow.
Libsodium is blazing fast on modern processors, has portable implementations, and is trusted. Problem: it is pretty big, and I hate the auto tools.
Edit: of course, those recommendations only hold if you have a trustworthy RNG.
Take Monocypher or TweetNaCL, and rip off any primitive you don't need. This may be enough. Even when you take the whole thing, Monocypher only needs 30kb of x86-64 machine code when compiled with -Os. If you only keep authenticated encryption and x25519, which are enough for many uses, I think you should be able to halve that down to 15kb or less.
If speed doesn't matter, TweetNaCl is even smaller.
If those aren't enough still, you may want to dive in, learn a ton about crypto (starting with https://www.crypto101.io/), and investigate the sponge construction, whose versatility may allow you to shrink the code even more. Perhaps. I'm in over my head at this point.
Neither of those libraries uses any extensions. TweetNaCl is a famously minimal implementation of NaCl in portable C by the NaCl authors. Monocypher is a library 'loup-vaillant wrote as a sort of side project. TweetNaCl does see some use, but libsodium is the most popular NaCl implementation, and libsodium's author provides his own low-footprint misuse-resistant crypto API separately.
Neither TweetNaCl nor 'loup-vaillant's library really addresses the low-footprint concern.
When you're that small it really requires more context. What are you trying to do?
I've deployed TLS in 50 KiB flash and 6 Kb RAM. But I could rely on hardware support for some public key operations and could pick a single ciphersuite, and controlled the server end as well.
The boring answer is that you'll need to identify the set of primitives you need and then find a library that matches. I can't think of any single primitive that would break that budget, so it'll depend on how many you need!
1. How much of your flash budget is eaten up by the application?
2. What performance do you need for different use cases and operations?
Generally, RAM is often the least of your problems. And if you are into Cortex M0 or even M0+ territory, your MCU will quite probably sport an AES-128 core. Even if it is slow you should try and use that.
I'm not yet to the point where I can recommend my thing without even mentioning the other two competitors. I did get bloody thorough, though, and I do think it is good enough for me to bet my job. (Meaning, I'd be willing to lose my job if my employer uses Monocypher on my watch, and data gets leaked because of that choice.)
(As for the original question, I don't know BearSSL enough to have an opinion. It does seem however to get even further than Monocypher on the constant time thing. Monocypher needs the platform to provide constant time 64-bit multiplication. Most do, but not all.)
> (Meaning, I'd be willing to lose my job if my employer uses Monocypher on my watch, and data gets leaked because of that choice.)
Would you be willing to be personally liable for that data leak?
(Put aside the philosophical question of whether or not it's reasonably for developers to be personally liable for their software failures - I'm interested in how far your confidence in your cryptography goes).
Disclaimer: I'm not 'tptacek but I'm one of the Latacora principals and co-edited this document.
Embedded crypto gets weird fast. General recommendations are a little tricky, but: is that device talking to the internet directly or some kind of IoT hub or whatever?
If it's on the raspi side of powerful, just use OpenSSL, or maybe Go's TLS stack, again, assuming you can get away with it.
On smaller systems, things get weird. If you can't afford go/openssl, there aren't a lot of things I'm very confident in. BearSSL near the top of the list. That's still double-digits kilobytes of RAM though, so maybe I just ate all your budget. You might be in one of the cases where a NOISE protocol instance is in fact the right answer; depends a little on what else the box is doing and how frequently.
Sorry, I get that it's not a satisfying answer :-) It's complicated!
Their history of implementation issues leads me to believe that the general upside of TLS doesn’t necessarily weigh up to the upside (and cost!) of a light bespoke implementation. That’s contingent on having someone around who won’t mess this up; failing that, an embedded TLS stack is still a good idea.
I would have told you something differently before NOISE and NaCl, particularly Curve25519. We could have done AESCTRHMACSHA256 a long time ago and be basically a good as XSalsa20-Poly1305, but Curve25519 was a huge leap compared to the DH2048 you were likely to do before.
I don't think you can deem mbedTLS too risky on one hand, and then on the other recommend Noise, with it's slew of unfinished and largely unverified libraries. Outside of the WireGuard RHUL effort for a specific 'pattern' AFAIK the Noise core hasn't really seen any formal analysis either. Commoditizing the DH operation means you can build an enormous amount of AKEs, and even people like Trevor Perrin can make mistakes there.
Noise is potentially very interesting, particularly for the embedded space, but it'll be a while before it's safe to use.
There's another paper besides the RHUL one, which preceded it, using tamarin: https://git.zx2c4.com/wireguard-tamarin/tree/wireguard.m4https://www.wireguard.com/papers/wireguard-formal-verificati... There are other groups who are also currently working on similar and better proofs. I think the end goal is to get proofs of the general pattern language of Noise rather than just the WireGuard handshake (IKpsk2), which will probably then satisfy your concerns with Noise. The Noise project itself is also working on things like NoiseSocket which will be more of an easily pluggable "right answer".
Ah cheers for the link. Yeah a proof at the level of abstraction up from a single pattern would be lovely. I don't really have 'concerns' as such: it's just if your risk profile is the thing that has kicked you away from TLS towards Noise then you need a good justification (notwithstanding, a proof of security for a new AKE should really be par for the course).
IMO the interesting aspect with the development of Noise will be if it can avoid bloat. From the mailing list I can see that there's solid awareness of that risk (would assume Trevor is aware anyway), but it will be interesting to see how the simplicity of pattern API will handle things like signatures, when they're inevitably added. I see at least one Noise-using project has already made the leap on that front.
You’re right that they’ve gotten less scrutiny, but they also need less scrutiny. (I’m not saying more isn’t better.) TLS carries a lot baggage from phlogiston era crypto and is significantly more complex than a dumb NOISE impl.
Note that I qualified my suggestion to “you need to have someone around for that” and that I also mentioned low cost. Specifically, I imagine you’d instantiate NOISE with some boring primitives, ideally in a memory safe language, and spend some time and money pointing Tamarin at it, for example. If you don’t have that, fine, get a tiny TLS stack. I’m just saying that a priori I can’t tell you I have less faith in random mbedTLS-containing ROM vs NOISE-with-reasonable-implementor. (I appreciate that we’re comparing apples to oranges with a concrete ROM vs an abstract protocol.) I also happily appreciate that we’re in territory where the constraints are too restrictive to make blanket recommendations.
Let me rephrase: would you agree that there are platforms that actually shipped with garbage crypto where it’s plausible that they could’ve made NOISE work but didn’t embed a TLS stack because size/perf?
I would definitely agree, yeah. Notwithstanding the legacy protocol core, Noise has great potential to allow people to step away from the asn1, X509 etc TLS cruft.
Comparing between those two options is a question of appetite for risk, your threat model, and the level of competency you have available. On the latter note, _at the moment_, I think the subset of people who are capable of taking advantage of Noise would be largely similar to the same subset you could safely task with designing and implementing a custom AKE+messaging protocol from scratch anyway. I think the level of competency you need available is on the very far end of the spectrum. Edit: and on the risk point, even if the library has been eyeballed less, at least you know with mbedTLS that if a bug drops you'll get a patch pretty quickly. If you goof up your Noise impl you're on your tod.
Appetite for risk, threat model, competency available _and_ platform constraints, IMO. I think we're in violent agreement: you should only do this if you have someone on board who knows what the hell they're doing, and you literally can't afford a decent TLS stack on that device.
Advice for that kind of problem typically requires a lot more context, e.g.:
* You need to do symmetric crypto between two MCUs, where only one has an RNG;
* You need to do symmetric crypto with no RNG;
* You can't rely on your MCU safely storing state / unreliable transports.
Cryptography and libraries/standards are gradually building towards a world in which higher-and-higher level abstractions let inexperienced web/high-level application developers build safe systems. The same isn't really true for the lower-end of the embedded space, and consequently you can't really produce an equivalent set of (reasonable) guidelines like the ones linked.
I think STROBE is quite a bit smaller than TweetNaCl once deployed, in gates or bytes, both ROM and RAM. More generally, there are lots of off-list recommendations that are still fine. The list doesn’t have AESCBCHMAC anymore but I’m unlikely to tell you Fernet is busted.
We could do an elaborate embedded post but the answers diverge a lot more because constraints are tighter. If you’re doing embedded you need a security person around.
The real question is which of these have actually been vetted.
I trust NaCl and, specifically, DJB-associated implementations thereunto. Lots of people have looked at it. I trust DJB and his cohorts to think about and mitigate footguns as much as practical.
STROBE is right about a year old. Maybe it's awesome, but it almost certainly hasn't been vetted sufficiently.
I seem to recall that most PAKE's relied on one of the nice properties that modular exponentiation has that doesn't work for ECC. IIRC, quite a few of the PAKE's tried to use ECC and fell into the trap and created a breakable PAKE.
The patent situation around PAKE's didn't help. Fortunately, those patents just expired.
> If you’re doing embedded you need a security person around.
Apple couldn't even get it right. They implemented an 3072-bit SRP that takes almost 15-20 seconds on Cortex M0/M3 series processors unless you have an exponentiation accelerator (Cortex-M4).
If Apple can't get it right, what chance do those with far less resource have?
A list like the parent article but tailored to embedded would be quite welcome.
My argument was specific to embedded crypto. If I don’t have to care about size constraints then yes, I’m going to make a better-understood recommendation than STROBE. Re “I trust DJB”: if you’re going to trust individual implentors, I suggest that the median cryptographer is going to suggest you can do a lot worse than “literally Mike Hamburg” here. I certainly will.
Re: PAKEs: yes, some PAKEs and related protocols are hard to port to ECC. For example, SRP doesn’t port cleanly from FF to an elliptic curve group because it actually needs a field. But I called out SPAKE2 for a reason: porting SPAKE2 to ECC is easy.
I suspect its lingering litigation distrust of RAMBUS and association with Stanford connections.
RAMBUS got shafted by the DRAM manufacturers, but they pulled a LOT of shady crap of their own and Stanford was in the thick of it.
While I have no belief that Mike Hamburg was ever in the middle of that, I have some concerns about what might or might not be patented once RAMBUS's lawyers get done with it.
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).
You suggest using Ed25519 which is vulnerable to third party signature malleability as its cofactor is 8 and the library doesn’t check that the signature is actually a point in the curve.
On the other point, then don’t list deterministic nonces as a comparative advantage since it is not actually distinguishing.
That's fair: we don't alert users that these recommendations aren't adequate for building elaborate new signature schemes. We're assuming people are trying to solve the basic problems described in the use cases we wrote (remember, this document originates as a response to a similar thing Colin Percival wrote a long time ago).
I'll think about a way to articulate that. Obviously, we can't really offer advice on doing state-of-the-art signature schemes in a couple paragraphs, and would not be interested in trying.
On the other point: the 2015 version of the document addressed the point you're making (and recommended deterministic DSA!). I just think it's kind of dumb to design new systems with a DSA dependency in 2018, and so rescinded the recommendation.
As a sort of hand-wavy message board explanation: you design a protocol using public-key crypto with the assumption that any given public key pairs with a single private key and with no other public or private keys.
But that's not true: for both Curve25519 and in the Ed25519 signature scheme, which were designed with curves for which point validation is supposedly unnecessary and thus not performed, there are for a given curve point other points --- not valid ones, but ones for which the math will work --- that are equivalent.
For the kinds of things most developers use crypto primitives for, and most of the things everyone was using them for in 2009, these distinctions are --- I'll argue --- not that important. If your transport protocol handshake blows up because of cofactors, the problem probably isn't that you didn't check curve points; it's that you designed a bad key exchange.
But since I don't do cryptocurrency work, like, at all, it's easy to forget that the mainstream of what people do with signature schemes is a lot broader than it was before. I'll try to think of a way to word that and get it into the document.
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.
That's a good point; as I recall reading it it was supposed to say HMAC-SHA256. But, to be clear: HMAC-MD5 isn't really busted, I just would prefer not to see it in new code.
Exactly. We want to move away from md5 (and SHA-1) and has been trying to do that for many years now. So we should not use it _even if_ it is ok in a specific construction. It adds yet another dependency that makes it harder to remove md5.
5000 iterations of PBKDF2 is very low. I'd use at least 100,000. Benchmark it, but that should be reasonable even on mobile provided you're caching the keys.
Assume it is a NodeJS Electron app that people run locally (and in the future, a browser extension).
(there is also a web version, which of course could always be compromised, but we're encouraging users to download the app so they have full control and don't have to worry about that. But they need to be compatible.)
Telling our users not to use crypto isn't an option. Recommending our users not use a browser is possible, but forcing them not to use a browser isn't an option either.
I don't think you can do this safely without having a security person on board. And there's a chance they'll try to ship a real crypto library in the Electron app.
I'll give it a shot though, some things that come to mind:
* RFC6979 ECDSA or bust
* Have you considered off-curve attacks for that ECDH?
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.)
I might be misunderstanding you, but... 'tptacek and I worked on the 2018 recommendations in the article, and I think we still agree with what we said last week when we edited it :-)
Ah, didn't know he also worked on it. It wasn't obvious in the article.
Then I have two basic questions (for either you and tptacek):
1) Given I just need to hash the contents of a file for content-addressed data (like in git), it seemed like sha2-256 would be sufficient. However, it seemed like on 64-bit machines, sha2-512 is faster, and I can just lop off the first 256 bits. Is that correct? And in what cases would you use sha3-256/sha3-512?
2) Given I need to build an API that authenticates through client tokens, I was thinking of using JWT (json web tokens) with HMAC256, and a payload with a randomly generated token for the at_hash claim, and send it over TLS. Do I need to include a nonce in the payload? If not, it's the same JWT on every client request. If so, how would you recommend generating a nonce?
In the article, under symmetric signatures, you talk about not doing anything complicated with the data you feed into the HMAC. But I'm not sure what the simple construction of this data is. Is it where you say "just concatenate the key and data and hash them and be secure"?
1) Yes, use SHA512/256 (truncated SHA512). I don't think I'd default to SHA3 anywhere.
2) Are you entirely convinced you actually need client tokens? In particular, can you get away with a 256-bit random token and store the session in a database?
3) Re: HMAC input malleability: yep, concat and HMAC is fine. Serializing JSON or whatever is also fine. You're usually providing the tag (that's what the output of HMAC is called) verbatim next to the message, so you generally don't care about e.g. canonical serialization.
2) Hrm. I guess maybe? As I understand it, the reason for a client token is to have stateless servers, so the server doesn't need to look up a valid token upon every request--which scales better. In my case, the API endpoint is for something that doesn't (and won't) get a lot of traffic, so I can probably get away with a 256-bit random token over TLS? Since it's over TLS, there probably aren't MITM attacks to sniff the token and replaying it--so it's probably ok? Are there other considerations I'm not aware of?
It's not always a foregone conclusion that it scales better. I've seen people argue that when using ECDSA verification that's 4x longer than an in-DC RTT. Usually: DB kv lookups aren't even close to the most expensive thing your app does.
Generally: don't do encrypted tokens. If you must: don't do JWT for this. Just secretbox a thing and be done with it, or use PASETO[0].
A lot of the implementations _aren't even faster_, but the laundry list of security bugs they have caused is very real. Suddenly you get to worry about irrevocable tokens in order to solve scaling problems you don't have.
> However, it seemed like on 64-bit machines, sha2-512 is faster, and I can just lop off the first 256 bits.
Just as a heads-up, SHA-512/256 isn't exactly just SHA-512 with 256 bits chopped off. It also uses a unique IV. This might not be a big difference in practice, but I'd lean toward using SHA-512/256 explicitly, and not SHA-512 truncated to 256 bits.
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 :-)
If you have a modern version of Python, you can do:
import secrets
secrets.token_bytes() # returns a randomized token
You can pass in the number of bytes you want, but I would think it would be better to rely on the default (presently 256 bit). This module is intended for cryptographic purposes. There are also helper functions to get a hex string or a URL safe string back.
It is getrandom(2) on Linux, similar to getentropy(2) on OpenBSD. It should be in 16.04, it is kernel 3.17+ although it was not added to glibc until recenrtly so you might have to use the syscall directly.
getentropy(2) exists on Linux. I do not know when it was introduced, but my Arch system has it. (I feel as if your comment implies that it is the BSD equivalent to getrandom(2).)
> 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.
It could, in the sense that anything is possible, but that isn't the behavior the Linux kernel community has chosen. And they are pretty good about not changing published interfaces at this point. At least getrandom(2) provides the sane behavior (and does not require an fd or filesystem namespace access).
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.
E.g. "I have an API key and I want it encryptedly available to some servers, and engineers to be able to roll but not read the cred", KMS directly with a CMK is great. Otherwise: that's what the rest of the bulk encryption and key generation recommendations are for; get a DEK, use NaCl's secretbox or whatever.
DEK sharding strategies depend on your data model so that gets a little tricky to provide good advice for in this document but that's something we help clients with, sure :)
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.
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:
Yeah. Here’s my situation, which I don’t think is especially uncommon:
- My laptop has a 1TB disk, which is mostly full. I want to back it up.
- Some of the data on it is sensitive. The vast majority is not - for example, a large fraction of the disk is taken up by torrented anime videos - but I don’t want to separate out only the sensitive data to back up securely. Not only would that be inconvenient, it would be wildly insecure, since I’d presumably want some other, potentially less secure backup solution for the rest of the data, and it’d be really easy to miss some sensitive data and have it accidentally included in the insecure backup.
- Storing 1TB of data on Tarsnap for a year costs $3,000 (though after deduplication and compression there should be somewhat less than 1TB).
- Storing 1TB of data on Amazon Glacier for a year costs $48, which can be combined with various open-source encryption tools (of varying quality).
- Backblaze’s consumer backup product, which I currently use, costs $50 per year for unlimited storage; it supposedly does client-side encryption, though I don’t know how much I trust it.
- One of those prices is not like the others.
- I expect to have a larger disk in the future, and fill it up too; storing 2TB would double the Tarsnap and Amazon prices.
- If Tarsnap actually made the difference between my data being compromised or not, that would be worth $3,000 or $6,000 to me, and I do have the means to spend that much if necessary. But in reality, I’d expect it to only slightly reduce the chance of compromise compared to a high-quality alternative, and I don’t have so much money (or arguably, I don’t value security highly enough?) that I can reasonably spend so much on that small of a benefit.
- Why should you, the author of the post, or anyone else care that I’m stingy? Well, you don’t have to. But I’d certainly appreciate advice from experts about which of the alternatives are the best. In other words, what the right-est answer is that fits my budget constraints, even if it’s not actually the right answer. :) I don’t think the alternatives are all so insecure that it would be irresponsible to recommend any of them.
- I have nothing against Colin personally; indeed, I wish him the best of success. I do think his pricing model doesn’t do a great job representing his costs, since the time he spends maintaining the Tarsnap software and servers, and providing support, doesn’t scale linearly with the amount of data stored. But there’s no rule it has to; it’s his choice. It’s just that the result is a service that isn’t for me.
Restic's threat model assumes trusted systems - the ability to make a backup also implies the ability to destroy and tamper with existing ones. Tarsnap has fine-grained access controls which can severely restrict hosts:
e.g. you may give each host their own write-only key so they can automatically create new snapshots, while keeping the keys that permit reading and deleting old snapshots on separate machines with separate passphrases.
> But, seriously: you can throw a dart at a wall to pick one of these. Technically, argon2 and scrypt are materially better than bcrypt, which is much better than PBKDF2. In practice, it mostly matters that you use a real secure password hash, and not as much which one you use.
It’s not so much a strict order of preference as it is a preference, any preference, so as to still be recommending things. Argon2 and scrypt are too close to call.
I'm under the impression Argon2 is at least marginally better than scrypt as it has heavily analyzed side channel mitigations and such. Is scrypt better in some other way?
Argon2 and the PHC precipitated a lot of analysis that increased our confidence in scrypt, too. My point is that it doesn’t really matter, so optimize for availability. I like Argon2 for the stamp of approval, but dislike all the confusion around parameter selection and i-vs-d confusion. (I know argon2id exists.)
Doesn't scrypt suffer from much of the same parameter selection issues? I know I've had to choose some fairly obtuse values when using scrypt for login in a webapp.
In fact, taking a quick look again I find Argon2's "memorySizeKB" and "iterations" make much more sense to me than scrypt's "CostFactor" and "BlockSizeFactor" parameters as it's a lot clearer what's being impacted. I agree with the i-vs-d confusion, but in most cases I think using argon2id as you mentioned should resolve the contention as is already the suggested default in the IETF draft.
> We recommend the following procedure to select the type and the parameters for practical use of Argon2.
As opposed to just pick a profile, which, to be fair, the RFC also suggests :) So I guess that’s a fair point, it just feels like as with the i-vs-d thing there’s just more song and dance around it that I wish wasn’t there. The suggestion in the RFC vs published 3rd party recommendations (eg jjarmoc’s NNC reco) are also off by a factor of 100 or so? I’m happy to buy that that’s an unfair subjective impression, but when I was reviewing an argon2id python implementation last week I really just wanted to give people a function that just does “encrypt my damn password already”. Maybe that’s up to the implementation layers job, that’s fine - I did that for txscrypt too and I don’t remember where I got the magic numbers from :)
To be clear in case someone else reads this out of context: I am not saying not to use Argon2id!
I like and use tarsnap (and have for years) but the lack of choice of backends is a downside. I've been waiting for something I can use to backup my workstation and laptops to a server at home as well as a server I have at $work (ISP). I've tried out all the usual applications but have yet to find something I'm happy with.
One of the nicer bits of borg is the ability to restrict it to append-only mode, which limits the damage compromised hosts can do. e.g in authorized_keys:
"Do you get enough control do to that on rsync.net?"
Yes. You have your own .ssh folder in your account and can edit (upload) your keys as you see fit.
Also, if you have our ZFS snapshots enabled, those are immutable/readonly - so even if you aren't using a sophisticated tool like borg, you still have snapshots of your data that are immune to attack - even from someone who knows all of your credentials.
+1 for restic. I've been using it for work-related backups for a while and it works quite well. rclone support has recently been added [0], expanding the number of storage backends available by quite a bit.
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.
Did you feel that entire graf was condescending or just parts of it? The "you don't have to understand how KMS works" perhaps? (It's definitely not meant that way :-))
When it comes to security, that reflex is almost categorically wrong. I say "almost" because the people who tell people like us what to do are also reading this thread.
You don't get to have an ego when it comes to security or operational reliability (two separate fields, but ones with often similar resistance from developers). It just doesn't work that way.
> Security Professionals seem to have an unfortunate habit of talking down to everybody else.
I understand the feeling, and I have a related one, which is that the crypto field seems to be too "Rock-Star" focused. Unlike most other areas of software engineering, where a design flaw is unlikely to be business-threatening[1] and so engineers are comfortable rolling their own, crypto is very much of the "get it exactly right or don't do it at all" category.
It's hard to get right, and it goes against many (most?) programmer's instinct of "I can code it up in a week(end)". Add to that the steady stream of news about some company's compromised security, and crypto experts who care to communicate to fix the software industry's happy-go-lucky culture are forced to become ever more strident and dumb-down the message to reach the widest possible audience.
And then people think they're being condescending...
It's a cultural issue based on a technical one, and I don't know how to fix it other than have software engineers be more careful.
On the "rock-star" thing, it's because of how much we depend on a few recognized sources of authority (here, cperciva, tptacek) who we trust to point us in the right direction in the every-changing minefield of crypto practices. Other than have the field stop evolving and best practices become common-sense (which they absolutely aren't currently), I don't know how to fix that either.
[1] they might cause bugs, they might cause downtime, they might cause frustration with users, but by themselves are unlikely to cost you [m/b]illions and kill your company
I want to be clear: LVH is a trained cryptographic engineer, but I'm a software security tester that just happens to have a sort of practice focus on crypto bugs. I try to be open with people that I am not qualified to design nontrivial cryptosystems; what I can do is spot problem areas in existing systems, and make predictions about what design choices are likely to lead to those kinds of problems.
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.
Go already gives you an AEAD API with "Seal" and "Open" and implements it with GCM, which is what you should use in a clean-slate designs if you're sticking to the standard library.
This requires the whole plaintext/cipher text to fit into memory. For small blobs I would agree that GCM is perfect, but for anything larger you end up with extra projects like https://github.com/minio/sio trying to break streams into smaller ordered chunks. They are on v2 now.
It's not recommended not because it's insecure, but because it's easy to get wrong.
XSalsa20Poly1305 can also be implemented in a streaming/buffered fashion, it's just that most libraries implement the easier to use interface.
If you're encrypting objects that won't fit in RAM, it's worth considering encrypting separate chunks, making sure that the order cannot be changed (e.g. by incrementing a part of nonce for each chunk and setting some flag for the last chunk, see https://github.com/dchest/nacl-stream-js or https://download.libsodium.org/doc/secret-key_cryptography/s...). This allows detecting tampering early without writing malicious results into a file. Again, should be done carefully, as it's easy to get wrong.
Can you explain what is easy to get wrong? You want a CSPRNG to generate the IV, HMAC key, and AES key (which Go and node both have). Are their other implementation details that are complex?
I think the most common mistake I've seen is that people forget to use constant-time comparison function to verify MAC. AE/AEAD interfaces just have an open() function which returns NULL instead of the decrypted message if MACs don't match.
Also, AES-CTR has only space for 128-bit "IV" (counter that is encrypted), which is sometimes split into 96-bit nonce and 32-bit block counter, sometimes into 64-bit nonce and 64-bit block counter, sometimes IV is used directly and then incremented for each block. 96-bit is on the edge of collisions for randomly generated numbers, 64-bit random nonce is not safe, with 128-bit you're also limited with how much data you can encrypt without collisions... meh. XSalsaPoly accepts 24-byte nonce (can be random) and is good for 2^72 - 32 bytes (practically unlimited).
You also mention having separate keys for HMAC and AES, which is good, but you have to care about it (theoretically). With AE/AEAD you don't have to care about it.
That is, it seems like you can implement the system you described properly, but many people can't.
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?
Cryptographer joke: DSA stands for Disastrous Security Apparatus.
A lot of the problems with (EC)DSA are around nonce use. The k in ECDSA has the worst intersection of possible cryptographic randomness requirements: despite the name, it's not just "don't reuse me" (though that's disastrous too), it's also "be unpredictable and secret". An attacker that can reliably predict part of (let alone all of) your k has pretty much won already. The other issue is the failure mode: when this fails, it's not just easy to detect and exploit (well, full-k-reuse is easy at least), the attack also results in the key being entirely compromised. DSA is a no-good footgun. Contrast: EdDSA and friends, the recommendation in this document, is real hard to mess up.
I'm not sure what you mean by "I dislike having the one option of RSA"; this set of recommendations does not tell you to use RSA, it tells you the opposite.
Having multiple options is fine, but having multiple options as a recommendation for people writing cryptosystems is a disaster, and that's what this document is for. We've tried "agility". It was a bad idea. Cryptanalysis isn't hampered much by a set of recommendations. People are studying SIDH and LWE long before either is an everyday cryptosystem.
It takes a long time for NIST to make new recommendations, and I think there's a fair argument to be made that P256 isn't really broken enough to warrant a new spec yet? I mean, you can in fact write secure software that uses P256; if you've used a browser to hit Google today you probably already have.
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.
> 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
Imagine the following scenario:
All the hard negotiations are done and you're about to sign your biggest customer or even sell the entire business for big bux. This is, of course, contingent on a clean 3rd party security review.
The reviewer asks: "How does the system enforce key expiration policies? How do you rotate keys? How do you revoke a key that may have been compromised or recover from known compromise? Which private keys get used on network-facing servers? In what model of HSM do you store the root key?" ... and so on.
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...
> This is the reasons it's at the core of SCP03, the smartcard world is very sensitive to transistor count...
The reason it's at the core of SCP03 is because SCP03 is ancient (2006?) and once things get affixed intro a "standard" things now move at a glacial pace.
And, nowadays, fixed logic transistor count is almost irrelevant.
RAM transistor count, however, is expensive and getting moreso.
The audience for this document is software engineers. It woudl be impossible to write a document that serves every audience. Unless you're also suggesting that you should AES-CMAC a password reset token? And if we're going to go there, why not PMAC? Or OMAC?
> 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?
There are lots of things that are outside of the set of recommendations that are still fine. If you use UUIDs I won't tell you you're wrong and you need to rip it out :-)
Can someone explain to a layman why you need to avoid RSA ? Is this only for the particular use case the article talks about or you should avoid it for other things, like encrypting a hard drive?
The short of it is: If you're interoperating with anything in the real world, you're forced to use insecure modes. And even if you're not, the library you'll be working with probably has insecure defaults. Unless your job title rhymes with 'Cryptography Engineer', steer clear of it.
pgsodium is a postgres extension that adds libsodium integration to postgres, it exposes many of functions for patterns mentioned in the article, including box/secretbox, hashing, password handling, asymmetric keys, diffie-hellman, etc.
If you're stuck with FIPS 140-2, you should probably have someone on your payroll to answer your questions instead of an Internet document given to the broader audience of software developers.
Guidance from experts from a use case perspective is difficult to find, as documentation is always product centric.
Additionally, many members of the HN community have exposure they aren’t aware of. If you represent that you “encrypt” data, many organizations consider data that isn’t FIPS unencrypted. A password database compromise of your scrypt protected passwords may be a problem if you just accept boilerplate terms when selling a few licenses to state, local or federal customers.
It may help if we point out that we now have at least two independent implementations of XChacha20: your Libsodium and my Monocypher. This should raise confidence.
I'd love to add the extended nonce to RFC 7539, though.
> Why would implementation in your own library raise confidence?
I thought this would be obvious.
I didn't look at Sodium to implement XChacha20, but I did compare our two implementations (my test vectors come from Sodium). At the very least, this is evidence that Sodium did things right.
> Sodium is interesting because thousands of people use it.
By that metric, OpenSSL is even more interesting. Have those users also tested Sodium? I personally put more weight in Matthew Green's security audit.
Likewise, Monocypher is interesting because of its small size (easy to audit, won't take months like Sodium), its paranoid test suite, and to a lesser degree the proof that Poly1305 works. https://monocypher.org/poly1305-proof
At a guess, it might be because the things that you say are "missing" are specific to HTTP, yet the document says nothing (that I remember) about HTTP at all. The recommendations being discussed in the article are at a completely different level.
It's like if I said, "you forgot to mention to disable root logins via SSH". While that might certainly be a good recommendation, it's out of scope as it has nothing to do with what is being discussed.
Ah, thank you. I fully understand now the stupidity of my response. The title itself says "cryptographic" in it, and my answers had nothing to do with that. My mistake.
[2] RSASSA-PSS with SHA25 or MGF1+SHA256 in tricolor systemic silicate orientation
[3] 2048-bit Group #14 with a generator or 2
I regret the error (but not the recommendation; don't make your own custom RSA-based transport protocol).
I think this is our largest point of divergence. If the world had sane TLS libraries, I would absolutely say "run TLS with all the backwards compatibility crap turned off" -- but we don't have sane TLS libraries. I am not confident in my ability to turn off all the unwanted "features" of SSL/TLS stacks, and I'm not confident that anyone can write code which will turn off all the unwanted features and keep them turned off in future library versions. It's not much of an exaggeration to say that I consider the OpenSSL maintainers to be actively hostile; if I have to run their code at all I really want it to be inside a sandbox.
Yes, writing your own transport protocol is nontrivial. But if you write your own transport protocol, you don't need to worry about "the user upgraded to a new version of OpenSSL and now your connections are all HeartBleeding". A sane library would have had this feature turned off by default; OpenSSL is not a sane library.
While I'm on the topic:
Password handling: I skip bcrypt because the only reason to not use scrypt is if you need a US Government endorsed scheme. But yeah, it's (slightly) better than PBKDF2.
Cryptographic primitives: I think "use NaCl" is cheating a bit as far as answers go; that may be reasonable advice to implementors but it's not a protocol specification. So I'm reading those as "use foo, via the NaCl library".
As for what the foo in question should be: I'm gradually becoming more comfortable with curves, and 25519 in particular; similarly with sbox-free symmetric crypto (e.g., djb's dances and Keccak). At this point I'd say it comes down to how conservative you are; I wouldn't say that someone using XSalsa20+Poly1305 is wrong to do so.
If you're looking for a recommendation: just use OpenSSL and keep it up to date.
I love that I can't instantly tell which of those three footnotes is a real thing.
I assume the misquote is making fun of how long that description is compared to, like, "Use 256-bit AES keys." or "Use OpenSSL." (What specific thing in the decryption algorithm should I be making sure I don't misread in order to avoid side channel attacks?)
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.
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.
No-one is trustworthy enough to outsource the whole industry's security to - not tptacek, not djb, not AWS, and certainly not me. I think the key is to take not just the recipe but also the rationale. Someone who tells you "Don’t use RSA." might as well be working for the NSA. Someone who tells you "RSA has too many knobs. In modern curve systems, like Curve25519, everything is pre-set for security." is at least making a coherent argument that others can criticize - they might still be wrong, but the fact that they're being substantive is a positive step.
Even the dumbest of us know tptacek is not infallible, though I do hope cperciva and tptacek revisit this thread.
I did bring them up in the threads they occurred in. Not wanting to reopen those old discussions is precisely why I didn't talk about specific examples or give links.
Disclaimer: I'm a co-editor of the new version of the document and also a principal at Latacora and therefore clearly an NSA stooge ;-)
All could be amplified.
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!
So we're not just trusting DJB here. We're trusting a sizeable community that reviewed his work.
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
Really bad.
Invalid curve attacks will leak your secret key, which most old implementations (i.e. the ones likely to end up in your hardware) don't protect against.
If you reuse an ECDSA nonce, you will leak your secret key.
If you have even the smallest timing leak, guess what.
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-7056
https://web-in-security.blogspot.com/2015/09/practical-inval...
Essentially, a bunch of ECC implementations didn't do proper bounds checking and leaked data. ECC still offers a lot of benefits in terms of key size, performance, and security, however, so do your research carefully.
If you're doing ECDSA or ECDH over P256, it might be fine. It might also be a complete disaster. So, we don't recommend it -- and if you must, you should have someone audit it for you, because you're not in the safe zone anymore.
(Examples of disastrous failures: P256 off-curve attacks, unsafe k choices for ECDSA.)
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.)
Cascading ciphers does nothing to address the dangerous part of encrypting (order of operations for authenticating, authenticating all the security-sensitive components of the message, validating authenticators safely, randomizing encryption, safely handling truncation of authentication tags, providing adequate headroom for nonces, &c &c). In fact, since the best modern authenticated encryption constructions tend to be built up from a single cipher core (usually AES), cascades make encrypting safely harder.
You could "cascade" authenticated constructions, but different constructions have different failure modes. The poly MAC constructions fail and cough up authentication keys. Some gracefully handle truncation and some don't. Some constructions fail somewhat resiliently if nonces get repeated; some explode; some purport not to seriously fail at all. Some of them can reliably be implemented in software on any platform, but the binary field stuff really wants hardware extended carryless multiplication or you get new side channels. These things aren't designed to snap together in cascades and smushing them together doesn't make a lot of design sense.
It's hard to get this stuff right even when you're making the conventional, boring choices. Cascades involve a lot of "not boring" stuff, and the payoff for that not-boringness is arguably homeopathic.
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.
FWIW I'm more hopeful that I can make mTLS work immanently as part of the environment than everyone getting it right in their app. Less httpd more caddy, if that makes sense :)
Maybe an quick example off the top of my head would be: you know you need to authenticate and perhaps additionally 'encrypt' something --- for say a software update, fancy over-Bluetooth authentication scheme etc.
You need to pick: symmetric or asymmetric schemes? Auth then encrypt? What does replay of an old signature or MAC mean for your system? Key usage limitations? Key re-use? Quite a few ways you can err where the choice of e.g Ed25519 over P-256 ECDSA pales in comparison.
Or in other words: most people are trying to build a secure system, and where security is only achieved by the combination of the protocols, primitives used.
W.r.t TLS, yeah, bake in default configs as part of an environment where you can, although there'll always be plenty of people developing directly against the software API, and compatibility issues will typically play a part.
General reco from your list: the answer is always symmetric unless you literally can not accomplish the same thing any other way. (And you probably can.)
If I remember correctly, hashes and symmetric crypto are generally safe, and so those recommendations shouldn’t change.
That’s a very, very big “only” :).
In any case, there are several compelling computational problems which are (as of current research) post-quantum resistant. They’re based on lattices, error correcting codes, hashes, multivariate polynomials and supersingular elliptic curve isogenies (the latter one being the hot new thing).
Each of those problems has at least a few (but generally many) viable contenders for actual cryptography. Hashes give us very nice signatures, from old-school Winternitz one time signature to merkle trees to current frontrunners like SPHINCS (and its variants). Unfortunately hash-based cryptography can only be used for signatures so far, but they really excel at that.
The ring-LWE problem (and more generally, module-LWE) in lattice cryptography is pretty versatile: we can get fast encryption, signature and encapsulation schemes. The tradeoff is that key sizes run larger. But there is a lot of research into provable security in average-case and worst-case lattice assumptions. The NTRU problem is the other large “school” of lattice cryptography, which mostly has the same problem: very fast, but with larger key sizes.
Error correcting codes give us fewer computational problems to work with than lattices (essentially general decoding and syndrome decoding), but they are extremely well-studied. McEliece remains secure (for binary Goppa codes), which is incredible because it was published only two years after the notion of Diffie-Hellman PKE. Unfortunately most types of error correcting codes are not suitable for cryptography because they have excessive structure. We’ve been mostly stuck with binary Goppa codes for 40 years, though there is exciting work on quasi-cyclic and quasi-dyadic codes in the NIST PQ CFP. Otherwise, similar story as lattices: relatively fast, but very large key sizes.
Isogenies are extremely new and only have a few credible cryptosystems based on them. The most prominent researchers leading this domain are Jao, Longa, de Feo, Plut and Galbraith. The two contenders are SIDH and the NIST proposal succeeding it, SIKE. These have the opposite advantage to lattices and codes, because their key sizes are incredibly small (the smallest among all post-quantum cryptosystems), but their key exchange time is commensurately slower. The additional benefit is that they use much of the same mathematics as traditional elliptic curves, which means you could design hybrid ECDH-like and SIDH-like schemes with a relatively small library.
There are some wonkier proposals (such as Joux’s Mersenne prime one), but these are the ones receiving the most research attention. I wouldn’t say it’s a solved problem, but I’m personally confident there will be mature cryptography available when quantum computers can practically break our current state of the art.
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 get it. But libcrypto is less likely to have some insane UAF bug than, say, libtiff or whatever. If you're going to use unsafe code, libcrypto and libsodium are pretty great choices. I wrote a Clojure (so JVM) library that binds libsodium FWIW.
- I hear nice things about Rust's ring lib. Still gotta FFI from OCaml or the JVM though.
- A lot of the recommendations on this list are algorithms designed to be safe to implement. For example, it's unlikely that a JVM impl of XSalsa20 + Poly1305 is suddenly unsafe because of the environment you're running in. This is NOT TRUE for things like AES-GCM; firstly a lot of naive AES implementations are insecure, and good luck doing GHASH safely in software.
The rest of this should be fine in a native phone app.
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.
If you wanna do Argon2id that's fine too :-)
What is the rationale behind the assumption that this middle ground is better than straight up Argon2i for general purpose password derivation? I've never seen it explained anywhere.
I'm assuming you're familiar with the Argon2 RFC sections on Argon2id? I think it goes into quite a bit of detail between the two.
Assuming timing attacks breaks Argon2d entirely at relatively little cost, the attacker advantage for a 1-pass Argon2id would be twice that of a one-pass Argon2i: about 10. A three pass Argon2i with a third of the memory looks better: about 3. Not that it matters that much, but still.
Or is my threat model of timing attacks (which assumes they could recover whatever they can at little cost) too paranoid?
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.
You can shoot yourself in the foot with HMAC but it won't be because of HMAC; for example: if your messages don't contain a nonce or timestamp they might be replayable or something. But that's not an HMAC flaw.
So to answer your question: maybe? You can get in plenty of trouble with HMAC, but it won't be HMAC's fault.
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 :)
I can get pretty deep on the TLS/SSL side if you have specifics; I'm also the main author of s2n, our Open Source implementation of TLS, and a participant in the TLS1.3 process.
Monocypher is portable (C99/C++), pretty fast, and has low memory footprint (generated binary between 30kB and 60kB). Problem: it isn't trusted yet. (I'd like to run a bug bounty, but I'm not sure how I should go about it.)
TweetNaCl is portable (C89), has low memory footprint, and is made by trustworthy professional cryptographers. Problem: it is slow.
Libsodium is blazing fast on modern processors, has portable implementations, and is trusted. Problem: it is pretty big, and I hate the auto tools.
Edit: of course, those recommendations only hold if you have a trustworthy RNG.
IOW, Cortex M0 territory.
Small IoT is about this size, so I think many will be interested in some answers... any answers.
Say, for securely transmitting sensor data to an x86 server (or similar) without hardcoding symmetric keys on the devices.
If speed doesn't matter, TweetNaCl is even smaller.
If those aren't enough still, you may want to dive in, learn a ton about crypto (starting with https://www.crypto101.io/), and investigate the sponge construction, whose versatility may allow you to shrink the code even more. Perhaps. I'm in over my head at this point.
Neither TweetNaCl nor 'loup-vaillant's library really addresses the low-footprint concern.
I've deployed TLS in 50 KiB flash and 6 Kb RAM. But I could rely on hardware support for some public key operations and could pick a single ciphersuite, and controlled the server end as well.
The boring answer is that you'll need to identify the set of primitives you need and then find a library that matches. I can't think of any single primitive that would break that budget, so it'll depend on how many you need!
(As for the original question, I don't know BearSSL enough to have an opinion. It does seem however to get even further than Monocypher on the constant time thing. Monocypher needs the platform to provide constant time 64-bit multiplication. Most do, but not all.)
Would you be willing to be personally liable for that data leak?
(Put aside the philosophical question of whether or not it's reasonably for developers to be personally liable for their software failures - I'm interested in how far your confidence in your cryptography goes).
Embedded crypto gets weird fast. General recommendations are a little tricky, but: is that device talking to the internet directly or some kind of IoT hub or whatever?
On smaller systems, things get weird. If you can't afford go/openssl, there aren't a lot of things I'm very confident in. BearSSL near the top of the list. That's still double-digits kilobytes of RAM though, so maybe I just ate all your budget. You might be in one of the cases where a NOISE protocol instance is in fact the right answer; depends a little on what else the box is doing and how frequently.
Sorry, I get that it's not a satisfying answer :-) It's complicated!
I would have told you something differently before NOISE and NaCl, particularly Curve25519. We could have done AESCTRHMACSHA256 a long time ago and be basically a good as XSalsa20-Poly1305, but Curve25519 was a huge leap compared to the DH2048 you were likely to do before.
Noise is potentially very interesting, particularly for the embedded space, but it'll be a while before it's safe to use.
IMO the interesting aspect with the development of Noise will be if it can avoid bloat. From the mailing list I can see that there's solid awareness of that risk (would assume Trevor is aware anyway), but it will be interesting to see how the simplicity of pattern API will handle things like signatures, when they're inevitably added. I see at least one Noise-using project has already made the leap on that front.
You’re right that they’ve gotten less scrutiny, but they also need less scrutiny. (I’m not saying more isn’t better.) TLS carries a lot baggage from phlogiston era crypto and is significantly more complex than a dumb NOISE impl.
Note that I qualified my suggestion to “you need to have someone around for that” and that I also mentioned low cost. Specifically, I imagine you’d instantiate NOISE with some boring primitives, ideally in a memory safe language, and spend some time and money pointing Tamarin at it, for example. If you don’t have that, fine, get a tiny TLS stack. I’m just saying that a priori I can’t tell you I have less faith in random mbedTLS-containing ROM vs NOISE-with-reasonable-implementor. (I appreciate that we’re comparing apples to oranges with a concrete ROM vs an abstract protocol.) I also happily appreciate that we’re in territory where the constraints are too restrictive to make blanket recommendations.
Let me rephrase: would you agree that there are platforms that actually shipped with garbage crypto where it’s plausible that they could’ve made NOISE work but didn’t embed a TLS stack because size/perf?
Comparing between those two options is a question of appetite for risk, your threat model, and the level of competency you have available. On the latter note, _at the moment_, I think the subset of people who are capable of taking advantage of Noise would be largely similar to the same subset you could safely task with designing and implementing a custom AKE+messaging protocol from scratch anyway. I think the level of competency you need available is on the very far end of the spectrum. Edit: and on the risk point, even if the library has been eyeballed less, at least you know with mbedTLS that if a bug drops you'll get a patch pretty quickly. If you goof up your Noise impl you're on your tod.
mbed TLS also doesn't seem to be particularly well vetted and has had a number of compromises due to implementation issues.
Cryptography and libraries/standards are gradually building towards a world in which higher-and-higher level abstractions let inexperienced web/high-level application developers build safe systems. The same isn't really true for the lower-end of the embedded space, and consequently you can't really produce an equivalent set of (reasonable) guidelines like the ones linked.
> 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.
We could do an elaborate embedded post but the answers diverge a lot more because constraints are tighter. If you’re doing embedded you need a security person around.
Also I <3 SPAKE2. More than I ought to.
I trust NaCl and, specifically, DJB-associated implementations thereunto. Lots of people have looked at it. I trust DJB and his cohorts to think about and mitigate footguns as much as practical.
STROBE is right about a year old. Maybe it's awesome, but it almost certainly hasn't been vetted sufficiently.
I seem to recall that most PAKE's relied on one of the nice properties that modular exponentiation has that doesn't work for ECC. IIRC, quite a few of the PAKE's tried to use ECC and fell into the trap and created a breakable PAKE.
The patent situation around PAKE's didn't help. Fortunately, those patents just expired.
> If you’re doing embedded you need a security person around.
Apple couldn't even get it right. They implemented an 3072-bit SRP that takes almost 15-20 seconds on Cortex M0/M3 series processors unless you have an exponentiation accelerator (Cortex-M4).
If Apple can't get it right, what chance do those with far less resource have?
A list like the parent article but tailored to embedded would be quite welcome.
Re: PAKEs: yes, some PAKEs and related protocols are hard to port to ECC. For example, SRP doesn’t port cleanly from FF to an elliptic curve group because it actually needs a field. But I called out SPAKE2 for a reason: porting SPAKE2 to ECC is easy.
RAMBUS got shafted by the DRAM manufacturers, but they pulled a LOT of shady crap of their own and Stanford was in the thick of it.
While I have no belief that Mike Hamburg was ever in the middle of that, I have some concerns about what might or might not be patented once RAMBUS's lawyers get done with it.
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).
There is more distinguishing Ed25519 from Deterministic ECDSA than deterministic nonce generation.
On the other point, then don’t list deterministic nonces as a comparative advantage since it is not actually distinguishing.
I'll think about a way to articulate that. Obviously, we can't really offer advice on doing state-of-the-art signature schemes in a couple paragraphs, and would not be interested in trying.
On the other point: the 2015 version of the document addressed the point you're making (and recommended deterministic DSA!). I just think it's kind of dumb to design new systems with a DSA dependency in 2018, and so rescinded the recommendation.
But that's not true: for both Curve25519 and in the Ed25519 signature scheme, which were designed with curves for which point validation is supposedly unnecessary and thus not performed, there are for a given curve point other points --- not valid ones, but ones for which the math will work --- that are equivalent.
For the kinds of things most developers use crypto primitives for, and most of the things everyone was using them for in 2009, these distinctions are --- I'll argue --- not that important. If your transport protocol handshake blows up because of cofactors, the problem probably isn't that you didn't check curve points; it's that you designed a bad key exchange.
But since I don't do cryptocurrency work, like, at all, it's easy to forget that the mainstream of what people do with signature schemes is a lot broader than it was before. I'll try to think of a way to word that and get it into the document.
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.
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!
I shall up it to 100K!
I think the TL;DR is "I'm not sure you can do this safely without having a security person on your team".
(there is also a web version, which of course could always be compromised, but we're encouraging users to download the app so they have full control and don't have to worry about that. But they need to be compatible.)
Telling our users not to use crypto isn't an option. Recommending our users not use a browser is possible, but forcing them not to use a browser isn't an option either.
I'll give it a shot though, some things that come to mind:
* RFC6979 ECDSA or bust
* Have you considered off-curve attacks for that ECDH?
* How do you authenticate your symmetric ctexts?
Then I have two basic questions (for either you and tptacek):
1) Given I just need to hash the contents of a file for content-addressed data (like in git), it seemed like sha2-256 would be sufficient. However, it seemed like on 64-bit machines, sha2-512 is faster, and I can just lop off the first 256 bits. Is that correct? And in what cases would you use sha3-256/sha3-512?
2) Given I need to build an API that authenticates through client tokens, I was thinking of using JWT (json web tokens) with HMAC256, and a payload with a randomly generated token for the at_hash claim, and send it over TLS. Do I need to include a nonce in the payload? If not, it's the same JWT on every client request. If so, how would you recommend generating a nonce?
In the article, under symmetric signatures, you talk about not doing anything complicated with the data you feed into the HMAC. But I'm not sure what the simple construction of this data is. Is it where you say "just concatenate the key and data and hash them and be secure"?
2) Are you entirely convinced you actually need client tokens? In particular, can you get away with a 256-bit random token and store the session in a database?
3) Re: HMAC input malleability: yep, concat and HMAC is fine. Serializing JSON or whatever is also fine. You're usually providing the tag (that's what the output of HMAC is called) verbatim next to the message, so you generally don't care about e.g. canonical serialization.
2) Hrm. I guess maybe? As I understand it, the reason for a client token is to have stateless servers, so the server doesn't need to look up a valid token upon every request--which scales better. In my case, the API endpoint is for something that doesn't (and won't) get a lot of traffic, so I can probably get away with a 256-bit random token over TLS? Since it's over TLS, there probably aren't MITM attacks to sniff the token and replaying it--so it's probably ok? Are there other considerations I'm not aware of?
https://www.imperialviolet.org/2017/05/31/skipsha3.html
Generally: don't do encrypted tokens. If you must: don't do JWT for this. Just secretbox a thing and be done with it, or use PASETO[0].
[0]: https://github.com/paragonie/paseto
Can you point to a RTFM on why not? I'm sure it's a big list of reasons but where can I read about the biggest one?
A lot of the implementations _aren't even faster_, but the laundry list of security bugs they have caused is very real. Suddenly you get to worry about irrevocable tokens in order to solve scaling problems you don't have.
A good intro is: http://cryto.net/~joepie91/blog/attachments/jwt-flowchart.pn...
Just as a heads-up, SHA-512/256 isn't exactly just SHA-512 with 256 bits chopped off. It also uses a unique IV. This might not be a big difference in practice, but I'd lean toward using SHA-512/256 explicitly, and not SHA-512 truncated to 256 bits.
(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.)
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 :-)
https://docs.python.org/3/library/secrets.html
On which systems is getentropy() available? My Ubuntu 16.04 doesn't seem to have it.
(FreeBSD only recently added the getrandom(2) syscall and getentropy(3) libc wrapper functions in -CURRENT.)
http://man7.org/linux/man-pages/man3/getentropy.3.html
It could even do that for urandom already. IIRC that's what BSDs do.
It could, in the sense that anything is possible, but that isn't the behavior the Linux kernel community has chosen. And they are pretty good about not changing published interfaces at this point. At least getrandom(2) provides the sane behavior (and does not require an fd or filesystem namespace access).
> IIRC that's what BSDs do.
Yep, at least FreeBSD.
---
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.
[1] http://www.daemonology.net/blog/2009-06-11-cryptographic-rig...
[2] https://gist.github.com/tqbf/be58d2d39690c3b366ad
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?
E.g. "I have an API key and I want it encryptedly available to some servers, and engineers to be able to roll but not read the cred", KMS directly with a CMK is great. Otherwise: that's what the rest of the bulk encryption and key generation recommendations are for; get a DEK, use NaCl's secretbox or whatever.
DEK sharding strategies depend on your data model so that gets a little tricky to provide good advice for in this document but that's something we help clients with, sure :)
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.
- My laptop has a 1TB disk, which is mostly full. I want to back it up.
- Some of the data on it is sensitive. The vast majority is not - for example, a large fraction of the disk is taken up by torrented anime videos - but I don’t want to separate out only the sensitive data to back up securely. Not only would that be inconvenient, it would be wildly insecure, since I’d presumably want some other, potentially less secure backup solution for the rest of the data, and it’d be really easy to miss some sensitive data and have it accidentally included in the insecure backup.
- Storing 1TB of data on Tarsnap for a year costs $3,000 (though after deduplication and compression there should be somewhat less than 1TB).
- Storing 1TB of data on Amazon Glacier for a year costs $48, which can be combined with various open-source encryption tools (of varying quality).
- Backblaze’s consumer backup product, which I currently use, costs $50 per year for unlimited storage; it supposedly does client-side encryption, though I don’t know how much I trust it.
- One of those prices is not like the others.
- I expect to have a larger disk in the future, and fill it up too; storing 2TB would double the Tarsnap and Amazon prices.
- If Tarsnap actually made the difference between my data being compromised or not, that would be worth $3,000 or $6,000 to me, and I do have the means to spend that much if necessary. But in reality, I’d expect it to only slightly reduce the chance of compromise compared to a high-quality alternative, and I don’t have so much money (or arguably, I don’t value security highly enough?) that I can reasonably spend so much on that small of a benefit.
- Why should you, the author of the post, or anyone else care that I’m stingy? Well, you don’t have to. But I’d certainly appreciate advice from experts about which of the alternatives are the best. In other words, what the right-est answer is that fits my budget constraints, even if it’s not actually the right answer. :) I don’t think the alternatives are all so insecure that it would be irresponsible to recommend any of them.
- I have nothing against Colin personally; indeed, I wish him the best of success. I do think his pricing model doesn’t do a great job representing his costs, since the time he spends maintaining the Tarsnap software and servers, and providing support, doesn’t scale linearly with the amount of data stored. But there’s no rule it has to; it’s his choice. It’s just that the result is a service that isn’t for me.
https://www.tarsnap.com/man-tarsnap-keymgmt.1.html
e.g. you may give each host their own write-only key so they can automatically create new snapshots, while keeping the keys that permit reading and deleting old snapshots on separate machines with separate passphrases.
> But, seriously: you can throw a dart at a wall to pick one of these. Technically, argon2 and scrypt are materially better than bcrypt, which is much better than PBKDF2. In practice, it mostly matters that you use a real secure password hash, and not as much which one you use.
It’s not so much a strict order of preference as it is a preference, any preference, so as to still be recommending things. Argon2 and scrypt are too close to call.
In fact, taking a quick look again I find Argon2's "memorySizeKB" and "iterations" make much more sense to me than scrypt's "CostFactor" and "BlockSizeFactor" parameters as it's a lot clearer what's being impacted. I agree with the i-vs-d confusion, but in most cases I think using argon2id as you mentioned should resolve the contention as is already the suggested default in the IETF draft.
https://tools.ietf.org/html/draft-irtf-cfrg-argon2-03#sectio...
Specifically:
> We recommend the following procedure to select the type and the parameters for practical use of Argon2.
As opposed to just pick a profile, which, to be fair, the RFC also suggests :) So I guess that’s a fair point, it just feels like as with the i-vs-d thing there’s just more song and dance around it that I wish wasn’t there. The suggestion in the RFC vs published 3rd party recommendations (eg jjarmoc’s NNC reco) are also off by a factor of 100 or so? I’m happy to buy that that’s an unfair subjective impression, but when I was reviewing an argon2id python implementation last week I really just wanted to give people a function that just does “encrypt my damn password already”. Maybe that’s up to the implementation layers job, that’s fine - I did that for txscrypt too and I don’t remember where I got the magic numbers from :)
To be clear in case someone else reads this out of context: I am not saying not to use Argon2id!
I like and use tarsnap (and have for years) but the lack of choice of backends is a downside. I've been waiting for something I can use to backup my workstation and laptops to a server at home as well as a server I have at $work (ISP). I've tried out all the usual applications but have yet to find something I'm happy with.
restic looks like it may fit the bill perfectly.
borg[1] has been referred to as "the holy grail of backups"[2] and is supported at rsync.net.[3]
The end result is encrypted, zero knowledge remote backups on a ZFS filesystem that you can SSH to.
I think everyone here knows all about rsync.net, but here are some examples:[4]
[1] https://borgbackup.readthedocs.io/en/stable/[2] https://www.stavros.io/posts/holy-grail-backups/
[3] http://rsync.net/products/attic.html
[4] http://www.rsync.net/resources/howto/remote_commands.html
Do you get enough control do to that on rsync.net?
Yes. You have your own .ssh folder in your account and can edit (upload) your keys as you see fit.
Also, if you have our ZFS snapshots enabled, those are immutable/readonly - so even if you aren't using a sophisticated tool like borg, you still have snapshots of your data that are immune to attack - even from someone who knows all of your credentials.
[0] https://restic.net/blog/2018-04-01/rclone-backend
> 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.
I don't know why that one paragraph stuck out at me so much, but it triggered the "screw you, don't tell me what to do" reflex.
You don't get to have an ego when it comes to security or operational reliability (two separate fields, but ones with often similar resistance from developers). It just doesn't work that way.
I understand the feeling, and I have a related one, which is that the crypto field seems to be too "Rock-Star" focused. Unlike most other areas of software engineering, where a design flaw is unlikely to be business-threatening[1] and so engineers are comfortable rolling their own, crypto is very much of the "get it exactly right or don't do it at all" category.
It's hard to get right, and it goes against many (most?) programmer's instinct of "I can code it up in a week(end)". Add to that the steady stream of news about some company's compromised security, and crypto experts who care to communicate to fix the software industry's happy-go-lucky culture are forced to become ever more strident and dumb-down the message to reach the widest possible audience.
And then people think they're being condescending...
It's a cultural issue based on a technical one, and I don't know how to fix it other than have software engineers be more careful.
On the "rock-star" thing, it's because of how much we depend on a few recognized sources of authority (here, cperciva, tptacek) who we trust to point us in the right direction in the every-changing minefield of crypto practices. Other than have the field stop evolving and best practices become common-sense (which they absolutely aren't currently), I don't know how to fix that either.
[1] they might cause bugs, they might cause downtime, they might cause frustration with users, but by themselves are unlikely to cost you [m/b]illions and kill your company
What are the classic/authoritative texts in this space?
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.
XSalsa20Poly1305 can also be implemented in a streaming/buffered fashion, it's just that most libraries implement the easier to use interface.
If you're encrypting objects that won't fit in RAM, it's worth considering encrypting separate chunks, making sure that the order cannot be changed (e.g. by incrementing a part of nonce for each chunk and setting some flag for the last chunk, see https://github.com/dchest/nacl-stream-js or https://download.libsodium.org/doc/secret-key_cryptography/s...). This allows detecting tampering early without writing malicious results into a file. Again, should be done carefully, as it's easy to get wrong.
Libhydrogen takes a different approach, and supports an optional "message id" (which is AD in disguise) https://github.com/jedisct1/libhydrogen/wiki/Secret-key-encr...
Also, AES-CTR has only space for 128-bit "IV" (counter that is encrypted), which is sometimes split into 96-bit nonce and 32-bit block counter, sometimes into 64-bit nonce and 64-bit block counter, sometimes IV is used directly and then incremented for each block. 96-bit is on the edge of collisions for randomly generated numbers, 64-bit random nonce is not safe, with 128-bit you're also limited with how much data you can encrypt without collisions... meh. XSalsaPoly accepts 24-byte nonce (can be random) and is good for 2^72 - 32 bytes (practically unlimited).
You also mention having separate keys for HMAC and AES, which is good, but you have to care about it (theoretically). With AE/AEAD you don't have to care about it.
That is, it seems like you can implement the system you described properly, but many people can't.
True for so many things.
with https://crypto.stackexchange.com/questions/56448/can-keyed-c... as a reference :)
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?
A lot of the problems with (EC)DSA are around nonce use. The k in ECDSA has the worst intersection of possible cryptographic randomness requirements: despite the name, it's not just "don't reuse me" (though that's disastrous too), it's also "be unpredictable and secret". An attacker that can reliably predict part of (let alone all of) your k has pretty much won already. The other issue is the failure mode: when this fails, it's not just easy to detect and exploit (well, full-k-reuse is easy at least), the attack also results in the key being entirely compromised. DSA is a no-good footgun. Contrast: EdDSA and friends, the recommendation in this document, is real hard to mess up.
I'm not sure what you mean by "I dislike having the one option of RSA"; this set of recommendations does not tell you to use RSA, it tells you the opposite.
Having multiple options is fine, but having multiple options as a recommendation for people writing cryptosystems is a disaster, and that's what this document is for. We've tried "agility". It was a bad idea. Cryptanalysis isn't hampered much by a set of recommendations. People are studying SIDH and LWE long before either is an everyday cryptosystem.
It takes a long time for NIST to make new recommendations, and I think there's a fair argument to be made that P256 isn't really broken enough to warrant a new spec yet? I mean, you can in fact write secure software that uses P256; if you've used a browser to hit Google today you probably already have.
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.
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.
Imagine the following scenario:
All the hard negotiations are done and you're about to sign your biggest customer or even sell the entire business for big bux. This is, of course, contingent on a clean 3rd party security review.
The reviewer asks: "How does the system enforce key expiration policies? How do you rotate keys? How do you revoke a key that may have been compromised or recover from known compromise? Which private keys get used on network-facing servers? In what model of HSM do you store the root key?" ... and so on.
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.
This is the reasons it's at the core of SCP03, the smartcard world is very sensitive to transistor count...
The reason it's at the core of SCP03 is because SCP03 is ancient (2006?) and once things get affixed intro a "standard" things now move at a glacial pace.
And, nowadays, fixed logic transistor count is almost irrelevant.
RAM transistor count, however, is expensive and getting moreso.
I'm not sure what they're saying here. Is there a problem with the way curl handles TLS?
We had enough curve arguments on the CFRG leading up to RFC 7748/8032 that any additional curves for ECC gets filed under "needless bikeshedding".
Why not pick PinkBikeShed or FuchsiaBikeShed instead?
The short of it is: If you're interoperating with anything in the real world, you're forced to use insecure modes. And even if you're not, the library you'll be working with probably has insecure defaults. Unless your job title rhymes with 'Cryptography Engineer', steer clear of it.
https://github.com/michelp/pgsodium
Guidance from experts from a use case perspective is difficult to find, as documentation is always product centric.
Additionally, many members of the HN community have exposure they aren’t aware of. If you represent that you “encrypt” data, many organizations consider data that isn’t FIPS unencrypted. A password database compromise of your scrypt protected passwords may be a problem if you just accept boilerplate terms when selling a few licenses to state, local or federal customers.
FIPS-140-2: "Use AES"
So: aes_cbc_encrypt(crypto_secretbox(message, nonce, k1), iv, k2)
From a security perspective, there is nothing wrong with Salsa. But libraries implementing ChaCha today are unlikely to add Salsa.
It wouldn't take much effort for libraries currently having high-quality implementations of ChaCha to add an extended nonce variant.
The only reason it didn't happen is that there is no formal specification.
I'd love to add the extended nonce to RFC 7539, though.
I thought this would be obvious.
I didn't look at Sodium to implement XChacha20, but I did compare our two implementations (my test vectors come from Sodium). At the very least, this is evidence that Sodium did things right.
> Sodium is interesting because thousands of people use it.
By that metric, OpenSSL is even more interesting. Have those users also tested Sodium? I personally put more weight in Matthew Green's security audit.
Likewise, Monocypher is interesting because of its small size (easy to audit, won't take months like Sodium), its paranoid test suite, and to a lesser degree the proof that Poly1305 works. https://monocypher.org/poly1305-proof
> Don’t built elaborate password-hash-agility schemes.
build*
And what's the asterisk on
> Avoid: … IPSEC.*
?
A few references would help.
1. Content security policy headers for web
2. "strict" Samesite cookie flags for CSRF and authentication tokens
Difference of opinion
Didn't argon2 win the last password hashing competition?
It's like if I said, "you forgot to mention to disable root logins via SSH". While that might certainly be a good recommendation, it's out of scope as it has nothing to do with what is being discussed.