No, tuttavia non è necessario. Alcune delle presunzioni non sono corrette per iniziare. Le cose che fai notare come problemi di sicurezza non sono necessariamente problemi reali. Lasciatemi entrare in maggiori dettagli.
MDC utilizza SHA-1 e MAC-then-Encrypt
L'MDC è progettato per evitare un attacco di orrore di decrittazione , così come corruzione accidentale. Entrambi questi problemi sono effettivamente mitigati anche quando si utilizza una funzione di hash "modesta". In effetti, anche MD5 probabilmente non causerebbe problemi, considerando che l'MDC agisce in modo simile a un MAC in cui la resistenza alle collisioni non ha importanza. L'uso di una funzione hash più strong non ti darebbe alcun beneficio reale. Per avere effettive garanzie di integrità, è necessario firmare digitalmente il messaggio. Ciò impedirà una vasta classe di attacchi che MDC non è in grado di eseguire. Nel complesso, MDC non è progettato per offrire una strong garanzia di integrità. Non è né previsto né in grado di farlo. Serve solo a proteggere da un attacco particolare e oscuro ea fornire protezione contro la corruzione accidentale che potrebbe portare alla decifrazione di un messaggio confuso.
BLAKE2 e Whirlpool non sono supportati
Per firmare un messaggio, viene utilizzata una funzione di hash. A tal fine, SHA-256 e SHA-512 vanno bene. In questa situazione, SHA-1 potrebbe non essere l'ideale, e per questa ragione, è stato eliminato gradualmente a favore di funzioni più forti. Mentre funzioni completamente diverse possono essere belle, non è necessario per la sicurezza. SHA-2 va bene. Sono completamente pre-resistenti e hanno un'ottima resistenza alle collisioni. Si noti inoltre che Whirlpool, pur non essendo approvato dal NIST, si basa direttamente su AES, che qualcuno che non ha alcuna fiducia nel NIST potrebbe voler evitare (non che ci siano motivi per sospettare che sia particolarmente debole). Gli attacchi a cui SHA-2 è vulnerabile (come gli attacchi di estensione della lunghezza) sono del tutto irrilevanti rispetto al modo in cui vengono utilizzati nel formato OpenPGP. Quando si presenta la necessità, è possibile aggiungere più hash.
Le curve NIST vengono utilizzate per ECC
Questo non è completamente vero. Una curva NIST (P-256, in particolare) viene utilizzata quando ECDSA è in uso, ma ECDSA viene deprecato a causa della stessi punti deboli che ha il normale DSA. È supportato, ma non è raccomandato o richiesto. Le versioni di GnuPG più recenti hanno una curva non NIST, in particolare Ed25519 per sostituire ECDSA. Non è altrettanto supportato, ma è più veloce e ha una sicurezza superiore. Vorrei anche notare che la P-256 e altre curve NIST non sono "note per essere compromesse", come si dice. Il problema con P-256 è che non usa numeri "niente-su-manica", rendendo teoricamente possibile che i valori siano stati scelti per abilitare una classe di attacchi ancora sconosciuti. Non ci sono prove concrete a riguardo, ma è bene essere cauti. Questo è uno dei motivi per cui ECDSA è stato sostituito da Ed25519.
I veri problemi
Ci sono problemi reali con GnuPG, ma non sono tra le cose che hai menzionato. Questi problemi tendono ad essere cose nuove che non erano una preoccupazione quando il formato OpenPGP era stato pensato:
- La segretezza di inoltro non è presente. Compromettere la chiave privata consente la decodifica retroattiva.
-
La crittografia post-quantica non è in uso. NTRU sarebbe fantastico, ma non è supportato.
-
Il Web of Trust è difficile da correggere, quindi molte persone che usano PGP tendono a fare affidamento su TOFU.
- GnuPG è molto complesso. Per l'analisi di formati complessi, un filtro seccomp stretto sarebbe bello.
- PGP implica concetti non intuitivi, che lo rendono difficile da usare. Ciò ostacola gravemente i tassi di adozione.