PGP encrypted file as attachment
Tomisław Kityński
I am trying (programatically, in java with cryptix package) to send a mime
message
containing text/plain message and an attachment. This attachment is supposed
to
be pgp-encrypted file. After reading some rfc-s, I found, that encrypted
data in
mime message must be declared as multipart message with Content-Type set to
"multipart/encrypted" with parameter "protocol" equal to
"application/pgp-encrypted" (and of course boundary parameter).
This multipart message is supposed to contain two bodies: first with
Content-Type
declared as "application/encrypted" and content equal to "Version: 1" and
the second
body's Content-Type declared as "application/octet-stream" containg
pgp-armoured
message.
So the structure of the whole message looks like this:
+- Mime-Headers
|
+- Multipart (multipart/mixed)
|
+- BodyPart (text/plain)
|
| This message contains pgp-encrypted attachment. (Well...)
|
+- Multipart (multipart/encrypted; protocol="application/pgp-encrypted")
|
+- BodyPart (application/encrypted)
|
| Version: 1
|
+- BodyPart (application/octet-stream)
|
| -----BEGIN PGP MESSAGE-----
| Version: Cryptix OpenPGP 0.20010829
|
| hQEOA6n2Fh9n2QOiEAP/cYtXmApbCKIooR9ZKGmPnz+kEGsFoNYf7RI1aY+uu+Kp
| ...
| =GzhA
| -----END PGP MESSAGE-----
I use ms-outlook as an e-mail reader. When I open the message I see actually
the attachment icon, but when I click on that button, I can see two files
in there --- one for application/encrypted body and second for
application/octet-stream
body.
Since I am completly new to PGP, my question is --- is that okay to see two
files
in there? And is this okay to see armoured pgp message instead of some
"please
select your private key to decrypt the message" requester after clicking on
the
octet-stream body? (Or maybe outlook just does not support
multipart/encrypted mime
messages)? If this is the latter case, is there any pgp-enabled mail client
that
would act similar to what I've just described (mainly it's about to show
just one,
encrypted file and after clicking on it to ask for private key)?
I'd appreciate your help, thank you in advance,
sincerly,
TK.
Neil W Rickert
Hash: SHA1
<non-ex...@nowhere.com> writes:
>I am trying (programatically, in java with cryptix package) to send a mime
>message
>containing text/plain message and an attachment. This attachment is supposed
>to
>be pgp-encrypted file. After reading some rfc-s, I found, that encrypted
>data in
>mime message must be declared as multipart message with Content-Type set to
>"multipart/encrypted" with parameter "protocol" equal to
>"application/pgp-encrypted" (and of course boundary parameter).
Okay. But, from your first sentence, you are not sending an
encrypted mime message. Rather, you are sending an unencrypted
message with an encrypted attachment.
Presumably it is okay to use the same standard, in that MIME is
recursive (a mime component can contain a mime structure). But you
are not compelled to do so. You could just attach the encrypted part
as an application/pgp .
>I use ms-outlook as an e-mail reader.
My sympathies.
> When I open the message I see actually
>the attachment icon, but when I click on that button, I can see two files
>in there --- one for application/encrypted body and second for
>application/octet-stream
>body.
I would assume that the PGP plugin for outlook can handle this. But
perhaps you have confused it with your way of structuring the mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (SunOS)
iD8DBQFAeGg9vmGe70vHPUMRAoZeAKC3B/qFCulqPJjenIqqSybAphebzgCgnsmv
iPuSX22hfLtDIBAAkncfzCs=
=vgC4
-----END PGP SIGNATURE-----
Tomisław Kityński
news:c59p85$rij$1...@usenet.cso.niu.edu...
> >I am trying (programatically, in java with cryptix package) to send a
mime
> >message containing text/plain message and an attachment. This attachment
is
> >supposed to be pgp-encrypted file. (...)
>
> Okay. But, from your first sentence, you are not sending an
> encrypted mime message. Rather, you are sending an unencrypted
> message with an encrypted attachment.
That's exactly what I am trying to do. 8)
> Presumably it is okay to use the same standard, in that MIME is
> recursive (a mime component can contain a mime structure). But you
> are not compelled to do so. You could just attach the encrypted part
> as an application/pgp .
I've changed my app as you suggested and in fact it seems to work too.
I wonder what is the whole confusion with multipart/encrypted and
application/encrypted stuff. I don't remeber now exactly, but I guess
I have found somewhere on the net (with google) someone's post (or
was it more official document? I really don't remember now) where
it was written, that application/pgp for some reason should be replaced
with the combination I was talking about in the very begining. But
as I am newbe, I suppose I should stick with your words. 8)
> >I use ms-outlook as an e-mail reader.
>
> My sympathies.
;-) Believe me, I am not the fan of this software too. The same is about
the OS it is running on. ;-) Unfortunately I have to write an application
that sends daily report of the volume of my company to its bussines
partner and the data I send, as you already have guessed, must be
protected. Unfortunatley our partner uses, let's say, "professional"
software, ;-) so I need to test it under outlook. Yeah, bad karma. ;-)
And as it's only mail reader I have under windows, I am currently
forced to use it. 8(
> I would assume that the PGP plugin for outlook can handle this. But
> perhaps you have confused it with your way of structuring the mail.
I've downloaded some plugin (Windows Privacy Tray). It seems like
there is no difference for outlook to parse multipart or bodypart
pgp-encrypted file --- the result in both cases is the same --- it
does not handle this. ;-) But the plugin prompts for passphrase
and although it doesn't display decrypted zip file, I believe
our partner would be able to understand, that they need first
to save the file on the disk and _then_ use this plugin to decrypt
the attachment...
Well, I have two more question --- do I need to add .pgp extension
to the encrypted file? It looks like when it ends with .zip, outlook
is ignoring mime-type declared in the bodypart of the attachment
(it tries to open the zip, but it fails, since it's encrypted).
Second question is, do I need to send the attachment as pgp-armoured
message? Well, in fact the attachment would be encoded with base64
anyway, so there is no gain, but out of curiosity, would it be wrong
to send it as 8bit stream (no encoding)?
Uhm, and I have this little request --- I don't really want to bother
you and waste your time, but uhm, would you please allow me to send
you that generated e-mail (and the test keys and passphrase) so you
could take a look if is this correctly composed and if pgp-enabled
mail-reader can handle it properly? Of course I'll understand when
you refuse. 8)
Anyway, thank you very much for fast and helpful answer, 8)
best regards,
TK.
Neil W Rickert
Hash: SHA1
<non-ex...@nowhere.com> writes:
>Użytkownik "Neil W Rickert" <ricke...@cs.niu.edu> napisał w wiadomości
>news:c59p85$rij$1...@usenet.cso.niu.edu...
>> >I am trying (programatically, in java with cryptix package) to send a
>mime
>> >message containing text/plain message and an attachment. This attachment
>is
>> >supposed to be pgp-encrypted file. (...)
>> Okay. But, from your first sentence, you are not sending an
>> encrypted mime message. Rather, you are sending an unencrypted
>> message with an encrypted attachment.
>That's exactly what I am trying to do. 8)
>> Presumably it is okay to use the same standard, in that MIME is
>> recursive (a mime component can contain a mime structure). But you
>> are not compelled to do so. You could just attach the encrypted part
>> as an application/pgp .
I was a little mistaken there. It is part of the standard for
pgp/mime, that what is encrypted includes MIME headers. If your
separate encrypted attachment did not contain at least a
"Content-Type:" header in the clear text before encryption, then
there is no way that what you were doing good be a valid message.
>I've changed my app as you suggested and in fact it seems to work too.
>I wonder what is the whole confusion with multipart/encrypted and
>application/encrypted stuff.
The idea is that you encrypt the entire MIME component, including
MIME headers. This allows a multi-part mime message to be sent
encrypted. The decrypting software expects to fine those MIME
headers, so that it can reconstruct the entire original multipart
message. A single part message is just a special case.
Looking at a pgp/mime message in my mailbox, the very first line
after decrypting the PGP component is
Content-Type: text/plain; charset=us-ascii
> I don't remeber now exactly, but I guess
>I have found somewhere on the net (with google) someone's post (or
>was it more official document? I really don't remember now) where
>it was written, that application/pgp for some reason should be replaced
>with the combination I was talking about in the very begining. But
>as I am newbe, I suppose I should stick with your words. 8)
That is talking about how you should handle a full mail message.
Certainly, application/pgp was a kludge that allowed you to put an
old-style pgp component in as an attachment. Since that is precisely
what you are wanting to do, that kludge is the appropriate thing for
you to use. But it is limited. If you wanted to send a multi-part
message that way, then you would either encrypt only one part, or you
would have to seperately encrypt each part (and the recipient would
have to seperately decrypt each part). That's a bit cumbersome. The
better pgp/mime standard handles the encryption of an entire
multi-part message as a single PGP component.
>Well, I have two more question --- do I need to add .pgp extension
>to the encrypted file? It looks like when it ends with .zip, outlook
>is ignoring mime-type declared in the bodypart of the attachment
>(it tries to open the zip, but it fails, since it's encrypted).
Sorry, I can't help you with that. I use windows only casually. I
am mainly a unix person. In the unix world, the file type is
normally derived from the mime type or from the file contents. The
file name is rarely important. The windows way of handling types
seems to be part of a diabolical scheme to flood the world with
computer viruses :-(
>Second question is, do I need to send the attachment as pgp-armoured
>message? Well, in fact the attachment would be encoded with base64
>anyway, so there is no gain, but out of curiosity, would it be wrong
>to send it as 8bit stream (no encoding)?
If sending in email, it would have been better to encrypt as
pgp-armored, and then to send that directly (no further base64
encoding). I sometimes have students who encrypt as a binary
encrypted file, and send that base64 encoded. I usually have to
manually decrypt that. It isn't what email software expects to deal
with.
>Uhm, and I have this little request --- I don't really want to bother
>you and waste your time, but uhm, would you please allow me to send
>you that generated e-mail (and the test keys and passphrase) so you
>could take a look if is this correctly composed and if pgp-enabled
>mail-reader can handle it properly? Of course I'll understand when
>you refuse. 8)
If you want to do that, sure. My address in this message does work.
I would mainly try examining with exmh and with mutt (both on unix).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (SunOS)
iD8DBQFAeV/bvmGe70vHPUMRApUsAKCCz2F311ABAC4TvwR2jt/ippLgGQCcCk3E
IHRehRcYAxwDzuNhSRPGO1M=
=6Nv/
-----END PGP SIGNATURE-----
Tomisław Kityński
> I was a little mistaken there. It is part of the standard for
> pgp/mime, that what is encrypted includes MIME headers. If your
> separate encrypted attachment did not contain at least a
> "Content-Type:" header in the clear text before encryption, then
> there is no way that what you were doing good be a valid message.
I did some tests. The whole message was always multipart/mixed,
first body-part was text/plain and second was application/pgp.
In first test I simply encoded tgz archive with pgp, converted
it to pgp-armoured message and placed that text as content
of the application/pgp part. Headers looked like this:
Content-Type: application/pgp; name="tgzipped.tgz.pgp"
Content-Disposition: attachment; filename="tgzipped.tgz.pgp"
Content-Transfer-Encoding: 7bit
In the second case, the header were looking exactly the same,
but I have had prepended the tgz data with these headers:
Content-Type: application/x-gzip; name="tgzipped.tgz"
Content-Disposition: attachment; filename="tgzipped.tgz"
Content-Transfer-Encoding: 8bit
Wach line has ended with <crlf> and the last line was separated
from the content with empty <crlf> line. Then the data followed.
This was then pgp-encrypted.
In both cases I was actually only able to save the attachment
to the disk, since the pgp plugin for outlook admittedly asks for
the passphrase after clicking on the attachment, but does not
do anything more (well, I consider it as this plugin fault).
Anyway, after saving the attachment I was able to decrypt it.
In the first case I got proper tgz archive, but in the second case
I got... tgz archive with preceding headers. So I had to treat
it as an email (what means that I had to change the extension to eml)
open it, and after it showed empty letter with attachment, I was
able to save the proper archive. So it looks like this pgp
plugin does not handle such files in proper manner (according
to what you described). And now I don't know if shall I stick with
what you said about including MIME headers in encoded data (what
causes here some problems) or simply send the encoded data just
like in the first example. Could you please give me your point
of view on that?
> The idea is that you encrypt the entire MIME component, including
> MIME headers. This allows a multi-part mime message to be sent
> encrypted.
As stated above, I've encrypted single body-part (with its headers)
and it didn't work as expected. I suppose, that when I would use
multipart/encrypted with application/encrypted and application/octet-stream
parts, I would get the same result --- I mean I would have to rename
decrypted attachment to *.eml, open that message (where I could
see two attachements --- application/encrypted and application/octet-stream)
and finally save the latter one to get the file. So this is probably
more confusing for the recipient --- or maybe this is the outlooks' faul?
> The decrypting software expects to fine those MIME
> headers, so that it can reconstruct the entire original multipart
> message. A single part message is just a special case.
But as I understand, since I want to encode just one file,
I do not need to put it in multipart/encrypted multipart message
(together with application/encrypted) and to put this multipart
as the attachment body-part of the enclosing multipart/mixed message?
In other words --- is it save/proper to put in multipart/mixed
application/pgp body-part?
> Looking at a pgp/mime message in my mailbox, the very first line
> after decrypting the PGP component is
>
> Content-Type: text/plain; charset=us-ascii
Hmm, but isn't that because it's the text? I mean the plain
text could have many different encodings, so there is a chance,
that you would not know in what charset was it composed. And that's
why there is Content-Type included in the text body-part (but as
I suppose the most important thing in this header is the charset
attribute).
And in the case of binary files maybe it's not very handy or even
confusing to include Content-Type header before the data, since the
recipient need to strip this header manually and in fact this header
doesn't give him any useful information. How is this in real?
> That is talking about how you should handle a full mail message.
> Certainly, application/pgp was a kludge that allowed you to put an
> old-style pgp component in as an attachment. Since that is precisely
> what you are wanting to do, that kludge is the appropriate thing for
> you to use.
I see. The question is yet should I include MIME headers in
encrypted data?
> But it is limited. If you wanted to send a multi-part
> message that way, then you would either encrypt only one part, or you
> would have to seperately encrypt each part (and the recipient would
> have to seperately decrypt each part). That's a bit cumbersome. The
> better pgp/mime standard handles the encryption of an entire
> multi-part message as a single PGP component.
Oh, I see now, yeah, it would be indeed more conviniet to decrypt
it once even at the price of renaming the saved attachment to *.eml
and saving these files in there manually (but as I suppose pgp-enabled
mail-reader should handle this transparently).
> Sorry, I can't help you with that. I use windows only casually. I
> am mainly a unix person. In the unix world, the file type is
> normally derived from the mime type or from the file contents. The
> file name is rarely important. The windows way of handling types
> seems to be part of a diabolical scheme to flood the world with
> computer viruses :-(
Yes, that's very true. I never liked this way of recognizing file types.
The most flexible way I've known is probably the way AmigaOS's file-type
extensions handle this. You can define many conditions to determine
file type (like filename patterns, content signatures, there's even
hierarchical organization of these types), but well, it's not in the
scope of this topic. 8)
> If sending in email, it would have been better to encrypt as
> pgp-armored, and then to send that directly (no further base64
> encoding). I sometimes have students who encrypt as a binary
> encrypted file, and send that base64 encoded. I usually have to
> manually decrypt that. It isn't what email software expects to deal
> with.
I see, that's a good point. 8)
> If you want to do that, sure. My address in this message does work.
> I would mainly try examining with exmh and with mutt (both on unix).
So okay --- I am sending you two versions of the email as described
at the begining. I wonder which would be more "friendly" to pgp-aware
reader.
Thank you very much for your time,
sincerly,
TK.
Tomisław Kityński
wiadomości news:c5csms$b2r$1...@korweta.task.gda.pl...
> So okay --- I am sending you two versions of the email as described
> at the begining. I wonder which would be more "friendly" to pgp-aware
> reader.
The passphrase is: "TestingPassphrase"
Rob
> The passphrase is: "TestingPassphrase"
From what I have read of this thread, your emails are not valid OpenPGP/MIME
messages.
Have a read of RFC3156, it describes the OpenPGP/MIME message format.
Not many mail clients are OpenPGP/MIME aware, and Outlook definately isn't.
You could save yourself a lot of headache by just encrypting your file to
say Documents.tgz.pgp, and attaching this to an email. The end user would
have to save this attachment to disk, then decrypt manually. There is no
point making an OpenPGP/MIME message to an Outlook user as Outlook cannot
handle it, and the user would still have to save part of the message and
decypt manually.