RFC 6637: campi specifici dell'algoritmo per ECDH

Question

RFC 6637: campi specifici dell'algoritmo per ECDH

#1 da (3 voti)

5

Sto cercando di integrare RFC 6637 in Bouncy Castle C # che è più impegnativo come inizialmente pensato perché sia la chiave privata che la chiave pubblica devono essere presenti per calcolare la condivisione segreta: quelli che non rientrano nell'API del castello gonfiabile.

Comunque, Sezione 10 della RFC definisce che una chiave pubblica deve essere codificata nel pubblico- Chiave chiave della sessione crittografata. È questa la chiave pubblica del mittente o del destinatario? In entrambi i casi, perché l'OID non ne fa parte, perché senza l'OID, il punto è più o meno inutile.

UPDATE: Ho appena usato lo strumento Command Line di Symantec Pgp per scaricare i pacchetti di ecc file crittografati. Ora capisco un po 'di più: per ogni crittografia, il mittente genera una nuova chiave ECDH che corrisponde alla curva del ricevitore e invia la nuova chiave pubblica come parte del pacchetto.

UPDATE 2:

RFC 6637 ora è completamente supportato. Controlla il repository .

pgp ecc

posta esskar 12.05.2013 - 02:15

fonte

1 risposta

Leggi altre domande sui tag pgp ecc

I nodi TOR possono raccogliere gli IP e filtrarli per smascherare gli indirizzi URL di .onion? Quante volte dovrei cambiare le mie password

score 3 · Accepted Answer

Nell'algoritmo Diffie-Hellman , il mittente e il destinatario devono giocare nello stesso gruppo - - nel caso di ECDH, la stessa curva. Le persone con coppie di chiavi non condividono gli stessi parametri di gruppo a priori (sebbene nel caso delle curve ellittiche ci siano pochissime "curve standard"). Se le coppie di chiavi di entrambi i mittenti e quelle del destinatario utilizzano la stessa curva, possono usarle per calcolare una chiave condivisa, ma, in generale, non è possibile assumerla.

Inoltre, PGP segue il contesto di posta elettronica, che è a senso unico: un singolo messaggio viene inviato dal mittente al destinatario e il destinatario non riceve notifica della transazione fino a quando l'email non viene effettivamente emessa. Il ricevitore è quindi completamente statico durante l'operazione. Pertanto, mittente e destinatario devono utilizzare il gruppo della coppia di chiavi del destinatario.

Ne consegue che il mittente deve (normalmente) creare una nuova coppia di chiavi, considerata "effimera" (questa è la parola importante nella sezione 10 di RFC 6637), solo per quell'invio di e-mail, in lo stesso gruppo della chiave del destinatario. Il mittente non memorizzerà quella chiave (da cui la denominazione). Il messaggio deve includere la parte pubblica della coppia di chiavi effimere del mittente, cioè un punto di curva; la curva OID non deve essere specificata perché, per definizione, viene utilizzata la curva del ricevitore: il ricevitore lo conosce già.

Nota: poiché il mittente utilizza una coppia di chiavi effimera nuova di zecca, non l'autenticazione del mittente è implicita da ECDH. Se il mittente desidera dimostrare la propria identità al destinatario, deve anche firmare la sua email, con la propria coppia di chiavi di firma non effimera.