Differences from SEC 1 in ethereum ECIES

[devrandom]

I wanted to list the differences from SEC 1 that I found while working on ECIES for ethereumj. SEC 1 says:

• IV should be all zeros and should not be transmitted (see section 3.8 discussion about IV/ICB)
• IV should not be part of MAC (message tag) computation
• also noticed an extra hash of the MAC key in the go-ethereum implementation

I believe that the reason SEC 1 recommends constant IV is that the ephemeral key is used only once, so use of a random IV is superfluous.

The changes don't seem to introduce any weakness, just curious about the motivation.

( @romanman )

[romanman]

@obscuren : I know you are busy, but in a moment you not, can
you comment on this please or refer to somebody in your team.

[fjl]

I will have a look at it later.

[Gustav-Simonsson]

@romanman Hi! Apologies for the late reply - we've been so busy with other parts of Ethereum lately :)

Section 3.8 in SEC 1 Version 2.0 specifies zeroed IV for TDES in CBC mode and for AES in CBC and CTR modes, but it does not specify what IV value to use for plain XOR CTR.

The Go implementation uses XOR CTR: https://github.com/ethereum/go-ethereum/blob/develop/crypto/ecies/ecies.go#L193

You're right that IV should not be transmitted as part of the ciphertext, as specified in SEC 1.

While the IV value is not specified for XOR CTR, it's implied it cannot be random if it should not be transmitted as part of the ciphertext, as then the other party cannot know it.

If it's non-random, we can set it to the zeroed value defined for AES in CTR mode.

It's correct that IV should not be part of the message to take MAC over, defined as concatenation of ciphertext and "SharedInfo2" in section 5.1.3 step 8.

The extra hashing of the MAC key is indeed not specified in SEC 1 and can be removed.

Pull request: #847

@fjl @subtly Please review - if this is correct C++ would also need to be updated to be compatible.

SEC1: http://www.secg.org/sec1-v2.pdf

[subtly]

@romanman @Gustav-Simonsson This stems from adopting the go ecies package. This would go well with the adoption of libsecp256k1 multiply within ecies. Would be good to ping the upstream author about that as well.

[enuoCM]

What's the status of this issue now? So we cannot make ecies work between ethereumj and go-etherum now?

update: ECIESCoder of ethereumj works well with the go-ethereum ecies.