problems with PGP/MIME
webmaster at felipe1982.com
Sat May 16 16:16:08 CEST 2009
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
> > 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
> > 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
> > .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
> > bottom, but verification fails (it is *my*own* pub/priv key pair).
> That's because KGpg probably does not know how to verify
> 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
> > 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,
> > viewed it in kmail (which as you all know, supports cool things like
> > pgp/mime). But it (after submitting my passphrase) will not
> Hmm. No idea unless you did not make sure that the message is
> 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
> encrypted body parts.
> In practice, KMail (and probably most other PGP/MIME capable
> clients) encrypt the whole message (except for the email headers)
> the optional signing step, i.e. the text and all attachments. Now, if
> you decrypt the encrypted "attachment" in the received message,
> 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
> This message should then not be encrypted because otherwise
> the same situation as above. Signing the message should be okay.
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.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 258 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-users