On Sat, 16 May 2009 20:13:55 Ingo Klöcker wrote: > On Saturday 16 May 2009, webmas...@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 > > x...@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 x...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
