Differences from SEC 1 in ethereum ECIES #473
Comments
|
@obscuren : I know you are busy, but in a moment you not, can |
|
I will have a look at it later. |
|
@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. |
|
@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. |
|
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. |
|
I got an error “panic: got null header for uncle 0 of block 1458046c19b4c0e388db6cb7d09c3da6a8a88e75ccf9f027196c2732d43c9b6b” when i run 'range block.Transactions()'，what should i do when it happen???? |
|
It's way too late to align ECIES used in Ethereum p2p with any standard. New APIs for encryption have been proposed for the RPC interface but we haven't implemented them yet. |
fix signing with m1 = m2
Ci/fix test flow
* Create MVHashMap and use it StateDB * Parallel state processor * Move fee burning and tipping out of state transition to reduce read/write dependencies between transactions * Re-execute parallel tasks when there is a read in coinbase or burn address * Block-stm optimization Added tests for executor and two major improvements: 1. Add a dependency map during execution. This will prevent aborted tasks from being sent for execution immedaitely after failure. 2. Change the key of MVHashMap from string to a byte array. This will reduce time to convert byte slices to strings. * Remove cache from executor test * added mvhashmap unit tests (with as key) * Shard mvhashmap to reduce the time spent in global mutex * Skip applying intermediate states * Dependency improvement * added test for status * Create MVHashMap and use it StateDB * Parallel state processor * Move fee burning and tipping out of state transition to reduce read/write dependencies between transactions * Re-execute parallel tasks when there is a read in coinbase or burn address * Txn prioritizer implemented using mutex map (ethereum#487) * basic txn prioritizer implemented using mutex map * Re-execute parallel tasks when there is a read in coinbase or burn address * Re-execute parallel tasks when there is a read in coinbase or burn address * using *sync.RWMutex{} in mutexMap Co-authored-by: Jerry <jerrycgh@gmail.com> * added getReadMap and getWriteMap (ethereum#473) * Block-stm optimization Added tests for executor and some improvements: 1. Add a dependency map during execution. This will prevent aborted tasks from being sent for execution immedaitely after failure. 2. Change the key of MVHashMap from string to a byte array. This will reduce time to convert byte slices to strings. 3. Use sync.Map to reduce the time spent in global mutex. 4. Skip applying intermediate states. 5. Estimate dependency when an execution fails without dependency information. 6. Divide execution task queue into two separate queues. One for relatively certain transactions, and the other for speculative future transactions. 7. Setting dependencies of Txs coming from the same sender before starting parallel execution. 8. Process results in their semantic order (transaction index) instead of the order when they arrive. Replace result channel with a priority queue. * Do not write entire objects directly when applying write set in blockstm * fixed a small bug in the Report function (ethereum#530) * linters Co-authored-by: Jerry <jerrycgh@gmail.com>
* fix: use Feevault address in the EVM BlockContext * bump version * revert format change * fix
and others
I wanted to list the differences from SEC 1 that I found while working on ECIES for ethereumj. SEC 1 says:
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 )
The text was updated successfully, but these errors were encountered: