I wish XChaChaPoly was more widely implemented.
Cryptographic Right Answers
21–30 of 243 posts
Re: Cryptographic Right Answers
#22Earlier quoted context omitted.
Do you also agree with the recommendations given in the article in 2018?
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 :-)
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"?
Re: Cryptographic Right Answers
#23Would 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…
On which systems is getentropy() available? My Ubuntu 16.04 doesn't seem to have it.
Re: Cryptographic Right Answers
#24 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
Re: Cryptographic Right Answers
#25Re: Cryptographic Right Answers
#26> 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.
Re: Cryptographic Right Answers
#27Fight me. I mean, happy to answer any questions. By the way: if you're interested in this, you might also be interested in the set of 9 (count them: 9) new cryptopals challenges we sold off to raise money for rural congressional races on Twitter: https://twitter.com/search?f=tweets&q=set%208%20from%3Atqbf&... This is Cryptopals Set 8, before this weekend available only on request and after swearing a solemn oath not…
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.
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.
Re: Cryptographic Right Answers
#28This 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. Pa…
Re: Cryptographic Right Answers
#29Why is it better to use 256-bit IDs vs 128-bit IDs? I thought UUIDs were fine?
Re: Cryptographic Right Answers
#30Would 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…
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 On which systems is getentropy() available? My Ubuntu 16.04 doesn't seem to have it.