0

Is there any way to specify the textmode in BouncyCastle PGP encryption Java implementation?

I tried this but no luck (encrypted with UNIX line ending and decrypted in Windows):

PGPLiteralDataGenerator pgpldg = new PGPLiteralDataGenerator(false);
OutputStream ldout = pgpldg.open(compout, PGPLiteralData.TEXT, name, data.length, PGPLiteralData.NOW);
Jens Erat
  • 37,523
  • 16
  • 80
  • 96
user3295565
  • 3
  • 1
  • Is the text mode bit set (`gpg --list-packets`)? Is the behavior different if you use GnuPG on the command line (`gpg --textmode --encrypt`)? – Jens Erat Oct 20 '16 at 07:41
  • Yea, I tried GnuPG . I did encrypt a file with '**LF**' with text mode and decrypted in Windows. The file has '**CRLF**' as expected. – user3295565 Oct 20 '16 at 12:26

1 Answers1

1

RFC 4880, OpenPGP, 5.9. Literal Data Packet (Tag 11) defines that in text mode, data should be encoded with <CR><LF> line endings:

Text data is stored with text endings (i.e., network- normal line endings). These should be converted to native line endings by the receiving software.

GnuPG is doing so (--compress-algo 0 disables compression, --store just wraps the input in a literal data packet):

$ 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

Reading through BouncyCastle's source code for PGPLiteralDataGenerator and other called classes, I cannot find a single trace BouncyCastle is doing this (required) conversion. All I can find is that they write the encoding into the header (t, u or b). This is a BouncyCastle bug. They might fix it if you report it, otherwise (or until then), you have to add the carriage return on your own.

Community
  • 1
  • 1
Jens Erat
  • 37,523
  • 16
  • 80
  • 96