Re: Protection mail at rest
On Tue, Jun 03, 2008 at 04:37:20PM -0400, Eric Cronin wrote: > > On Jun 3, 2008, at 11:51 AM, Adam Aviv wrote: > > >Depending on the level of protection you want, you could just add a > >script to your .forward to encrypt your email before delivery using > >PGP/GPG. However, this will leave the headers in the clear, so you > >will likely want to create an entirely new envelope for the message > >with the original message encrypted as the body or an attachment. > > Does anybody have a recipe for this first mode handy? plain text e- > mails seem simple enough, but there needs to be a bit of MIME > unwrapping and rewrapping to correctly handle attachments so that the > client sees/decrypts them correctly I think. I've searched from time > to time and never found a good HowTo... S/MIME supports enveloped MIME objects, if PGP does not work out for MIME entities, you could try that. S/MIME is natively supported in Thunderbird, Apple Mail, and similar MUAs. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Protection mail at rest
On Tue, Jun 3, 2008 at 4:37 PM, Eric Cronin <[EMAIL PROTECTED]> wrote: > > On Jun 3, 2008, at 11:51 AM, Adam Aviv wrote: > >> Depending on the level of protection you want, you could just add a >> script to your .forward to encrypt your email before delivery using >> PGP/GPG. However, this will leave the headers in the clear, so you >> will likely want to create an entirely new envelope for the message >> with the original message encrypted as the body or an attachment. > > Does anybody have a recipe for this first mode handy? plain text e-mails > seem simple enough, but there needs to be a bit of MIME unwrapping and > rewrapping to correctly handle attachments so that the client sees/decrypts > them correctly I think. I've searched from time to time and never found a > good HowTo... > > Thanks, > Eric > I have written a script that does that in python, as part of the email handling for the project. It encrypts each message part separately and then construct a new email with each encrypted part as the payload of a new MIME multipart message. Contained within is also the encrypted session key, and necessary info to reconstruct. On the client side, the message can then be unwrap, decrypted, and the original email reconstructed. Or the client can request just the headers, the body, or any attachment (becomes iffy with a combination of 'text/plain' and 'text/html' content type) instead of the entire message. Depending on how you want to do the wrapping (if you want to meet some optimization like headers can be requested before the rest of the message), then the simplest approach is, if a MIME multipart message, to work with each part individually and encrypt. I decided to encrypt the headers for each part separatly from the payload, so that the client can see what the message contains before actually decrypting it. But, different approaches can be taken depending on the end goal (i.e. just encrypt the whole thing into a glob, and download the glob and decrypt it on the client directly into a mbox or maildir that is locally served). adam -- Adam Aviv Ph. D. Candidate Computer and Information Science University of Pennsylvania - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Can we copy trust?
[Moderator's note: I'm letting just this one through, because I think Peter's point bears repeating. --Perry] "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: >IT departments put corporate trusted CA certificates in employees computers. >The US DoD puts their trusted root certificates in DoD computers. All these >actions copy trust with high fidelity. They don't copy any trust at all, they copy a (usually expensive) cryptographic cookie that turns off browser warning messages. (They do copy the cookies with high fidelity though, if one bit is corrupted then the cookie becomes invalid). Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Protection mail at rest
Victor Duchovni <[EMAIL PROTECTED]> writes: > On Tue, Jun 03, 2008 at 04:37:20PM -0400, Eric Cronin wrote: > >> >> On Jun 3, 2008, at 11:51 AM, Adam Aviv wrote: >> >> >Depending on the level of protection you want, you could just add a >> >script to your .forward to encrypt your email before delivery using >> >PGP/GPG. However, this will leave the headers in the clear, so you >> >will likely want to create an entirely new envelope for the message >> >with the original message encrypted as the body or an attachment. >> >> Does anybody have a recipe for this first mode handy? plain text e- >> mails seem simple enough, but there needs to be a bit of MIME >> unwrapping and rewrapping to correctly handle attachments so that the >> client sees/decrypts them correctly I think. I've searched from time >> to time and never found a good HowTo... > > S/MIME supports enveloped MIME objects, if PGP does not work out for MIME > entities, you could try that. S/MIME is natively supported in Thunderbird, > Apple Mail, and similar MUAs. Actually, PGP/MIME uses the same high-level mechanism to wrap MIME objects as S/MIME does: http://www.ietf.org/rfc/rfc1847.txt The PGP/MIME description is in: http://www.ietf.org/rfc/rfc3156.txt Specification wise both should work equally well, but implementation quality may differ. What is often overlooked is that the e-mail envelope (including the Subject: header field) is not protected or even encrypted under RFC 3156 unless you forward the entire e-mail as a message/rfc822 MIME part within the PGP/MIME (or S/MIME) message. Interoperability of that has historically been poor, but the more modern MUAs should handle it today. Writing a .forward proxy that wraps incoming e-mails into PGP/MIME encrypted message/rfc822 attachments should be simple, probably simpler than PGP/MIME wrapping all the individual MIME parts in the incoming e-mail. /Simon - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Code makers and breakers of WWII era
http://news.cnet.com/2300-1029_3-6240826-1.html?tag=ne.gall.pg -- Crypto ergo sum. https://www.subspacefield.org/~travis/ Truth does not fear scrutiny or competition, only lies do. If you are a spammer, please email [EMAIL PROTECTED] to get blacklisted. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
the joy of "enhanced" certs
As some of you know, one can now buy "Enhanced Security" certificates,
and Firefox and other browsers will show the URL box at the top with a
special distinctive color when such a cert is in use.
Many of us have long contended that such things are worthless and
prove only that you can pay more money, not that you're somehow more
trustworthy.
An object lesson in this just fell in my lap -- I just got my first
email from a spammer that links to a web site that uses such a cert,
certified by a CA I've never heard of ("Starfield Technologies, Inc.")
Doubtless they sell discount "Enhanced Security" certs so you don't
have to worry about paying more money either. I haven't checked the
website for drive by malware, but I wouldn't be shocked if it was
there.
I'm thinking of starting a CA that sells "super duper enhanced
security" certs, where we make the company being certified sign a
document in which they promise that they're absolutely trustworthy.
To be really sure, we'll make them fax said document in on genuine
company letterhead, since no one can forge letterhead.
Perry
--
Perry E. Metzger[EMAIL PROTECTED]
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: the joy of "enhanced" certs
On Wed, 4 Jun 2008, Perry E. Metzger wrote: I'm thinking of starting a CA that sells "super duper enhanced security" certs, where we make the company being certified sign a document in which they promise that they're absolutely trustworthy. To be really sure, we'll make them fax said document in on genuine company letterhead, since no one can forge letterhead. Sorry - not quite good enough. You lack that key thing to make this secure and win the war on them internet terrorists. You totally missed the fundamental crucial and the totally aspect of your Unique Selling Proposition: it _has_ to be very very very expensive. And people have to know that it was, indeed, very very expensive. Dw - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
