ethereum / devp2p

Ethereum peer-to-peer networking specifications
972 stars 273 forks source link

[Question] [RLPX] auth / auth-ack padding #222

Closed ana-prdekalo closed 1 year ago

ana-prdekalo commented 1 year ago

Hello everyone, hopefully, this is the right place to ask the auth/ack padding questions.

Q1

Can someone please explain why we are applying arbitrary data to the end of the message? Is this just protection similar to the nonce? Or does this serve some other purpose?

I've read that usually data is padded to make the total size of the message a multiple of the encryption block size, so that the original message size is unknown, but since this padding is of a random length, this doesn't seem to be the case.

Q2

There is no spec about the padded data size, but both rust implementations linked in Readme append a random number of bytes, [100, 300].

C/P from OpenEthereum implementation:

        encoded.resize(encoded.len() + rand::thread_rng().gen_range(100, 301), 0);

Why these numbers? Was this randomly chosen or there is some reasoning?

Thanks in advance!

fjl commented 1 year ago

The random padding was added in EIP-8:

During the transitioning period (i.e. until the old format has been retired), implementations should pad auth-body with at least 100 bytes of junk data. Adding a random amount in range [100, 300] is recommended to vary the size of the packet.

It could be argued that the 'transitioning period' is now over. All Ethereum implementations support EIP-8, and most do not support pre-EIP-8 RLPx anymore.

fjl commented 1 year ago

The technical reason why the padding was added is making the two handshake formats distinguishable by size. In order to understand why this solution was chosen, you must know that RLPx before EIP-8 did not have any kind of version number, and all implementations used a fixed-size initial read from the connection to process the handshake. We had to grow the initial packet a bit.

While the EIP was being discussed, people voiced concerns that a plain-text size prefix would be 'too recognizable', i.e. the very first byte sent on RLPx connections would always be exactly the same. That's why a random padding amount was specified.

ana-prdekalo commented 1 year ago

I completely missed the EIP-8 link at the bottom of the specs 🤦‍♂️ Sorry for wasting your time, and thank you very much for the detailed explanations :)

fjl commented 1 year ago

Don't worry, it is my job to answer questions like that!