Added new EIP for PQ keystore #1
Conversation
| 1. **Key Derivation Function (KDF)** | ||
| - Replaces PBKDF2 with more secure, memory-hard alternatives: | ||
| - `argon2id` (preferred) | ||
|
|
||
| 2. **Authenticated Encryption** | ||
| - Encryption must use an AEAD (Authenticated Encryption with Associated Data) scheme: | ||
| - `aes-256-gcm` | ||
| - or `xchacha20-poly1305` | ||
| - MAC (message authentication code) is integrated into the encryption tag, eliminating the need for a separate field |
|
hey here are some ballpark no (there are with the sha hash fn)
so the idea would be to store the prf keys and generate the epoch based keys when required What have you guys implemented/thought about this ?? |
| 4. **Post-Quantum Declaration** | ||
| - Introduces a `quantum_secure: true` flag to explicitly indicate use of post-quantum |
There was a problem hiding this comment.
I don't think this flag is needed, as the version and primitives we use are enough.
There was a problem hiding this comment.
The idea was to have an explicit flag in the keystore file to indicate that it is quantum_secure. Otherwise, we ought to assume that version above above > 4 is considered quantum secure.
There was a problem hiding this comment.
I would emphasize that quantum_secure flag doesn't guarantee anything. If one JSON file uses EIP-2335 format but only adding quantum_secure: true, is this "quantum-safe"? Or what if the file satisfies all the requirements but making quantum_secure: false?
IMHO a specification should be clear enough so that implementers shouldn't worry about those edge cases.
There was a problem hiding this comment.
I would emphasize that
quantum_secureflag doesn't guarantee anything. If one JSON file uses EIP-2335 format but only addingquantum_secure: true, is this "quantum-safe"? Or what if the file satisfies all the requirements but makingquantum_secure: false?
Ofcourse. You are absolutely correct. Just because we have a flag, it doesn't mean the keystore adheres to the format. I am happy revise the spec to indicate that version=5 means it is quantum_secure.
| { | ||
| "properties": { | ||
| "memory": { "type": "integer" }, | ||
| "iterations": { "type": "integer" }, | ||
| "parallelism": { "type": "integer" }, | ||
| "salt": { "type": "string", "pattern": "^[a-fA-F0-9]+$" } | ||
| }, | ||
| "required": ["memory", "iterations", "parallelism", "salt"] | ||
| }, |
There was a problem hiding this comment.
What's the benefit for providing this "Full" option? This requires few more bytes without any additional functionality. If the spec is clear enough and well-descriptive, using short option seems fine (and also consistent with existing keystore formats like Web3 secret storage definition and EIP-2335)
| The keystore format MUST conform to the following schema: | ||
|
|
||
| ```json | ||
| { |
There was a problem hiding this comment.
Is this schema valid? It seems it's different with the examples below.
Co-authored-by: Jun Song <[email protected]>
Co-authored-by: Jun Song <[email protected]>
4 participants
No description provided.