
Cryptographic Right Answers - louis-paul
http://latacora.singles/2018/04/03/cryptographic-right-answers.html
======
weinzierl
Here is a summary, roughly ordered from constant to changed the most.

    
    
    	    			Percival 	Ptacek			Latacora
    				2009		2015			2018
    
    	Online backups		tarsnap		tarsnap			tarsnap
    
    	Symmetric key length	256-bit		256-bit			256 bit
    
    	Symmetric “Signatures”	HMAC		HMAC			HMAC
    
    	Random IDs		256-bit		256-bit			256-bit
    				
    	Hashing algorithm	SHA256 (SHA-2)	SHA-2			SHA-2
    
    
    	Password handling	scrypt		scrypt			scrypt	
    				PBKDF2		bcrypt			argon2
    						PBKDF2			bcrypt
    									PBKDF2
    
    	Website security	OpenSSL		OpenSSL			AWS ALB/ELB
    						BoringSSL		OpenSSL
    						AWS ELBs		LetsEncrypt
    
    	Client-server		OpenSSL		OpenSSL			AWS ALB/ELB
    	app security				BoringSSL		OpenSSL
    						AWS ELBs		LetsEncrypt
    
    
    	Asymmetric encryption	[1]		NaCl/libsodium 		NaCl/libsodium
    		
    
    	Asymmetric signatures	[2]		NaCl			NaCl
    						Ed25519			Ed25519
    						RFC6979
    
    	Diffie-Hellman		[3]		DH-2048			Nothing
    						NaCl			Curve25519
    
    
    	Encrypting Data:	AES-CTR HMAC	NaCl/libsodium default	KMS
    						ChaCha20-Poly1305	XSalsa20+Poly1305
    						AES-GCM
    
    
    
    

[1] RSAES-OAEP with SHA256 and MGF1+ SHA256 bart pop fssssssst exponent 65537

[2] RSASSA-PSS with SHA25 or MGF1+SHA256 in tricolor systemic silicate
orientation

[3] 2048-bit Group #14 with a generator or 2

~~~
tptacek
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).

~~~
cperciva
_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.

~~~
cperciva
_I think this is our largest point of divergence._

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.

~~~
pbsd
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.

~~~
cperciva
If you want to be really pedantic, every boolean operation is just a 2->1 bit
S-box...

------
tptacek
Fight me.

I mean, happy to answer any questions.

By the way: if you're interested in this, you might also be interested in the
set of 9 (count them: 9) new cryptopals challenges we sold off to raise money
for rural congressional races on Twitter:

[https://twitter.com/search?f=tweets&q=set%208%20from%3Atqbf&...](https://twitter.com/search?f=tweets&q=set%208%20from%3Atqbf&src=typd)

This is Cryptopals Set 8, before this weekend available only on request and
after swearing a solemn oath not to share.

~~~
evrydayhustling
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.

~~~
lmm
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.

~~~
18pfsmt
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.

~~~
lmm
> 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.

------
keithwinstein
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.)

~~~
loup-vaillant
I may have to update my manual, which currently recommends getrandom() on
Linux, and arc4random_buf() on BSD.
[https://monocypher.org/manual/#Random_number_generation](https://monocypher.org/manual/#Random_number_generation)

On which systems is getentropy() available? My Ubuntu 16.04 doesn't seem to
have it.

~~~
justincormack
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.

~~~
deathanatos
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).)

~~~
loeg
OpenBSD introduced getentropy(2). Since it is a subset of getrandom(2)
functionality, glibc added a compatibility wrapper that provides the same ABI.

(FreeBSD only recently added the getrandom(2) syscall and getentropy(3) libc
wrapper functions in -CURRENT.)

------
loup-vaillant
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](https://monocypher.org)
satisfies most of this, but we do have a couple departures:

 _Encrypting data:_ Monocypher provides an XChacha20 + Poly1305 AEAD
construction (copied straight from the RFC 7539). Why not XSalsa20? Because
XChacha20 has a little bit more security margin, and is a little bit easier to
optimise.

 _Symmetric "signatures":_ Monocypher provides Blake2b, which provides a keyed
mode for this. Blake2b doesn't need HMAC.

 _Hashing Algorithm:_ Blake2b again, because it's faster and immune to length
extensions attacks. I'm not sure why they still recommend SHA-2. Isn't Blake2
mature enough by now?

 _Password Handling:_ Monocypher provides Argon2i. Close to the top of the
list, but not quite.

 _Asymmetric encryption:_ Monocypher doesn't have a box-like construction, but
it does have a key exchange function, which combined with AEAD does the same
thing as NaCl's crypto_box(). This makes the library more orthogonal, and I
assumed combining key exchange and AEAD wasn't error prone.

 _Asymmetric signatures:_ Monocypher defaults to EdDSA, with curve25519 and
Blake2b. Why no SHA-512 instead? Because I already have Blake2b, which is
faster, and I didn't want the bloat. (Ed25519 is provided as an option)

I hope those departures are boring enough.

------
weinzierl
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.

[1] [http://www.daemonology.net/blog/2009-06-11-cryptographic-
rig...](http://www.daemonology.net/blog/2009-06-11-cryptographic-right-
answers.html)

[2]
[https://gist.github.com/tqbf/be58d2d39690c3b366ad](https://gist.github.com/tqbf/be58d2d39690c3b366ad)

------
victork2
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.

[https://docs.aws.amazon.com/kms/latest/developerguide/progra...](https://docs.aws.amazon.com/kms/latest/developerguide/programming-
encryption.html)

Thoughts?

~~~
lvh
Yep, but depends on your use case.

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 :)

------
piracykills
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:

[https://blog.filippo.io/restic-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.

~~~
jlgaddis
Thanks for the pointer to restic.

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.

~~~
rsync
"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)."

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]

    
    
      ssh user@rsync.net sha256 some/file
      pg_dump -U postgres db | ssh user@rsync.net "dd of=db_dump"
      ssh user@rsync.net du -Ahd2 some/directory
    

[1]
[https://borgbackup.readthedocs.io/en/stable/](https://borgbackup.readthedocs.io/en/stable/)

[2] [https://www.stavros.io/posts/holy-grail-
backups/](https://www.stavros.io/posts/holy-grail-backups/)

[3]
[http://rsync.net/products/attic.html](http://rsync.net/products/attic.html)

[4]
[http://www.rsync.net/resources/howto/remote_commands.html](http://www.rsync.net/resources/howto/remote_commands.html)

~~~
Wingwing
This isn't zero-knowledge. Please use this opportunity to educate the public
instead of muddying the term for the sake of marketing buzzwords.

~~~
CiPHPerCoder
To add to this comment: [https://paragonie.com/blog/2016/08/crypto-misnomers-
zero-kno...](https://paragonie.com/blog/2016/08/crypto-misnomers-zero-
knowledge-considered-self-descriptive)

------
jstanley
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.

~~~
lvh
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 :-))

~~~
jstanley
I admit that I wrote that before I read the rest of the article. The rest of
the article is great :).

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.

~~~
eropple
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.

------
ryan-c
Can we get work factor/parameter recommendations for scrypt, pbkdf2, bcrypt
and argon2?

------
jamesdsadler
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?

~~~
loup-vaillant
[https://www.crypto101.io/](https://www.crypto101.io/)

------
Xeoncross
> 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](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.

~~~
dchest
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](https://github.com/dchest/nacl-stream-js) or
[https://download.libsodium.org/doc/secret-
key_cryptography/s...](https://download.libsodium.org/doc/secret-
key_cryptography/secretstream.html)). This allows detecting tampering early
without writing malicious results into a file. Again, should be done
carefully, as it's easy to get wrong.

~~~
Xeoncross
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?

~~~
lvh
Example: if you don't specify that something is the last token, an attacker
can trivially truncate.

~~~
Xeoncross
That is what the 512bit MAC is for

~~~
lvh
I don't see which 512 bit MAC you're referring to. I'm referring to the
chunked encryption scheme 'dchest mentioned.

------
vandot
> If you can pay AWS not to care about this problem, we recommend you do that.

True for so many things.

------
raesene9
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."

with [https://crypto.stackexchange.com/questions/56448/can-
keyed-c...](https://crypto.stackexchange.com/questions/56448/can-keyed-crc-be-
used-as-a-mac/56450#56450) as a reference :)

------
exabrial
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?

~~~
lvh
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.

------
RcouF1uZ4gsC
>Client-server application security >Percival, 2009: Use OpenSSL.

Percival actually recommended not using SSL and shipping the server public key
with the client.

From [http://www.daemonology.net/blog/2009-06-11-cryptographic-
rig...](http://www.daemonology.net/blog/2009-06-11-cryptographic-right-
answers.html)

>Client-server application security: Distribute the server's public RSA key
with the client code, and do not use SSL.

What are your thoughts on that approach today.

~~~
lvh
Just use TLS.

To quote a little bit more from that 'cperciva article:

> If you're distributing client code which speaks to a server you operate,
> there is no need to use SSL; instead, you can distribute the server's public
> RSA key (or its hash) along with the client code, and "bootstrap" the
> security process that way. I do this in FreeBSD for the FreeBSD Update and
> Portsnap services, and I also do this in Tarsnap. It's simple; it works; and
> it's secure.

I'm sure cperciva knows how to start from a hardcoded RSA key and end with a
secure wire protocol. The spirit of the document is damage control: prevent
less broken software. There's a hell of a lot more in TLS than an RSA key.
There are a lot of ways you get from "RSA" to "wire protocol" and not a lot of
them are any good.

If you control both ends and you want to be fancy, use TLS with one secure
ciphersuite and a hardcoded CA, that's fine.

~~~
marshray
> 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.

------
technion
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".

------
chme
Why is this page not available over https? A bit ironic that we have to trust
the connection between us and the server to get advice about security.

~~~
lvh
Because we're messing with a little microblogging service and haven't set up
HTTPS for it yet.

~~~
chme
There seems to be an old version with expired letsencrypt certificates still
running: [https://latacora.singles](https://latacora.singles)

------
rphlx
> Avoid: the OpenSSL RNG

Is that just historical - i.e. a tiny chance somebody is still using the
broken Debian version from a decade ago - or is there actually something still
insecure, or at least suspicious, even in 1.1.0+?

I ask only because getentropy() is not widely available in the Linux world
yet, and getrandom() - and direct use of the /dev files - do have some caveats
of their own.

------
brohee
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...

~~~
bsder
> 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.

~~~
brohee
SCP03 is from 2009 actually. But its authors were likely very aware of HMAC,
yet chose CMAC.

------
charonn0
> 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?

------
exabrial
Also, any opinion on the Million Dollar Curve?
[https://cryptoexperts.github.io/million-dollar-
curve](https://cryptoexperts.github.io/million-dollar-curve)

~~~
CiPHPerCoder
I can't speak for the authors of the Latacora page but I generally find this
unnecessary.

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?

------
deegles
Why is it better to use 256-bit IDs vs 128-bit IDs? I thought UUIDs were fine?

~~~
lvh
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 :-)

------
sametmax
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?

~~~
CiPHPerCoder
I've covered this before, targeting the PHP community, but most likely
generally applicable: [https://paragonie.com/blog/2016/12/everything-you-know-
about...](https://paragonie.com/blog/2016/12/everything-you-know-about-public-
key-encryption-in-php-is-wrong#how-rsa-goes-bad)

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.

------
politips
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.

[https://github.com/michelp/pgsodium](https://github.com/michelp/pgsodium)

------
Spooky23
Any suggestions as far as the “most right” answers for those of us stuck with
FIPS 140-2 due to upstream compliance requirements?

~~~
CiPHPerCoder
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.

~~~
Spooky23
I suppose that’s is one way to look at it.

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.

~~~
CiPHPerCoder
Here's an idea: Wrap securely encrypted data in FIPS certified encryption.

FIPS-140-2: "Use AES"

So: aes_cbc_encrypt(crypto_secretbox(message, nonce, k1), iv, k2)

------
jedisct1
I wish XChaChaPoly was more widely implemented.

~~~
tptacek
Why?

~~~
dchest
As implemented in jedisct1's libraries, it allows authenticating associated
data, unlike XSalsaPoly from NaCl.

~~~
jedisct1
ChaCha is generally faster and has more implementations, including OpenSSL.
Salsa is essentially limited to NaCl and Sodium.

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.

~~~
loup-vaillant
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.

~~~
tptacek
Why would implementation in your own library raise confidence? Sodium is
interesting because thousands of people use it.

~~~
loup-vaillant
> _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](https://monocypher.org/poly1305-proof)

------
loeg
Two nits:

> Don’t built elaborate password-hash-agility schemes.

build*

And what's the asterisk on

> Avoid: … IPSEC.*

?

~~~
ryan-c
IPSec has a boatload of possible configurations, many of which are not secure.
It's kind of a tire fire.

~~~
loeg
Sure, I'd just like it clarified on the article.

~~~
tptacek
I clarified the asterisk by removing it.

~~~
loeg
Hah, works for me.

------
abhishekjha
Can somebody explain in layman terms what this article is about?

A few references would help.

------
zallarak
_Missing_

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?

~~~
zallarak
Just curious - why the downvote?

~~~
jlgaddis
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.

~~~
zallarak
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.

