Protection mail at rest
At one time, mail delivery was done to the end-user's system, and all mail was stored there. These days, most people find it convenient to leave their mail on a IMAP server: It can be accessed from anywhere, it can be on a system kept under controlled conditions (unlike a laptop), and so on. In fact, most people these days - even the technically savvy - not only leave their mail on an IMAP server, but let some provider deal with the headaches of maintaining that server. So, most people's mail spends most of its life sitting on a disk owned, managed, and controlled by some third party, whose responsibilities, not to mention abilities, for keeping that stuff secure are unclear to say the least. On top of that, the legal protections for data held by a third party are limited. We have mechanisms for providing end-to-end encryption of messages. Messages sent using, say, S/MIME are encrypted on the IMAP server just as they are out on the net. But this only helps for mail exchanged between correspondents who both choose to use it. Suppose I ask for a simpler thing: That my mail, as stored in my IMAP server, spends most of its life encrypted, inaccessible even to whoever has access to the physical media on which the server stores its mail. Now, this is a funny goal. If mail arrives unencrypted, anyone with access to the data stream can copy it and do what they like. It will inevitably be buffered, even likely stored on a disk, in the raw, unencrypted form. We explicitly leave dealing with this out of the equation - only end-to-end encryption can deal with it. Here are two ways of implementation something in this direction: 1. Client only. The client, whenever it sees a new message, (a) downloads it; (b) encrypts it using a secret key; (c) stores the encrypted version back on the server; (d) deletes the unencrypted version. The client can put the encrypted messages in a different folder, or it can mark them with a header line. 2. Server-assisted. The client gives the server its public key. When a message arrives at the server, the server (a) generates a session key; (b) encrypts the message using the session key; (c) encrypts the session key with the client's public key; (d) adds a header containing the encrypted session key to the encrypted message; (e) stores the encrypted message. The necessary work for the client is obvious. In each case, one would probably chose some headers to encrypt separately - e.g., the subject - so that one could more easily pull them out without decrypting the whole message. Obviously, approach 2 greatly decreases the time that messages may hang around unencrypted; but approach 1 can be implemented without any cooperation from the IMAP provider, which allows it to be rolled out even for those who use the large providers without having Google and Hotmail and Yahoo! buy into it. Does anyone know of existing work in this area? -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RIM to give in to GAK in India
So, what is it on the device that is using the 3DES key to encrypt chunks to send to the RIM messaging gateway? Something on the device has to encrypt/decrypt the data sent to/from the messaging server? Doesn't that constitute a session even if the 3DES keys are rotated frequently? (And, if they are, how are the 3DES keys agreed upon? Doesn't that imply public/private key-pairs or a master-key?) Arshad Noor StrongAuth, Inc. - Original Message - From: Victor Duchovni [EMAIL PROTECTED] Cc: cryptography@metzdowd.com Sent: Friday, May 30, 2008 10:41:10 AM (GMT-0800) America/Los_Angeles Subject: Re: RIM to give in to GAK in India On Thu, May 29, 2008 at 10:05:17AM -0400, Derek Atkins wrote: Arshad Noor [EMAIL PROTECTED] writes: Even if RIM does not have the device keys, in order to share encrypted data with applications on the RIM server, the device must share a session key with the server; must it not?. Isn't RIM (their software, actually) now in a position to decrypt content sent between Blackberry users? Or, does the Blackberry encryption protocol work like S/MIME? The enterprise solution does work something like S/MIME. The keys are symmetric 3DES, and encrypt message chunks (IIRC either 256 or 1K bytes) sent asynchronously to the enterprise messaging gateway. RIM does not have a secure session with the device. This is not like S/MIME except that as with S/MIME, this is not hop-by-hop encryption. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RIM to give in to GAK in India
On Fri, May 30, 2008 at 02:58:15PM -0400, Arshad Noor wrote: So, what is it on the device that is using the 3DES key to encrypt chunks to send to the RIM messaging gateway? Not to the RIM gateway, via the RIM gateway the payload is destined for a corporate messaging server. Something on the device has to encrypt/decrypt the data sent to/from the messaging server? Doesn't that constitute a session even if the 3DES keys are rotated frequently? (And, if they are, how are the 3DES keys agreed upon? Doesn't that imply public/private key-pairs or a master-key?) Presumably the device has a KEK, and generates a session key for each message, encrypting that under the KEK. The KEK is used for a long time (~90 days) and periodically renegotiated. I don't recall how the KEK is agreed to. Perhaps there is PKI involved in that step, or it could just negotiate the new KEK using the current KEK. There is not in practice any need for a PKI in this context, it looks rather a lot more like Kerberos than PKI. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unpatented PAKE!
[Moderator's note: Please do not top post. --Perry] Here's another approach to password authenticated key exchange with similar security claims. The underlying mechanism is under consideration for inclusion in by the 802.11s group in IEEE: http://www.ietf.org/internet-drafts/draft-harkins-emu-eap-pwd-01.txt -Original Message- From: Perry E. Metzger [EMAIL PROTECTED] Sent: May 30, 2008 2:27 PM To: Ben Laurie [EMAIL PROTECTED] Cc: Cryptography cryptography@metzdowd.com Subject: Re: Unpatented PAKE! Ben Laurie [EMAIL PROTECTED] writes: http://grouper.ieee.org/groups/1363/passwdPK/submissions/hao-ryan-2008.pdf At last. See also: http://www.lightbluetouchpaper.org/2008/05/29/j-pake/ Looks quite interesting indeed. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The perils of security tools
On Sun, May 18, 2008 at 4:55 PM, Hal Finney [EMAIL PROTECTED] wrote:
A simple trick can be used to help immunize DSA signatures against
these kinds of failures. I first learned of this idea many years ago
from Phil Zimmermann, and a varient has been used for a long time in
PGP and probably other code, but aparently not OpenSSL. The idea is
to base the random k not just on the output of your RNG, but also on
the private key x. Something like:
k = hash (x, rng()).
Of course it is still necessary that k be uniformly distributed mod q
(the DSA subgroup prime order), so this can't be just a straight hash.
It might be a separate PRNG instance which gets seeded with the data
values shown. But the idea is to mix in the secret key value, x, in
addition to data from the RNG.
I've used this idea before, although in the form of using the private
key as part of the PRNG seed -- which isn't of much use if the PRNG
ignores its seeding as in this case. However, even the form
k = hash (x, rng())
isn't good enough if the PRNG is sufficiently broken. The Debian code
generated an output that was not merely predictable, but also prone to
repetition if you run a binary multiple times. With typically just
2^15 different byte streams from the PRNG, by the birthday paradox
you'd have to expect to have been reusing some k after around 2^8
iterations or so. So your DSA key would still be at risk!
While mixing in more entropy is a good idea in general, I'd like to
caution against just throwing things in without knowing the full design
end-to-end. For example, if the environment is an embedded device and
hash() introduces visible power or timing side channels, you may not
want to do this exact construction. Most of the time it is fine, though.
DSA is especially vulnerable to all kinds of subtleties with k. As you
point out, it is fatal to replay k for a given private key x. But even
worse, it is fatal if some small number of bits of k are *predictable*.
This means even if the output wasn't completely predictable, but had
merely become somewhat predictable, it would still be exploitable.
http://crypto.stanford.edu/~dabo/abstracts/dhmsb.html
http://cat.inist.fr/?aModele=afficheNcpsidt=13872268
Mark Marson at Cryptography Research has done some great work
implementing these attacks. They're quite practical. I hope he'll give
a public talk about it some day.
You could also make k message-dependant -- i.e., feed both x and k
into the hash function:
k = hash (x, rng(), m)
This avoids that problem, and is likely to remain unbreakable even if
rng() returns just some constant. However, then you lose one
advantage of DSA, namely being able to do most of the computation in
advance, before you've even seen the message to be signed: If you've
obtained k and done the DSA exponentiation beforehand, you can create
signatures almost instantaneously; but this won't work if k depends on
the message.
This assumes the message always changes. Isn't this just getting back
to padding schemes, where you build something like PSS under your DSA to
protect against signing identical messages?
Since it appears some OpenSSL people are on this list, I'd like to ask
for more openness in the PRNG design and seeding. The current code is
crufty and arbitrary. Some minor but careful additions could have
helped reveal this bug earlier.
The code should generate warnings in the case of PURIFY being defined.
A comment should explain the security relevance of the seeding. For
example:
#ifndef PURIFY
/* SECURITY: add entropy to our pool. This is essential. (more) */
seed_PRNG(buf);
#else
#warning PRNG seeding disabled for Purify, do NOT use PRNG output!
printf(WARNING: PRNG seeding disabled for Purify, do NOT use PRNG
output!\n);
#endif
Also, there should be a TEST_MODE_INSECURE flag that outputs a debug
print of each time the PRNG is seeded and the data itself. This should
be run on a regular basis as part of automated tests. For example:
init()
{
#ifdef TEST_MODE_INSECURE
#warning PRNG seeding debug prints enabled, do NOT use PRNG output!
printf(WARNING: PRNG seeding debug prints enabled, do NOT use PRNG
output!\n);
#endif
}
seed_PRNG(src_name, buf)
{
#ifdef TEST_MODE_INSECURE
printf(PRNG seeding from %s: %s\n, src_name, hex_dump(buf));
#endif
... do seeding ...
}
Anyway, I hope this incident helps us all add more openness and paranoia
to our designs.
--
Nate
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
