ECC in PGP (aperto)

23

In che modo è supportato ECC (Crittografia delle curve ellittiche) in PGP (aperto) finora? Sembra che GnuPG (The GNU Privacy Guard) non abbia un'implementazione ufficiale - ma ho trovato il progetto gnupg-ecc ( GnuPG abilitato per ECC per RFC 6637 ) su Google Code:

This project brought to life Elliptic Curve Cryptography support in OpenPGP as an end-user feature. Users can simply select an ECC key generation option in

gpg2 --gen-key

and then use the generated public key as they normally would use any other public key, as shown here.

So che Symantec supporta ECC. Ci sono dei motivi per non usare ECC?

Modifica

Ho fatto qualche ricerca in più e ho scoperto che ECC ha scoperto che è un modo per raggiungere la linea principale di gnupg da molto tempo, ma solo nel versione per sviluppatori :

$ gpg2 --expert --gen-key
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
Please select what kind of key you want:
    (1) RSA and RSA (default)
    (2) DSA and Elgamal
    (3) DSA (sign only)
    (4) RSA (sign only)
    (7) DSA (set your own capabilities)
    (8) RSA (set your own capabilities)
    (9) ECDSA and ECDH
   (10) ECDSA (sign only)
   (11) ECDSA (set your own capabilities)
Your selection?'
    
posta esskar 19.04.2013 - 02:54
fonte

3 risposte

23

Vedo due motivi principali per cui potresti non voler utilizzare ECC :

Motivo pratico: la comunicazione coinvolge necessariamente due parti, il mittente e il destinatario. ECC può essere utilizzato solo se sia il mittente che il ricevente lo supportano. Come hai notato, le implementazioni esistenti e implementate non sono ancora all'altezza; se utilizzi una chiave pubblica ECC, le persone potrebbero inviarti messaggi crittografati con quella chiave o verificare le tue firme con quella chiave, solo se la loro implementazione di OpenPGP include il codice pertinente.

Quindi la tua scelta di ECC o non ECC dipende dal fatto che tu voglia massimizzare l'interoperabilità o preferisci essere un "early adopter" (sebbene nel caso di ECC ci siano già degli early adopter, ECC sta diventando mainstream)

Motivo morale: matematicamente, non abbiamo la prova che tutti gli algoritmi crittografici che impieghiamo siano davvero affidabili contro gli attacchi. Non sappiamo nemmeno se sia possibile matematicamente robusto contro gli attacchi. In questo momento, l'unico metodo che dobbiamo valutare la forza di qualsiasi algoritmo crittografico è definirlo, e quindi lasciare che molti crittografi lavorino su di esso per alcuni anni. Se nessuna di queste persone intelligenti ha trovato qualcosa di sbagliato nell'algoritmo, allora puoi sapere che se l'algoritmo è debole, allora, almeno, non è ovviamente debole.

Le curve ellittiche sono state proposte come oggetti adatti alla crittografia nel 1985 (da Koblitz e Miller, indipendentemente). La matematica delle curve ellittiche è stata studiata per circa 40 anni prima. Quindi ECC può praticare circa 70 anni di esposizione, 30 dei quali in un contesto decisamente crittografico. Non è male.

La fattorizzazione di interi , su cui si basa RSA, può vantare 35 anni di esposizione crittografica (RSA è stata proposta nel 1978) e più di un 2500 anni per la matematica sottostante. Pertanto si può affermare che la sicurezza di RSA è "più comprensibile" rispetto a quella delle curve ellittiche.

Personalmente, penso che ECC sia abbastanza maturo da essere implementato, e dal momento che ECC è molto di moda, le implementazioni diventano comuni e possiamo aspettarci che GnuPG si allinei presto. Pertanto, la mia raccomandazione è: ECC va bene, a patto che tu sia pronto a incontrare alcuni problemi di interoperabilità per alcuni anni.

(Un punto oscuro della distribuzione ECC è che ci sono pochissime implementazioni ECC "generiche", la maggior parte delle implementazioni sono specifiche per un insieme limitato di curve supportate, spesso limitate alle due curve NIST P-256 e P-384. la scelta della curva per la tua chiave ha quindi un impatto non banale sull'interoperabilità: P-256 va bene per sicurezza, quindi puoi usarlo e smettere di preoccuparti.)

    
risposta data 19.04.2013 - 13:47
fonte
9

Attualmente, ECC è supportato in GnuPG 2.1 beta. Puoi compilarlo dal sorgente e vedere di persona che sono supportate le seguenti curve:

nistp256 nistp384 nistp521 brainpoolP256r1 brainpoolP384r1 brainpoolP512r1 secp256k1

    
risposta data 01.07.2014 - 05:29
fonte
5

in GPG, per sicurezza, uno starebbe lontano da brainpool e curve nist. Le curve edDSA, montgomery e edwards vanno bene. ed25519 è fortunatamente schierato senza subrterfuge per ora.

Anche se è solo per la firma / certificazione / autenticazione. La crittografia seguirà.

le mailing lists su ietf.org sono ottimi punti di partenza e anche il controllo di cryp.to.

L'uso di ECC con l'implementazione di follia è peggiore dell'uso di RSA.

    
risposta data 03.02.2015 - 06:28
fonte

Leggi altre domande sui tag