Re: [cryptography] Email encryption for the wider public

[Ryan Carboni]

The majority of people are no more capable of GnuPG than understanding why
RAM can't be solely used on a computer.

GnuPG has some weird defaults that are difficult to change as well without
some command line commands.

Ultimately your system will have a major flaw: passwords are typically have
low entropy, and anyone with the same password will read the same mail
unless you concatenate a salt the user has to remember.


The ideal system would be to use Tor in conjunction with guerrillamail. Or
to use a preshared key with a block cipher, and hide the encryption (since
evidently you want to avert the attention of the NSA to be encrypting in
the first place) using steganography.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Email encryption for the wider public

[Kevin]

On 9/17/2014 9:43 AM, Henry Augustus Chamberlain wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


17/09/2014

Hello.

I think I might have a way to make email encryption easily accessible 
to the general public, and would be very grateful if you could share 
any comments you might have.


I think the existing algorithms (RSA, Diffie-Hellman, Elliptic Curve 
equivalents) are perfectly sound, as are the software programs (GPG 
and email client plug-ins), but the user is still required to 
understand concepts like public/private keys and digital signatures. I 
think these conceptual difficulties are what are holding back a more 
widespread adoption of email encryption, and this is what I wish to 
solve. (See "Why Johnny Can't Encrypt".)


I propose that we use the local part of the email address to store the 
public key, so instead of henryaugustuschamberl...@gmail.com 
, my email address would be 
(64 random letters)@gmail.com . (This is by no means 
a new principle - Bitcoin does something similar, although it uses a 
hash of the public key rather than the key itself.) RSA keys are too 
long, but elliptic curve keys would work fine.


I think combining addresses and keys actually makes intuitive sense. 
When you send an email to a particular address, you expect it to be 
read by that person and no-one else. Likewise, when you receive an 
email from some particular address, you expect to have originated from 
that address and nowhere else. This is precisely what public-key 
encryption guarantees, by means of encryption in the former case and 
digital signatures in the latter case. Using keys as addresses would 
remove the need for the user to understand public keys, encryption and 
digital signatures: everything would "just work" automatically - 
without compromising security in any way.


Having long (and unmemorable) email addresses would certainly create 
some problems, although perhaps fewer than one might initially 
imagine. "Mailto" links on web pages would continue to work as they 
always have done, as would institutions' email directories and private 
individuals' address books. Exchanging email addresses in person might 
be problematic, but QR codes might be of use here: they can be 
displayed on a smartphone screen or printed on business cards. Passing 
email addresses over the telephone remains a problem (although in the 
case of mobile phones, a text message could be used instead).


Somebody not using encrypted emails could still click on your "mailto" 
link and send you an email, although it will be unencrypted (and they 
would probably ask you why your email address is such a strange one!). 
Perhaps some people might choose to add a footer to unencrypted emails 
- like Hotmail used to do - explaining that they use encryption, and 
encouraging others to do likewise.


The issue of private keys still remains, but perhaps they could take 
the place of passwords: when configuring a desktop (or mobile) email 
client, one would provide a private key file (or a QR code) instead of 
a password. SSH already allows users to login using public key 
certificates rather than passwords. Configuring a phone (or new PC) is 
only ever done once, so hopefully this small hurdle would not impose 
an undue burden on the user. Webmail would be tricky to use, since a 
user could hardly be expected to memorise a 64 character password, but 
one might question whether webmail can have any place at all in an 
end-to-end encryption system.


In summary, I believe my proposal would allow encrypted emails to very 
closely resemble the existing unencrypted system that users are 
accustomed to. As far as the user is concerned, encrypted emails work 
just like normal emails, except that the email addresses are longer, 
and their password is replaced with a QR code that needs to be printed 
off and stored somewhere safe. In return for this, their messages are 
guaranteed to be encrypted end-to-end and digitally signed, or from 
the user's point of view, emails would "just work" the way they 
should: "To Mr X" means that only Mr X can receive it, and "From Mr Y" 
means that only Mr Y could have sent it.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUGY8lAAoJEIvCuPSbZIqXRvQP/3L5igSHyhmEQ+SiHWPSxT0m
N/t3TTxxFxQ6hO/kwI3kasVOEQL7csSyRXCQP4nSM8OqLkj2HU8fCMt+ytVrSdqp
c/Y2WyQczlcy8nIKfOi3Ua6fxd/WpUFV4BtSLbJ+BV/XIuzH8lXYJIiV0DRbVOlo
3I16IIWNDWNRc8pDp0v7olwsbA2pROWJhOb1bJ2uyiyxIGhREEx0smKs2DNKtyCI
DUxNkpF6yxLRTBoH4UT2Q5Q/D8A2X0n+6EvcpBpkf/BKcoky9tRpnhJrzd59n8AY
Clr2+DRcZbJv3JC3eVSOdsLUKvadznvvLx3JlbQWTGlXOMuA6vGmOFkxHozqrZWU
RwotrmoC2YLj0yAnxxaaTlvcmkGRJU04p/8js5KuDNcPbhkLg0Ld3P+Cqo/x7+db
ntRGudUn3mSu44cxLNF/IPqqrr9Y6FZlFRvjddIQ/YXTQ46cQVQnawOk+twM8Uk/
lLnX0u17+jIjUmwSoRBCTZKMfSxDLY71yPrej86MVFrUKNq2qeAC83lmJBcHF6zb
4K3W5IoWhGkAuJHLkwlW9wlCin9tKLnoRXHN0CAaVFc63o5ZWxinJlf7J7ml1q90
zIZyyCaGWLVfUD7RD8nw9FEMUVwEW+4zm4A9mudegJdvKmt7nxmKG1

Re: [cryptography] Email encryption for the wider public

[Maarten Billemont]

On 17 September 2014 09:43, Henry Augustus Chamberlain <
henryaugustuschamberl...@gmail.com> wrote:

> Using keys as addresses would remove the need for the user to understand
> public keys, encryption and digital signatures: everything would "just
> work" automatically - without compromising security in any way.


I'm not sure I understand what problem you've just solved.  Senders still
need to generate a keypair and encrypt their mail, receivers still need to
decrypt their mail.  All you've done is remove key lookup and replaced it
with a From: header.


-- 
*Maarten Billemont* (lhunath)
me: http://www.lhunath.com – business: http://www.lyndir.com –
http://masterpasswordapp.com
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Email encryption for the wider public

[Henry Augustus Chamberlain]

I think maybe I didn't make the bit about private keys very clear:
we're talking about proper randomly-generated private keys, just in
PGP. I was just suggesting that since you have to walk around with a
private key file, at least it gives you an excuse to get rid of
passwords, and just authenticate with the server using the private
key.

On 17/09/2014, Ryan Carboni  wrote:
> The majority of people are no more capable of GnuPG than understanding why
> RAM can't be solely used on a computer.
>
> GnuPG has some weird defaults that are difficult to change as well without
> some command line commands.
>
> Ultimately your system will have a major flaw: passwords are typically have
> low entropy, and anyone with the same password will read the same mail
> unless you concatenate a salt the user has to remember.
>
>
> The ideal system would be to use Tor in conjunction with guerrillamail. Or
> to use a preshared key with a block cipher, and hide the encryption (since
> evidently you want to avert the attention of the NSA to be encrypting in
> the first place) using steganography.
>
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Email encryption for the wider public

[Henry Augustus Chamberlain]

On 17/09/2014, Kevin  wrote:
> As someone who deals with security measures each day I need to come at
> it from that angle.  Your method is great save for the fact that
> spammers love spoofed addresses.  I doubt anyone could trust something like
> abcdcdhhiklklklmn...@hotmail.com
> Am I missing something?  If I'm not, it seems more measures should be
> taken.  What about digital signatures?  Would you change the scheem?
>
>
> --
> Kevin
>
>

Well, each email is digitally signed using the sender's key (as well
as being encrypted using the recipient's key) so it's impossible to
spoof the address.

As for trust, I think the whole point of cryptography is that you
should trust the digital signature rather than just checking the
sender's address. With my scheme, the address and the public key are
the same thing, so if an email is forged then the software can say
"This email isn't really from that address" rather than "Error!
Invalid key".

I haven't changed anything in terms of the cryptography - I'm just
trying to make things more usable.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Email encryption for the wider public

[Henry Augustus Chamberlain]

On 17/09/2014, Maarten Billemont  wrote:
>
> I'm not sure I understand what problem you've just solved.  Senders still
> need to generate a keypair and encrypt their mail, receivers still need to
> decrypt their mail.  All you've done is remove key lookup and replaced it
> with a From: header.
>

I haven't invented any new cryptography - functionally, it's similar
to what already exists.
But I think the reason that encryption still isn't widely used (after
more than 2 decades!) is the usability. Even if encryption/decryption
are automated, you still need to understand concepts like public keys
and digital signatures in case something goes wrong.

By combining the address and the public key, I think everything makes
much more sense to the end user: when they send emails to some
address, they know it can't be intercepted, and when they receive an
email from some address, they know that it definitely came from there.

The encryption/decryption can be handled automatically by something
like Enigmail, but now the user can easily understand the problem if
something goes wrong: errors will say things like "this email didn't
really come from that address", rather than "this digital signature
doesn't match the key".
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Email encryption for the wider public

[grarpamp]

On Wed, Sep 17, 2014 at 9:43 AM, Henry Augustus Chamberlain
 wrote:
> I propose that we use the local part of the email address to store the public 
> key,
> ...
> my email address would be (64 random letters)@gmail.com
> ...
> Somebody not using encrypted emails could still click on your "mailto"
> link and send you an email, although it will be unencrypted

Putting keys into some_encod...@example.com might cover
some bases related to offline key lookup and message validation.
Most user and system mail tools would need changes to handle
string width and keytype, addressbooks updated, etc. Totally burying
OpenPGP, passphrase and key lookup/use behind a fully integrated
MUA GUI for grandma would work just as similarly well right now today
with no such encoding.

But in the end, all you're doing is covering the message body, and in today's
world that's clearly not enough. No one's yet solving the huge issues
with leaving mail exposed to what is essentially open-for-all-to-inspect central
storage and mail routing. The "who's IP talking to who", "From To Subject,
daemon headers, etc" metadata, when, how much/often, provider logs, someone
sending you unencrypted mail, you giving up your private keys to the
provider or running blobs they provide to you, etc. This is all unfixable with
traditional "Email" models.

This is why that to really solve anything more than the message body,
you need to go completely nextgen and turn that 'email address' into
an anonymous P2P overlay network node address, run your overlay
client [which supplies a mail/messaging front end] and send/receive
mail through that from/to your usual MTA/MUA/messaging toolchain.

The real work there is in pushing the P2P node count up...
- Research how many users globally might leave their messaging
node up 24x7 for a direct realtime overlay connection with the far
end "user@node"... 1/10/100/n*1000 million?
- Develop message storage [and forward/poll/expiry] within the
overlay for those that aren't in online mode.
- Determine any hardware limitations and thin client models.

There is an ongoing thread with the subject
 "The next gen P2P secure email solution"
that contains various people's initial thoughts/framework on this.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Email encryption for the wider public

[Henry Augustus Chamberlain]

On 17/09/2014, grarpamp  wrote:
> Putting keys into some_encod...@example.com might cover
> some bases related to offline key lookup and message validation.
> Most user and system mail tools would need changes to handle
> string width and keytype, addressbooks updated, etc. Totally burying
> OpenPGP, passphrase and key lookup/use behind a fully integrated
> MUA GUI for grandma would work just as similarly well right now today
> with no such encoding.
>
> But in the end, all you're doing is covering the message body, and in
> today's
> world that's clearly not enough. No one's yet solving the huge issues
> with leaving mail exposed to what is essentially open-for-all-to-inspect
> central
> storage and mail routing. The "who's IP talking to who", "From To Subject,
> daemon headers, etc" metadata, when, how much/often, provider logs, someone
> sending you unencrypted mail, you giving up your private keys to the
> provider or running blobs they provide to you, etc. This is all unfixable
> with
> traditional "Email" models.

I think the metadata issue is really interesting, and I'm interested
in what various schemes (P2P, Dark mail alliance, etc) are doing about
it. But I think you and I are talking about different problems: your
main concern (which is a valid one!) is that encrypted emails still
expose metadata, whereas my concern is the fact that hardly anybody is
currently able to use email encryption at all! I think both concerns
are fair, and both are worth trying to solve.

Henry
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Email encryption for the wider public

[stef]

On Thu, Sep 18, 2014 at 09:06:53AM +0200, Henry Augustus Chamberlain wrote:
> currently able to use email encryption at all! I think both concerns
> are fair, and both are worth trying to solve.

let me summarize (and ask you to reread and understand) grapamps response to
you: email is dead.

-- 
otr fp: https://www.ctrlc.hu/~stef/otr.txt
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Email encryption for the wider public

[Krisztián Pintér]

On Thu, Sep 18, 2014 at 10:57 AM, stef  wrote:
> let me summarize (and ask you to reread and understand) grapamps response to
> you: email is dead.

email is not dead, it is a zombie that walks around for at least 20
years. btw do you guys aware of IM2000? http://cr.yp.to/im2000.html
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Email encryption for the wider public

[stef]

On Thu, Sep 18, 2014 at 11:13:04AM +0200, Krisztián Pintér wrote:
> On Thu, Sep 18, 2014 at 10:57 AM, stef  wrote:
> > let me summarize (and ask you to reread and understand) grapamps response to
> > you: email is dead.
> 
> email is not dead, it is a zombie that walks around for at least 20
> years.

i like your analogy :)

is there a non-zero probability that zombie analogies are the opposite to car
analogies?

-- 
otr fp: https://www.ctrlc.hu/~stef/otr.txt
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Email encryption for the wider public

[Peter Gutmann]

stef  writes:

>let me summarize (and ask you to reread and understand) grapamps response to
>you: email is dead.

... he said, via email.

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Email encryption for the wider public

[Henry Augustus Chamberlain]

Hi all,

Some very interesting points so far. To avoid making this email too
long, I'm going to reply without quoting - I hope this doesn't
inconvenience anyone.

Regarding the memorability issue, all I can say is that end-to-end
encryption really does require sharing 100+ bit keys - it's essential!
You may be able to memorise your email address at the moment, but
that's only half the story, since you can't memorise your public key!
I can't solve every problem with PGP, but I still think this proposal
solves a fair few of them. In some cases it improves on PGP, and in
the other case it's at least no worse: you can still use online
institutional directories etc if you want.

Don't forget all the advantages this scheme could bring! Simplicity
and transparency for the end user is really important! They're more
likely to understand the significance of a public key if it forms part
of the address (despite not understanding why it has to be this way).

Perhaps it doesn't help Derek's mum - nor my mum, for that matter -
but there are plenty of people for whom PGP is to complex whereas this
scheme would be manageable. If you wish, you can send some emails
encrypted and others unencrypted, just like you can with PGP - in this
case, you'd just need two addresses (which is surely no worse than
PGP, where you have an address and a key).

Regarding telephone conversations: if it's with a mobile phone,
perhaps a text message would work; if it's a landline, you probably
have internet access, so an initial unencrypted email would work if
you're not worried about man-in-the-middle attacks. (If you are
worried about such attacks, then a bit of effort might be required,
beyond just rattling off a short email address over the phone.)

By the way, I'm suggesting printable characters to encode the key, not
arbitrary bytes. An alphanumeric character stores nearly 6 bits (or 5
if it isn't case-sensitive), so 256-bit keys would require around 50
characters. Email standards allow 64 characters for the local part of
the address, so there's room for error-correction too.

Regarding the point about forged email addresses: for cryptography to
work, you need to identify people using their keys, not their
addresses. With PGP, you could send an email to my mum, using my email
address but the wrong signature; if my mum is just relying on the
email address, then that defeats the purpose of PGP. Of course, most
PGP systems compare the key with that stored in the address book; a
similar system can be used for my proposal, but with the advantage
that forged emails don't give rise to the situation where the address
is known but the key is unknown, which might lead a naive user to
assume something's broken with the crypto software.

Regarding webmail... I still haven't solved that one. Maybe there's an
inherent contradiction in trying to include webmail in an end-to-end
encryption system.

I like the idea of using the "address+...@gmail.com" technique,
although it does contradict the idea of "identify people using the
key, not the address". Also, in my original proposal, I suggested
using the private key (instead of a password) to login to the email
server. I reckon Gmail is unlikely to allow that in the near future :)

Best wishes,

Henry
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Email encryption for the wider public

[Givon Zirkind]

this is an interesting point.  since google scrougles your emails and 
their aup says you agree to let them, by machine, sift through your 
data, to target you for marketing--Google Analytic's targeted ads--how 
receptive would Google or any freemail provider be, to an innate 
encryption scheme.  if i were a lawyer for Google, I could even argue 
that such a user has violated Google's AUP and the account can be shut down.


On 9/19/2014 5:33 AM, Henry Augustus Chamberlain wrote:

Hi all,

Some very interesting points so far. To avoid making this email too
long, I'm going to reply without quoting - I hope this doesn't
inconvenience anyone.

Regarding the memorability issue, all I can say is that end-to-end
encryption really does require sharing 100+ bit keys - it's essential!
You may be able to memorise your email address at the moment, but
that's only half the story, since you can't memorise your public key!
I can't solve every problem with PGP, but I still think this proposal
solves a fair few of them. In some cases it improves on PGP, and in
the other case it's at least no worse: you can still use online
institutional directories etc if you want.

Don't forget all the advantages this scheme could bring! Simplicity
and transparency for the end user is really important! They're more
likely to understand the significance of a public key if it forms part
of the address (despite not understanding why it has to be this way).

Perhaps it doesn't help Derek's mum - nor my mum, for that matter -
but there are plenty of people for whom PGP is to complex whereas this
scheme would be manageable. If you wish, you can send some emails
encrypted and others unencrypted, just like you can with PGP - in this
case, you'd just need two addresses (which is surely no worse than
PGP, where you have an address and a key).

Regarding telephone conversations: if it's with a mobile phone,
perhaps a text message would work; if it's a landline, you probably
have internet access, so an initial unencrypted email would work if
you're not worried about man-in-the-middle attacks. (If you are
worried about such attacks, then a bit of effort might be required,
beyond just rattling off a short email address over the phone.)

By the way, I'm suggesting printable characters to encode the key, not
arbitrary bytes. An alphanumeric character stores nearly 6 bits (or 5
if it isn't case-sensitive), so 256-bit keys would require around 50
characters. Email standards allow 64 characters for the local part of
the address, so there's room for error-correction too.

Regarding the point about forged email addresses: for cryptography to
work, you need to identify people using their keys, not their
addresses. With PGP, you could send an email to my mum, using my email
address but the wrong signature; if my mum is just relying on the
email address, then that defeats the purpose of PGP. Of course, most
PGP systems compare the key with that stored in the address book; a
similar system can be used for my proposal, but with the advantage
that forged emails don't give rise to the situation where the address
is known but the key is unknown, which might lead a naive user to
assume something's broken with the crypto software.

Regarding webmail... I still haven't solved that one. Maybe there's an
inherent contradiction in trying to include webmail in an end-to-end
encryption system.

I like the idea of using the "address+...@gmail.com" technique,
although it does contradict the idea of "identify people using the
key, not the address". Also, in my original proposal, I suggested
using the private key (instead of a password) to login to the email
server. I reckon Gmail is unlikely to allow that in the near future :)

Best wishes,

Henry
___
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