RFC 4880, OpenPGP, 5.9. Literal Data Packet (Tag 11) définit qu'en mode texte, doivent être données codées avec <CR><LF> fins de ligne:
Les données textuelles sont stockées avec des fins de texte (c.-à-d., Réseau- terminaisons de ligne normales). Ceux-ci doivent être convertis en terminaisons par le logiciel de réception.
GnuPG fait donc (--compress-algo 0 désactive la compression, --store juste encapsule l'entrée dans un paquet de données littérale):
$ echo -e "foo\nbar" | gpg2 --textmode --compress-algo 0 --store | hexdump -c
0000000 � 020 t \0 X \b � u f o o \r \n b a r
0000010 \r \n
0000012
La lecture de BouncyCastle's source code for PGPLiteralDataGenerator et d'autres classes dites, je ne peux pas trouver une seule trace BouncyCastle est faire cette conversion (obligatoire). Tout ce que je peux trouver, c'est qu'ils écrivent le codage dans l'en-tête (t, u ou b). C'est un bug BouncyCastle. Ils pourraient le réparer si vous le signalez, sinon (ou jusque-là), vous devez ajouter le retour de chariot sur votre propre.
Le bit de mode texte est-il défini ('gpg --list-pack'')? Le comportement est-il différent si vous utilisez GnuPG sur la ligne de commande ('gpg --textmode --encrypt')? –
Oui, j'ai essayé GnuPG. J'ai crypté un fichier avec '** LF **' avec le mode texte et décrypté dans Windows. Le fichier a '** CRLF **' comme prévu. – user3295565