Re: Encrypted email

[Jesse Thompson <jesse.thompson () DOIT WISC EDU>]

Mike Wiseman wrote:
> > Perhaps a better place to start would be to define what the goals are.
> >
> > Clientless encryption is impossible if the goal is end-user to end-user
> > encryption.  Even Hushmail fell into this trap when they offered a
> > clientless way for users to access their mail.  They didn't make it
> > clear to users that any time the server is involved with the decryption
> > process, it means that your mail can be decrypted if there is a
> > subpoena
> > or a server is compromised.
>
> These issues apply to *any* enterprise encryption technology since keys
> would need to be backed up or escrowed.

Well, yeah.  That's why it's important to preface these discussions with
a definition of *who* you are protecting the content from.

End-to-end encryption without key escrow is the most secure, but has
usability drawbacks.

Key escrow done by a trusted 3rd party allows authorized parties to
access the content.

Key escrow/backup done on the same server that does the decryption makes
you vulnerable to abuse or compromise.

Client-less encryption (where the server is able to see the keys) makes
you vulnerable to abuse or compromise.  3rd party escrow in this case
doesn't add much additional security.


> > However, I wouldn't necessarily call it
> > encryption.
>
> Not sure what you're referring to - the Voltage product is based on
> identity-based encryption which is based on elliptic curve cryptography. No
> technology concerns there. Password strength is a concern but this can be
> dealt with via policy or the use of multi-factor authentication.

I was merely referring to the idea of "weakest link in the chain" or
"Achilles heal".  Just because part of your "encryption process" uses
strong encryption doesn't make the data completely secure.  Again, it's
important to preface these discussions with a definition of *who* you
are protecting the content from.

I have nothing against Voltage or systems like it.  I think that our
campus would benefit from this type of service.

Jesse


> Mike
>
>
>
> Mike Wiseman
> Computing and Networking Services
> University of Toronto

--
  Jesse Thompson
  Email/IM: jesse.thompson () doit wisc edu

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature