Re: BETA solution, Re: Failure of PKI in messaging

On Thu, Feb 15, 2007 at 02:47:05PM -0800, Ed Gerck wrote:

> Zmail actually reduces the amount of trust by not
storing your usercode,
> password, or keys anywhere. This makes sense for zmail,
and is an incentive
> to actually do it, to reduce risk -- anyone breaking
into any zmail server,
> even physically, will not find any key or credential
material for any user
> and, hence, cannot decrypt any user area (the user area
keeps the address book
> and contact keys, all encrypted using the user keys
that are not there), or
> user messages collected from ISPs.

Where are the usercode, password and keys stored then?

[...]
> This will actually be available in v3.x, with an option
for client-based
> super-encryption. If you are concerned about zmail
peeking into the raw
> message, which zmail does not do, you can simply agree
with your message
> partner on an out-of-band passphrase and use it in your
client (without
> zmail access) to encrypt. Your recipient can do the
same to decrypt. What
> you get from zmail is the secure routing and
distribution -- for example,
> you can require the recipient to login, allow the
recipient to prevent
> phishing, and expire the message in 7 days. You can
also request a return
> receipt telling you when, where, how, and by whom the
message was decrypted.

/If/ I trust ZMail (the people behind it and the X.509 stuff
that
secures the website) then yes, this is functionality not
offered by SMTP
and PGP or S/MIME. But I don't see this replacing PGP or
S/MIME. I also
still don't see how this improves the trust model.

-- 
Met vriendelijke groet / with kind regards,
    Guus Sliepen <guussliepen.eu.org>

Guus Sliepen wrote:
> On Thu, Feb 15, 2007 at 02:47:05PM -0800, Ed Gerck
wrote:
> 
>> Zmail actually reduces the amount of trust by not
storing your usercode,
>> password, or keys anywhere. This makes sense for
zmail, and is an incentive
>> to actually do it, to reduce risk -- anyone
breaking into any zmail server,
>> even physically, will not find any key or
credential material for any user
>> and, hence, cannot decrypt any user area (the user
area keeps the address book
>> and contact keys, all encrypted using the user keys
that are not there), or
>> user messages collected from ISPs.
> 
> Where are the usercode, password and keys stored then?

N O W H E R E, as it says above.

> [...]
>> This will actually be available in v3.x, with an
option for client-based
>> super-encryption. If you are concerned about zmail
peeking into the raw
>> message, which zmail does not do, you can simply
agree with your message
>> partner on an out-of-band passphrase and use it in
your client (without
>> zmail access) to encrypt. Your recipient can do the
same to decrypt. What
>> you get from zmail is the secure routing and
distribution -- for example,
>> you can require the recipient to login, allow the
recipient to prevent
>> phishing, and expire the message in 7 days. You can
also request a return
>> receipt telling you when, where, how, and by whom
the message was decrypted.
> 
> /If/ I trust ZMail (the people behind it and the X.509
stuff that
> secures the website) then yes, this is functionality
not offered by SMTP
> and PGP or S/MIME. But I don't see this replacing PGP
or S/MIME. 

There's no need to replace PGP or S/MIME. After all, less
than 5% of all email
is encrypted using them. What's needed is to offer an option
for the other
95% that could be encrypted and authenticated.

>I also
> still don't see how this improves the trust model.

Because you have to trust zmail less (the two quotes above),
and also because
you have to trust the recipient less (the return receipt,
for example). In
addition, you have to trust your platform less (no
private-key that is stored
in your computer; ZSentryID can be used to render
key-logging ineffective).
In short, the less you have trust everyone (including your
own computer),
the better the trust model is -- what you trust is what can
break your
security, when it fails.

Best,
Ed Gerck

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com