-----BEGIN PGP SIGNED MESSAGE-----
In <98May9(_dot_)191656edt(_dot_)43009(_at_)brickwall(_dot_)ceddec(_dot_)com>,
on 05/09/98
at 07:16 PM, dontspam-tzeruch(_at_)ceddec(_dot_)com said:
On Sat, 9 May 1998, William H. Geiger III wrote:
Hi,
I am having a little problem in parsing signed messages following the
draft documentation.
Both PGP 2.6.x & 5.0 produce the following (output as binary file):
A3 01 01 AF 00 50 FF [remained is signature block]
I take it you compressed a zero-byte file? The problem is a bug in PGP
signing zero byte files, where instead of doing something right, it does
what you show above, and something more (read on).
No I did not. I used a small 7 byte text file (test.txt) that contained:
hello<cr><lf>
It was signed with my 1024 RSA key0xFE68B861.
3 - The packet is of indeterminate length. The header is 1 octet
long, and the implementation must determine how long the packet
....
Obviously this is not the case as the compressed data packet does not
cover the entire file as there is a signature packet that follows.
Buried in some old 2.6.2 docs it says something different. Functionally
a type of 3 means that the function, i.e. algorithm can determine when
the EOF is (which zip does).
The RFC needs to be updated to reflect this information as it is how PGP
is currently generating these messages.
Now the next octet (01) represents zip compression algorithm.
Where I am having problems is with the remaining 5 octets. I have read
through RFC1591 and I am still lost at decodeing the remainder of this
compression packet.
At this point I am not intrested in Inflating the data but calculating the
length of the compressed packet so I can find the start of the sig block
for sepeate processing.
You must inflate (to /dev/null if needed or simply dump the stuff in the
output buffer) as the only way to know where the compressed data ends.
So I have to dump the entire file to the Inflate() function and then
re-parse the packets after inflation? Not a very pretty solution.
Also Section 10.2 does not seem accurate as:
This is a bug in PGP since if you have even one byte of data, what would
be compressed would be sig,literal(data).
Well I don't know if I would call it a bug since this is how both 2.6.x &
5.0 generate this file using RSA key for signing.
Also you might notice a trailing literal with the file type, name, and
time, but with zero bytes. So the actual format might be (zero byte
compressed packet)(signature packet)(literal packet).
IMHO we need a section in the RFC outlining the format PGP is currently
using when creating a binary, signed text file as implementers will have
to be able to process these messages.
I have attached a copy of the file here, my key is available off the
keyservers if anyone want's to use it to verify the sig block. test.pgp is
hello<lf><cr> signed with 2.6.3a and test8.pgp is the same file signed
with 5.0i.
- --
- ---------------------------------------------------------------
William H. Geiger III http://users.invweb.net/~whgiii
Geiger Consulting Cooking With Warp 4.0
Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://users.invweb.net/~whgiii/pgp.html
- ---------------------------------------------------------------
begin 666 test.pgp
MHP$!KP!0_XD`E0,%`#53YX:/0J-9_FBX80$!NEL#_1((S03DXQX$C,#?!U*/
M]J,UW9G"5X:8%P?[5=:C/V%$S9*%/AP-"6$.LQYFGMQWL7U95_(^:AO1[=*'
M!E>_%EU7-/-8.9['^?!98THT&2`0#Z\=S9B^-V1LZ6(Y')1&YLV=X#+6SS">
M'*945KU+N2"G,,O2?4.>VBJ*G%HB7625K!5B"'1E<W0N='AT`````&AE;&QO
"#0I4
`
end
begin 666 test8.pgp
MHP$!KP!0_XD`E0,%`#54P!N/0J-9_FBX80$!8V4$`*%3@(5W./K??NEUBX-X
M[Z8^3QIQ,:1M;&G<905H\JL6U[T&*'<D-D7H9081R"TA"MH%?/*3PW4X4!1Q
MX6G1AQHO?*<P',RG52I(N\>(JGQ8EKBVE;8=C-+`ON:;VL\S4GXKW+:S\**0
M2I(NP:>3(_at_)Q)##85X+?WDX5L[,<YWS)JYK!5B"'1E<W0N='AT`(_at_)```&AE;&QO
"#0HN
`
end
Tag-O-Matic: Windows: From the people who brought you EDLIN!
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000
iQCVAwUBNVUXnY9Co1n+aLhhAQHA0AP/Wxa34ZDzA7ma/NreZuIvJDgsK/Wu9w1M
Q22qtIx60ovGb+giRvY+UJuh4XN3h00gA+nQNBYVF6kf/T1c8Vdv8pLLSlVwwOVS
12rNyltZ6IOWyLEVEPPbWYdoGskR2//uOjyO4V5aR36kYjfuFWUSTn4Imbj4MalQ
5hnCrJAuWSE=
=saiO
-----END PGP SIGNATURE-----