/cipher/ - cryptography general

Hi Lain, I'm noticing a lack of threads focused solely on cryptography. Cryptography is the study of transforming information so that it appears to be noise, to anyone that does not have the appropriate key that can transform it back. It is the bedrock of information security. Without cryptography, there would be no way to conceal our messages "on the wire". This thread is for discussion about cryptography, both theoretical and practical. Lately I have been trying to write a very low-latency networking application that will have encrypted data streams. I am still pondering whether I should use chacha (probably 12-round) or hardware-accelerated AES-CTR. Based on the EBASC benchmarks, chacha12 is pretty reliably about 1-2x slower than hardware AES for the packet sizes I'm looking at, but not relying on complicated libraries does feel like a big plus. What does lain think?

>>27643 I'd argue that for low-latency the difference between the 2 is honestly negligible, but for your *very* low-latency setting you should obviously go for AES if hardware-acceleration is available for all of your deployments. Also I would suggest going for AES-GCM and actually having authentication, unless your protocol already handles authentication somewhere else but really it just makes more sense to do it using GCM as if you did raw CTR + HMAC separately, you'd likely end up (slightly) slower than just using GCM's integrated auth. From what I know of OpenSSL, it can handle AES-NI automatically so it should not be any more complicated than a normal OpenSSL AES setup. Also you can verify if AES-NI is being used by looking at /proc/cpuinfo for the aes flag. For what it's worth, libsodium's functions are even simpler than OpenSSL if you want less boilerplate but OpenSSL does give much more control. Good luck with your network application OP!

>>27664 >if hardware-acceleration is available for all of your deployments. This is the issue, it's a safe bet that all servers would have AES-NI or whatever the ARM equivalent is, but I can't guarantee that all users would. It's meant to be cross-platform. I can perhaps leave the door open for AES support. You're right that AES-NI software support isn't actually very complicated, now that I did more research. I'm prioritizing using the smallest TCB I can, but there are some really small and good SSL libraries. >but really it just makes more sense to do it using GCM as if you did raw CTR + HMAC separately, you'd likely end up (slightly) slower than just using GCM's integrated auth. That's a good point. I'm using siphash-2-4 for packet authentication at the moment. User messages are (eventually) signed and the cryptographic handshake is authenticated, so the MAC isn't the sole source of authentication. It also saves a couple bytes. But, after some benchmarking, it seems likely that you're right and either GCM mode or another AEAD scheme would be faster. chacha20-poly1305 actually beats aes-256-gcm on my machine.

>>27666 >it's a safe bet that all servers would have AES-NI or whatever the ARM equivalent is, but I can't guarantee that all users would. The servers will probably be doing a lot more work than individual users. Individual users may not notice the performance difference, but it'll add up quickly for your servers (probably, depends on your architecture). And the more requests the serversl can process the more users it can serve I will also second >>27664's recommendation for AES-GCM for the same reasons they mentioned but also because there are less cryptographic gotchas compared to AES-CTR.

>>27670 The only situation I can think of where choosing an AES-based cipher would pose an issue is video streaming on phones. As I understand it, constant-time software AES could be a pretty big power drain with that much throughput. Also, since I made that post I found out about AEGIS (https://eprint.iacr.org/2013/695.pdf), an authenticated cipher that has some pretty stunning performance improvements over AES-GCM on processors with pipelined AES instructions. The only caveat is that it has a long-ish initialization routine, so it gets beat by chacha for very short messages. What I ended up doing is reworking the cryptographic handshake so that both ends of any connection provide a mask of 'performance' ciphers they support (chacha12, chacha8, aegis-256) during the handshake, and they end up using the last cipher in the list that they both support, with chacha20 being the default.

>>27671 Looks awesome and will read this thoroughly You guys care about post quantum ? I feel divided: only ultra paranoid agencies like military and gov care about it, but it also makes sense to be scared about the store then decrypt threat

>>27678 >You guys care about post quantum ? I think the immediacy of practical quantum computing is quite overhyped. However, I'm glad there is now an additional family of usable public-key cryptosystems (LWE-based) that have undergone extensive analysis. They are unsuitable as a drop-in replacement for ECC though.

> Cryptography is the study of transforming information so that it appears to be noise, to anyone that does not have the appropriate key that can transform it back This is part of the equation, but it is a bit of a narrow view of cryptography. It leaves out zero-knowledge, many forms of secure multi-party computation, and indistinguishability obfuscation. And of course, since it leaves out zero-knowledge, it certainly leaves out signatures which most people would consider "core" cryptography. It's not even true from a simulation view of security since the simulator's backdoor can be observation of queries to some idealized primitive. The backdoor in this scenario is instantiation of the object rather than an "appropriate key". There's a big problem with newcomers to cryptography seeing "encryption" as the end-all of cryptography while it's a significantly deeper field.

>>27709 excuse me for trying to come up with a high-level description of a well-known concept. I'm really sorry to have misled so many people, even implying that digital signatures aren't cryptography! This really is egg on my face. >There's a big problem with newcomers to cryptography seeing "encryption" as the end-all of cryptography Is there? I'm so sorry to have contributed to this huge, pervasive issue. Thank you for saging by the way, it's a great way to show that you're interested in joining the conversation and aren't just firing off pointless criticisms.

It's possible to bruteforce gpg keys on a laptop so that you can produce two different gpg keys with the same 64-character fingerprint. I memorized Tor Project's gpg fingerprint and had relied on that knowledge for many years, apparently under a false sense of security. They haven't fixed this problem for the latest OpenPGP standard btw.

>>27712 not that lain but they're just trying to clarify things. it was a good post. there's no need to be mean to them for expanding on your OP. >>27725 do you mean the short key id? GPG fingerprints are 160 bits hashes, usually represented in 40 hex characters. The long key id is a truncation of the fingerprint down to 64 bits (16 chars) and the short key id is a truncation down to 32 bits (8 chars). It's that 32-bit short key id that is vulnerable to collision attacks on consumer grade hardware. The full fingerprint is still collision resistant to my knowledge.

>>27726 >The full fingerprint is still collision resistant to my knowledge. It's really not, here is my source. Warning: sfw furry content. https://soatok.blog/2026/01/07/practical-collision-attack-against-long-key-ids-in-pgp/

>>27725 You can brute force a 160-bit fingerprint? That seems unlikely. However SHA-1 is known to be weak to collisions.

>>27726 >there's no need to be mean to them for expanding on your OP. I would not have been mean if they hadn't saged while making an on-topic reply. To me that signals "I am uninterested in this conversation". >>27727 This describes an attack on the 64-bit key id, not the finferprint. Says so right there in the post.

>>27727 The article you share is about the long key id. That is not the same as the fingerprint. >>27726 >It's that 32-bit short key id that is vulnerable to collision attacks on consumer grade hardware. s/collision/preimage and note that the 64-bit long keys are preimage resistant but not collision resistant (as demonstrated in that article). the full 160-bit fingerprint is still safe.

Glad to see a thread for cryptography here! I've recently started to learn about cryptography from a theoretical standpoint by reading picrel. (Today I accidentally read from a copy of the 2008 version which said Elgamal encryption is secure against chosen ciphertext attacks, which seemed a bit weird to me. Turns out that's dead wrong, and it's corrected in the 2014 version lmao. Anyway, it's really interesting so far, so I hope I can stick with it...) So far, learning from the book has been really nice to satiate my curiosity about the foundations of cryptography (e.g., why exactly can we say some cryptosystems are secure but not others?), but I'm still wondering about what modern applied cryptography research entails. Maybe this is a dumb question but what are some good ways to get in the loop about that? I know a little about post-quantum crypto (LWE) from a few YouTube videos but that's really about it...

>>27834 Pet peeve: > Post Quantum Cryptography There are no proofs of this > Plausibly Quantum Resilient Cryptography

>>27873 Ayrt, I get what you mean but this reads as such uhm ackshually tier snark. We have also yet to prove that trapdoor functions, which are the basis for public-key cryptography, even exist - does that mean we should call RSA ""plausibly secure"" every single time we refer to it? Yes, it's based on mathematical conjecture, but by our security standards and definitions, it is "secure", which is why we take it as such.

>>28029 >does that mean we should call RSA "plausibly secure" every single time we refer to it? that depends on the context if you're writing a book on the subject, you are definitely expected to acknowledge such theoretical aspects

>>27834 >but I'm still wondering about what modern applied cryptography research entails You can read some of the NIST submissions from recent competitions and get an idea of what it's like. I like Ausmussen's paper 'too much crypto', it's very readable. You could also look at recent AES attacks, although they tend to be extremely technical. >>27873 Probably because there are no such proofs. Every single cryptosystem ever is based on something being really difficult to figure out, not on proving that it is impossible to figure out.

>>28035 >because there are no such proofs >because you just stated the same as the post you're replying to are you agreeing?

>>28038 I read >>27873 as "this hasn't been proved (but it could be in the future)" and >>28035 as "this cannot be proven". Which is weird because they used the same words.

>>27666 The ARM equivalent is AES-CE. RISC-V also has scalar and vector cryptography extensions ratified, but I'm only aware of the latter existing in silicon, and it's quite rare (e.g., the only production, available board that has it right now that I know of is the Spacemit K3). If you're curious about seeing an AES-CE-based implementation, check mbedTLS/TF-PSA-Crypto's for the "official" ARM one. Iirc SiFive has produced multiple RISC-V vector crypto implementations, in OpenSSL and the kernel, I want to say. There are also POWER AES extensions, SPARC variants, so on. If extreme portability is your goal with a performance emphasis, I would recommend XChaCha8 or 12. If you're willing to sacrifice some potential targets, then just stick with AES. If you can guarantee everyone is running your tismware, then AEGIS is even better, as you found out. You can also consider things like Boyar-Peralta if you don't feel like supporting all the various ISAs but still need the AES S-box. It's definitely slower, but you still get SWAR tricks and it's constant time. Pornin has a pretty solid reference implementation. Plus it's just useful to have an implementation for yourself, you can do some pretty neat tricks with the AES S-box (e.g., see Saarinen's SM4 trick, and other associated affine relationships between the AES S-box and e.g. Camellia, ARIA)

https://link.springer.com/chapter/10.1007/3-540-69053-0_6 https://en.wikipedia.org/wiki/Kleptography This is really interesting. I don't grasp the full impact of this, nor how could it be used in practice by an attacker. This is the most intriguing part: >The Dual_EC_DRBG cryptographic pseudo-random number generator from the NIST SP 800-90A is thought to contain a kleptographic backdoor. Dual_EC_DRBG utilizes elliptic curve cryptography, and NSA is thought to hold a private key which, together with bias flaws in Dual_EC_DRBG, allows NSA to decrypt SSL traffic between computers using Dual_EC_DRBG for example.

>>28207 It's kinda something that jumps out at you when you first see it. To get a better idea, assume we have some elliptic curve E with a cofactor of one over a field of prime characteristic. We have two points, P, Q, and since we're on a curve of cofactor one, there must be some relationship P = sQ. Of course, determining s is considered hard if the usual ECDLP requirements are met, but if we construct it ourselves, we know s. The general functionality of the generator are the functions: X(x,y) -> x (extracts x coordinate of a given point in affine coords) t(x) : {0,1}^k -> {0,1}^{k-n} (truncates n MSB of data, 16 per spec) g_P(x) = X(xP) (scalar mult of P by x) g_Q(x) = t(X(xQ)) (scalar mult of Q by x, extract x coord, truncate) Then, to actually use it, we pick some random number s in F_p, and pass it to g_P to establish the first state. The outputted values are calls to g_Q passing the current state, then the next state is calculated by calling g_P on itself. Say we have an output from the generator t. The outputs from the generator are, iirc, the x coordinate of a given curve point truncated by 16 bits. Since it's trivial to brute force 16 bits, we'll just consider it the full x coordinate of some other point A. Since A is an output, we know it must be related to Q by some value x, so we call that r. So we have: sA = srQ (A = rQ) srQ = rP (sQ = P) rP = internal state Since the next internal state is calling g_P on itself, we can determine the next state, and thus predict the generator, by seeing only a single output. So, how does this get exploited? Raw PRNG output is visible to an attacker very frequently - think RSA padding, nonces, so on. Observe a single output and you now have the state, allowing you to break ECDH, and thus you now have an insecure channel. Similar issues follow for signatures. Beyond this risk though, the generator itself was rather poor, quite slow, and relied on somewhat atypical security assumptions. ECDDH, which is fairly standard, but then also the X-Log problem (ECDLP where the scalar is an x coordinate of a point on the curve), and TPP (is it possible to efficiently reconstruct curve points where data has been truncated?). The middle one is the most so-so, the former is believed hard, and the last is also believed hard only when a cryptographically relevant portion of the information has been truncated (recall, DUAL_EC_DRBG only requires 16 bits - so in this instance, it is not a sound problem). Sorry for the late response.