The Cryptographic Doom Principle \ stacker news ~bitcoin

pull down to refresh

The Cryptographic Doom Principle moxie.org/2011/12/13/the-cryptographic-doom-principle.html

130 sats \ 10 comments \ @ek 12 May 2023 bitcoin

21 sats \ 0 replies \ @l0k18 12 May 2023

In general, always integrity first, and only put size data when you need it to be there and don't have it without integrity and better don't have it without encryption either.

I get around the message size problem by using a fixed size packet and have a buffer that gathers pieces and reassembles them for longer messages. Each segment once decrypted, after identifying the receiving private key via a random+hash "cloaked key", which only the holder of the key can identify, plus a private key that was used to generate with the public key the cipher used on the encryption. I use CTR, because I handle the integrity myself with a truncated SHA256 hash prefix on the packet segment format. I don't use signatures in the algorithm - authenticity is handled by the use of session keys which double as identifiers for the sessions, and designate a sats balance to spend on the bandwidth. Generating ECDH shared secrets costs about the same processing as the signatures and the signatures you can recover keys from, like with Bitcoin tx signatures, cost 65 bytes and you have to do the ECDH operation anyway.

The "receiver" key cloak scheme makes it so an attacker cannot see a common receiver key in the message, and in the protocol it signifies what it is associated with, the outer-layer uniform sized packets are an ephemeral key that is changed periodically by volume (it's a one sided operation to tell the other side to use a new public key on their packets), and inside these packets are arbitrary length onion messages, the onions use the same encryption header format the difference is the key is connected to sessions for relaying and accounting of session balances.

I dunno, maybe I haven't thought of a problem with my scheme. I'm most glad to hear of any someone can think of.

100 sats \ 0 replies \ @tldr_dead 12 May 2023

The Cryptographic Doom Principle states that if one has to perform any cryptographic operation before verifying the MAC on a message received, it will inevitably lead to doom. In Vaudenay Attack, if an attacker cycles through enough modifications, they will eventually trigger a MAC error, leading to plaintext recovery. Similarly, in SSH plaintext recovery, the recipient needs to decrypt the first block and interpret the first four bytes as the length of the message before verifying the MAC, allowing attackers to reveal the first four bytes of plaintext in a ciphertext block. There are a number of other ways in which the Cryptographic Doom Principle has manifested itself, and it will inevitably cause trouble.

0 sats \ 2 replies \ @ek OP 12 May 2023

I don't get how the first example about "authenticate-then-encrypt" has something to do with how MACs are used. Seems like a normal padding oracle attack.

21 sats \ 1 reply \ @0260378aef 12 May 2023

The point is that you can't do the authentication (i.e. checking the MAC) until you have stripped the padding, in this model. So you're processing and performing logic on plaintext data that isn't yet authenticated.

Clearly there are potential finesses in that. A MAC is always going to be fixed length, and a payload has to be variable length, so you are always going to have to put padding in there.

You might counter-argue, well, why not put the MAC at the end, after the padding? But it won't remove the fundamental problem, which is, to authenticate the message by reading the MAC, you're going to need to process that payload (with or without padding bytes at the end), and so you're left making a logical decision about the payload before your authentication process has completed.

In encrypt-then-mac, instead, you do the authentication first, so you never do logical processing on un-authenticated plaintext.

0 sats \ 0 replies \ @ek OP 12 May 2023

Ah ok, I think I get it now.

I was confused because if a MAC is included in the ciphertext or not, the padding still needs to be checked first.

But the point is that in this model of authenticated encryption, it's a weakness if you first have to decrypt before authenticating. Knowing the ciphertext is authentic before decryption is clearly superior.

Thanks!

0 sats \ 1 reply \ @BBitcoinUSA 12 May 2023

What does this mean for us mortals who don’t understand anything that article says?

10 sats \ 0 replies \ @ek OP 12 May 2023

If you are implementing a cryptographic scheme where you want to encrypt (handle data confidentially) and authenticate stuff (make sure data was not changed during transit + we can be sure who sent the data), you should first encrypt and then put a MAC (Message Authentication Code) on it.

This article explains why.

0 sats \ 1 reply \ @slender_trikes_0c 12 May 2023

Help me out please. What is the relevance of an article from 2011 on a news site? But since it's here, another question, is Moxie a shitcoiner?

100 sats \ 0 replies \ @ek OP 12 May 2023

I found this article because it was mentioned in the PR regarding NIP-93: NSON.

I didn't care about the year. The year also doesn't matter for stuff like this. TCP/IP was invented in the 70s/80s. Is it now no longer important to know how it works? I would say no.

I posted this here because I didn't understand the first example and hoped someone would enlighten me. That indeed happened.

0 sats \ 0 replies \ @ek OP 12 May 2023

@tldr