Standard for ASCII Armored Message(RFC4880)

[GoogleCodeExporter]

The library bccrypto-net-1.7 don't have a correct parsing implementation for 
the ASCII Armored Message parser as explained in RFC4880.
Attached is an example what for Kleopatra but doesn't works for 
bccrypto-net-1.7.

The exact error is parsing the headers: ArmoredInputStream.ParseHeaders(). I 
have done a fix but this specific  case but not is not recommended for 
production environment.

Original issue reported on code.google.com by willg...@gmail.com on 22 Mar 2014 at 7:04

Attachments:

• example.txt

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Sorry, this file is not correct formatted.
Even GnuPG complains about it

gpg.exe --list-packets example.txt
gpg: invalid armor header: 
hQIMA9tEsPXBYr2AARAAwHZIGOmW9J+64Aro1RGhBZaDTmbeS4wOm7g4QHyA9q\r\n
:pubkey enc packet: version 3, algo 1, keyid DB44B0F5C162BD80
        data: [4096 bits]
:encrypted data packet:
        length: 313
        mdc_method: 2
gpg: encrypted with RSA key, ID C162BD80
gpg: decryption failed: secret key not available

RFC4880 also states, that there must be a blank line between the headers and 
data.

Section 6.3
Concatenating the following data creates ASCII Armor:
     - An Armor Header Line, appropriate for the type of data
     - Armor Headers
 >>>>- A blank (zero-length, or containing only whitespace) line
     - The ASCII-Armored data
     - An Armor Checksum
     - The Armor Tail, which depends on the Armor Header Line

I wonder what software is creating such a PGP block?

Original comment by tobi...@googlemail.com on 24 Mar 2014 at 7:35

[GoogleCodeExporter]

Hello 

You are right :-). But the section 6.2 Forming ASCII Armor define the way that 
corrupted header must be managed :-).

The section state:

 OpenPGP should consider improperly formatted Armor Headers to be
 corruption of the ASCII Armor.  Unknown keys should be reported to
 the user, but OpenPGP should continue to process the message.

The idea in the standard is: because the header is not part of the signature or 
encryption the message can be processed. That is exactly what is doing 
Kleopatra (the internal library used, of course :-)).

I am guessing the the signature was created by "http://gpg4win.org/" but in the 
copy and paste operation added some corruption :-). 

Original comment by willg...@gmail.com on 24 Mar 2014 at 1:06

[GoogleCodeExporter]

Thanks for the bug report. This sounds like a bug for bouncy castle, as they 
are the underlying pgp library in use. If they fix it, I will happily move to 
the newer version :)

Original comment by m...@dejavusecurity.com on 5 Apr 2014 at 8:35

• Changed state: WontFix