È una coincidenza che i primi 4 byte di un file PGP / GPG siano ellissi, sorriso, segno femminile e un cuore?

Sì, è una coincidenza che i primi byte ti appaiono come questi simboli. Fanno parte delle specifiche del formato dei messaggi OpenPGP ( RFC 4880 ) e variano a seconda delle proprietà del pacchetto.

Creiamo un file contenente solo quei byte e prova a leggerlo come messaggio GPG:

$ echo "\x85\x02\x0c\x03" > foo.gpg && gpg --list-packets foo.gpg
# off=0 ctb=85 tag=1 hlen=3 plen=524
:pubkey enc packet: version 3, algo 255, keyid 0AFFFFFFFFFFFFFF
    unsupported algorithm 255

• Il primo byte ( 0x85 = 0b10000101 ) è il byte del tipo di cifratura (CTB) che descrive il tipo di pacchetto. Possiamo suddividerlo come segue:
  1 : bit dell'indicatore CTB
  0 : vecchio formato di pacchetto (vedi RFC 1991 )
  0001 : pacchetto crittografato con chiave pubblica
  01 : il campo lunghezza pacchetto è lungo 2 byte

• Il secondo e il terzo byte indicano la lunghezza del pacchetto ( 0x020c = 524 ).

• Il quarto byte ( 0x03 ) indica che è nel formato di pacchetto della versione 3.

Come puoi vedere, questi byte sono costanti di numeri significativi e non magici che puoi rimuovere senza perdere informazioni. Se li tagli, stai corrompendo il pacchetto GPG e sarà necessario qualche congettura per ricostruirlo.

I byte sono mostrati come smiley e cuori perché è così che il tuo terminale (probabilmente DOS) mostra caratteri di controllo non stampabili. Nei set di caratteri che provengono da code page 437 , i byte bassi al di fuori dell'intervallo ASCII stampabile sono tradizionalmente rappresentati come icone. Ecco il CP437 originale su un PC IBM:

(Fonte immagine)

Come principio generale, i formati di file binari ben progettati¹ avranno i loro primi pochi byte come un numero magico identificando il formato. I primi quattro byte dei file eseguibili ELF sono sempre 7f 45 4c 46, i primi otto byte dei file PNG sono sempre 89 50 4e 47 0d 0a 1a 0a e così via. I formati di file crittografati ben progettati seguiranno sempre quel numero magico con una "intestazione" non crittografata che rivela l'algoritmo di crittografia, la lunghezza dei dati crittografati, cose del genere.

Questo non è normalmente considerato una vulnerabilità di sicurezza, a causa del principio di Kerckhoffs , che dice che un cryptosystem ha bisogno per essere sicuro anche se l'hacker sa tutto ciò che l'intestazione del file può dire loro (come l'algoritmo).

È possibile progettare un formato di file, o un protocollo, tutti i cui byte sono indistinguibili dalla casualità a meno che tu non conosca già la chiave di decodifica, ma è sorprendentemente difficile (lo sapevi che la crittografia della durata prevista dei dati crittografati può introdurre una vulnerabilità ?) e in realtà non ti guadagna nulla. Un file completamente indistinguibile dall'output di cat /dev/random sarà altrettanto sospetto della polizia segreta come un file ovviamente crittografato con GPG. Forse più sospetto, anche perché ci sono tutti i tipi di motivi innocui per crittografare i file.

Se sei preoccupato che un hacker apprenda semplicemente che stai usando la crittografia per comunicare con qualcuno, devi steganografia , che nasconde informazioni segrete all'interno di file ordinari e non crittografati. Essere consapevoli del fatto che lo stato dell'arte nella steganografia non è tanto sofisticato quanto lo stato dell'arte nella crittografia; l'ultima volta che ho controllato, tutti gli approcci conosciuti erano irrisolti da un determinato avversario. (Se la prima impressione della polizia segreta è "oh, questa è una scheda di memoria piena di foto delle vacanze", potrebbero non preoccuparsi di scavare più a fondo ... a meno che non abbiano già un motivo per sospettare di te.)

¹ Non ho alcuna opinione sul fatto che il formato del file GPG sia ben progettato.