Can KeyMaterial be Vec-based?
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 42/100
- Tipo di issue
- Refactoring
- Chiarezza
- Da chiarire
- Stato di attività
- Tranquilla
- Stack tecnologico
- rust
- Ambito
- cryptography
Direzione di ricerca
Start by tracing KeyMaterial and Secret definitions and their uses across the library. Compare Secret<Vec> with Vec<Secret> against Secret's current statically sized zeroization, while preserving the existing KeyMaterial128, KeyMaterial256, and KeyMaterial512 aliases. Done means the representation choice is established and the library's key-material behavior remains secure.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
If we are standardizing on always assuming a memory allocator, then we can consider making KeyMaterial carry a Vec<u8> instead of a [u8; KEY_LEN], which would reduce a number of friction points across the library.
pub struct KeyMaterial<const KEY_LEN: usize> {
buf: Secret<[u8; KEY_LEN]>,
key_len: Secret<usize>,
key_type: KeyType,
security_strength: SecurityStrength,
allow_hazardous_operations: bool,
}
The core change would be pretty simple: keep the <const KEY_LEN: usize>, but change it to <const INITIAL_CAP: usize> so that the type aliases for KeyMaterial128, KeyMaterial256, KeyMaterial512 are still there, and efficient about not needing to up-allocate for the common cases.
Then change buf: Secret<[u8; KEY_LEN]> to buf: Secret<Vec<u8>> or possibly buf: Vec<Secret<u8>>.
This will require some thought about Secret since currently it can only handle statically-sized types due to how the zeroizer is implemented. Possibly buf: Vec<Secret<u8>> is the right answer and does not require any changes to Secret.
- Lingua principale
- Rust
- Stelle
- 25
- Fork
- 18
- Merge medio
- 16h 38m
- PR unite (30g)
- 3
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di bcgit/bc-rust
-
good first issue refactor
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
API Gap: KeyPairGenerator Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 58/100
Tutte le issue di bcgit/bc-rust
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
gitbutlerapp/gitbutler#15998 · 1 commento ·
-
bug triage:deciding
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100