Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't pass on small block ciphers

00f.net

Post reply on HN
Print view View original

41–50 of 64 posts

Re: Don't pass on small block ciphers

#41

Post by bflesch »

Aachen wrote: post #9
bflesch wrote: post #6

Slightly unrelated, but aren't these AES-specific custom CPU instructions just a way to easily collect the encryption keys? There is a speedup but is it worth the risks? If I were a nation state actor, I'd just store the encryption keys supplied to the AES CPU instruction somewhere and in case the data needs to be accessed you just read the stored keys. No need to waste time deploying a backdoored CPU firmware and wa…

I am not a chip designer but from my limited understanding, this "somewhere" is the problem. You can have secret memory somewhere that isn't noticed by analysts, but can it remain secret if it is as big as half the cpu? A quarter? How much storage can you fit in that die space? How many AES keys do you handle per day? Per hour of browsing HN with AES TLS ciphers? (Literally all supported ciphers by HN involve AES) We…

Good points, but might be mitigated by knowing that the first key after boot is for HDD encryption and if storage is limited then keep counter for each key, and always overwrite least frequently observed key.

Re: Don't pass on small block ciphers

#42

Post by tptacek »

cyberax wrote: post #39
tptacek wrote: post #37

Earlier quoted context omitted.

Right, but balanced and unbalanced Feistel networks let you turn the 16-byte AES block into an arbitrarily small PRF.

Well, yes. But at this point you're just making a new cipher with AES as the round function. And I think it should be at least as safe as the round function? I have not checked lately, but is it actually the recommendation for format-preserving encryption?

I don't know about "the" recommendation, but it's how NIST standardized it (FF1 and FF3, both Feistel networks) and in the NIST rubric these aren't "new ciphers"; they're "block cipher modes".

I'll say I'm more comfortable using a straightforward FPE block cipher mode with AES than I am repurposing a weaker lightweight cipher to take advantage of its 32-bit block size.

Re: Don't pass on small block ciphers

#43

Post by fluoridation »

201984 wrote: post #36
fluoridation wrote: post #32

Earlier quoted context omitted.

Would it, though? Either way you're operating in ECB mode with 2^32 or 2^64 values. Why is one more secure than the other? EDIT: What I mean is you can do cypher = truncate(plain ^ AES(zero_extend(plain))).

>EDIT: What I mean is you can do cypher = truncate(plain ^ AES(zero_extend(plain))). How would you decrypt that though? You truncated 3/4ths of the AES output needed to decrypt it. I thought you were suggesting this: ciphertext = truncate(AES(key) ^ plaintext) And in this case, since AES(key) does not depend on the plaintext, it would just be XOR by a constant.

You're right, my bad. I guess if you have strict size requirements it does make sense to use small block sizes.

Re: Don't pass on small block ciphers

#44

Post by Dylan16807 »

AlotOfReading wrote: post #23
Dylan16807 wrote: post #8

Earlier quoted context omitted.

Small sizes have to be used with extra care, so I wouldn't want to make a generic function for all sizes. For bigger sizes we already have nice functions that take care of everything.

The article lays out exactly why you'd want small sizes, even with the risks. The good qualifier just means that it'd have to be no riskier than any other algorithm at the same length.

I agree? That doesn't affect what I said. You shouldn't make a one-size-fits-all function that scales that small. It should have to be a deliberate choice to switch from normal mode to small mode, and anyone that hasn't looked into it deeper shouldn't even know about the small mode.

Re: Don't pass on small block ciphers

#45

Post by 201984 »

botusaurus wrote: post #40
201984 wrote: post #34

Earlier quoted context omitted.

Are you certain using AES is still faster? Let's say for a 32-bit block size and 64-bit key. From https://en.wikipedia.org/wiki/Speck_(cipher) , that Speck combination would use 22 rounds, and using the instruction timings for Zen 5 from https://instlatx64.github.io/InstLatx64/AuthenticAMD/Authent... , it looks like each round would take at most 3 cycles. (Dependency chain for each round is 3 instructions long, ror+a…

maybe the reason they are so close is that the AES microcode is inplementing exactly those operations

There's nothing similar about AES and Speck, and the "microcode" for AES isn't like what you're thinking of. If you want to learn more about it, you can look up the specifications for AES and Intel's AES instruction set.

Re: Don't pass on small block ciphers

#46

Post by throw0101c »

Any reason not to use Ascon, which not only got Official Status™ from NIST:

* https://www.nist.gov/news-events/news/2023/02/nist-selects-l...

* https://csrc.nist.gov/pubs/sp/800/232/final

But was also a lightweight finalist in CAESAR (along with ACORN):

* https://en.wikipedia.org/wiki/CAESAR_Competition

* https://en.wikipedia.org/wiki/Ascon_(cipher)

Re: Don't pass on small block ciphers

#47

Post by 201984 »

throw0101c wrote: post #46

Any reason not to use Ascon, which not only got Official Status™ from NIST: * https://www.nist.gov/news-events/news/2023/02/nist-selects-l... * https://csrc.nist.gov/pubs/sp/800/232/final But was also a lightweight finalist in CAESAR (along with ACORN): * https://en.wikipedia.org/wiki/CAESAR_Competition * https://en.wikipedia.org/wiki/Ascon_(cipher)

Ascon is a stream-oriented AEAD, not a block cipher, and it requires a nonce. Because of this, it would not work for the usecases in TFA, not to mention it's also quite a bit slower than Speck.

Re: Don't pass on small block ciphers

#48

Post by FiloSottile »

whizzter wrote: post #24

Not a cryptographer but I'm not liking the "advice" of encrypting the first 64bits of the UUID. An user of an opensource application using this known "encryption" will be able to approximate the real UUID values based on creation time of objects they control and then would probably be able to approximate keys for 64bit encryption (although I guess one could design a cipher with a far larger key than block size, but i…

All of these small block ciphers have regularly large keys.

Re: Don't pass on small block ciphers

#49

Post by Aachen »

bflesch wrote: post #41
Aachen wrote: post #9

Earlier quoted context omitted.

I am not a chip designer but from my limited understanding, this "somewhere" is the problem. You can have secret memory somewhere that isn't noticed by analysts, but can it remain secret if it is as big as half the cpu? A quarter? How much storage can you fit in that die space? How many AES keys do you handle per day? Per hour of browsing HN with AES TLS ciphers? (Literally all supported ciphers by HN involve AES) We…

Good points, but might be mitigated by knowing that the first key after boot is for HDD encryption and if storage is limited then keep counter for each key, and always overwrite least frequently observed key.

Could work. How do you know what the least-frequently used key is if you can't store them, though? Would need some heuristics. Maybe it could write the first five keys it sees after power on on every power on, or some other useful heuristic.

Like, I do take your point but it does seem quite involved for the chance that it'll get them something useful, and they still need to gain physical access to the intact device, and trust that it never gets out or the chipmaker's reputation is instantly trash and potentially bankrupt. And we know from Snowden documents that, at least in ~2013 (when aes extensions weren't new, afaik), they couldn't decrypt certain ciphers which is sorta conspicuous if we have these suspicions. It's a legit concern or thing to consider, but perhaps not for the average use-case

edit: nvm it was proposed in 2008, so that it didn't show up yet in ~2013 publications is not too surprising. Might still be a general point about that 'they' haven't (or hadn't) infiltrated most cpus in general

Re: Don't pass on small block ciphers

#50

Post by AlotOfReading »

Dylan16807 wrote: post #44
AlotOfReading wrote: post #23

Earlier quoted context omitted.

The article lays out exactly why you'd want small sizes, even with the risks. The good qualifier just means that it'd have to be no riskier than any other algorithm at the same length.

I agree? That doesn't affect what I said. You shouldn't make a one-size-fits-all function that scales that small. It should have to be a deliberate choice to switch from normal mode to small mode, and anyone that hasn't looked into it deeper shouldn't even know about the small mode.

I suppose I don't understand your point. On one hand, you can have different algorithms for each of 32, 64, etc with potentially different pitfalls and usage requirements. On the other, you can have one algorithm that implements all of them. I wasn't trying to comment on how that should be exposed in the library (because crypto lib design is a whole 'nother topic), but I'm not opposed to it being explicit.

Same as CRCs, really. You can easily write a function that performs CRCs of any size and expose different parameterizations as CRC-8/16/32/64 etc.

Post reply on HN