Yeah. It's also worth pointing out that it is more or less impractical
to secure email. The result is paper-success-reality-fail. This has
been an observation for a long time. For recent evidence see Silent
Circle's decision to drop their secured email offering. I would say it
is mostly because they knew that it is practically impossible and a
WOFTAM to try to secure email.
The better direction is this: stop using email, use something like a
secured chat system, which can be secured, because we can avoid email's
terrible assumptions and context.
iang
On 15/08/13 14:11 PM, wasa bee wrote:
To: and From: headers leak the emails/identity of communicating parties,
but it's not the only place that happens. I've never used PGP but I've
used SMIME, so I'll refer to SMIME here (that may also apply to PGP
anyway). In SMIME, the keyWrap (which contains the AES key encrypted
under each recipient's public key) has some sort of headers that the
recipient parses. The header contains info about the intended
recipients' certs, like issuer, SN and email. sometimes it even contains
the entire recipient's cert (if memory serves). So one has to be careful
of what info is contained in the keywrap structure. If the email is
present, it will leak even if To/From were protected somehow. Even if
the email is not present, maybe the cert info provided for the
decryption of the keyWrap still leaks enough info about recipients...
for e.g. it might be enough to identify people by their cert rather than
by their email.
Another example where all this matters is in BCC headers. In Firefox
(last time i checked was 2 years ago i believe), Firefox would send the
same message to both To,CC and BCC recipients. The BCC header of course
is not present in the message so recipients don't have access to it.
However, going thru the keyWrap structure leaks the fact that the
message has also been encrypted for an extra recipient so it breaks the
BCC purpose.
It seems to me that as long as a long-term info is transmitted in each
message, it can be used for tracking who's talking to whom. Or one needs
to build some sort of deniability into the crypto scheme.
On Tue, Aug 13, 2013 at 7:53 PM, ianG <i...@iang.org
<mailto:i...@iang.org>> wrote:
On 13/08/13 20:16 PM, Peter Saint-Andre wrote:
On 8/13/13 11:02 AM, ianG wrote:
Super! I think a commercial operator is an essential step
forward.
How so? Centralization via commercial operators doesn't seem to have
helped in the email space lately.
Centralisation works when the server doesn't have any information of
value. Presumably the most that LeastAuthority.com can say is that
a certain company has X GB of documents and updates that set at rate
Y. Not a lot of value there...
The reason email space providers are suffering is that even when the
content is encrypted, the To: and From are not. This enables a
fairly dramatic capability -- seeing who's writing to whom. In
contrast to the bland GB number, this would provide all a business's
customers, all a dissident's contacts, all an insniding trader's
leakees, etc etc...
iang
_________________________________________________
cryptography mailing list
cryptography@randombit.net <mailto:cryptography@randombit.net>
http://lists.randombit.net/__mailman/listinfo/cryptography
<http://lists.randombit.net/mailman/listinfo/cryptography>
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
