problems with PGP/MIME

[Felipe Alvarez]

On Sat, 16 May 2009 20:13:55 Ingo Klöcker wrote:
> On Saturday 16 May 2009, webmaster at felipe1982.com wrote:
> > I will do my best to describe as succinctly and clearly as possible.
> > To begin, I use openSUSE, openoffice for documents, and 
[usually]
> > kmail for email. I created a document in OOo and clicked on the
> > 'email' button to send it to my "other" email address
> > xx at student.qut.edu.au [backup]. I sent the file signed and 
encrypted.
> > The other address has only a web interface, and as such, has no
> > support for PGP/MIME. As expected, I see two attachments,
> > application/pgp-encrypted "VERSION 1" file, and
> > application/octet-stream (my encrypted .odt file).
>
> The application/octet-stream attachment does not only contain your
> encrypted .odt file, but the whole MIME structure of your message
> (after signing and before encryption) including the attached .odt file.
>
> > It isn't actually
> > binary, it appeares in ASCII when downloaded and opened in text
> > editor. I ran it through Kgpg, and also separately through gpg
> > command line, and was disappointed that I did not recover my 
original
> > .odt file.
> >
> > The top portion contains email header information stuff (stuff I
> > don't want, or care to understand). There is a signature at the 
very
> > bottom, but verification fails (it is *my*own* pub/priv key pair).
>
> That's because KGpg probably does not know how to verify 
PGP/MIME
> signatures correctly.
>
> > In
> > the middle, above the signature, and below the email header stuff,
> > there is an ascii-armoured portion of data. I have not yet 
attempted
> > to select it all, copy, paste, decrypt, because I thought to myself,
> > "there must be a better (read: easier) way to do this..." So, is
> > there?
>
> The "ascii-armoured portion of data" is most likely the base64
> encoded .odt attachment. Try running it through
>
>   base64 -di < "ascii-armoured portion of data" >foo.odt
>
> base64 is part of the coreutils.
>
> > I forwarded the message back to my xx at felipe1982.com address, 
and
> > viewed it in kmail (which as you all know, supports cool things like
> > pgp/mime). But it (after submitting my passphrase) will not 
decrypt!
>
> Hmm. No idea unless you did not make sure that the message is 
also
> encrypted with your own key.
>
> > Is this the normal behaviour of pgp/mime. I did read a little (albeit
> > quickly and not in detail) of rfc3156 (is this the most recent?).
>
> In theory, PGP/MIME allows arbitrary complex hierarchies of signed 
and
> encrypted body parts.
>
> In practice, KMail (and probably most other PGP/MIME capable 
email
> clients) encrypt the whole message (except for the email headers) 
after
> the optional signing step, i.e. the text and all attachments. Now, if
> you decrypt the encrypted "attachment" in the received message, 
you
> will get something like you write above.
>
> I'm not sure what your use-case is. If it's for backup purposes (as
> indicated above), then I suggest to sign and encrypt the .odt file with
> KGpg and then attach this signed&encrypted attachment to a 
message.
> This message should then not be encrypted because otherwise 
you'll have
> the same situation as above. Signing the message should be okay.
>
>
> Regards,
> Ingo


As it turns out, the attachment was base64 encoded, and the code 
you asked me to run worked correctly and the file opened beautifully 
in Ooo again!
I restared Kmail, and this time it __did__ decrypt the message (it had 
failed to do this earlier). All-in-all, clients without pgp/mime are a PITA. 
Use ascii armour or encrypt attachments before attaching (not 
encryption after attaching as in pgp/mime.)

Felipe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 258 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20090517/229e2164/attachment.pgp>