BBCR4 on Crypto-wars today at 13:30

[Mark Lomas]

If you are willing to use distributed key servers you might build on an
observation by Gus Simmons.

The RSA scheme usually generates a pair of keys, (d,n) and (e,n), where p
and q are two large primes, n=p.q, and d.e is congruent to (p-1).(q-1).
Encrypt by computing c = (m**e) mod n; decrypt by computing m = (c**d) mod
n. Message padding is needed to guard again certain attacks, but is
irrelevant to this example.

Simmons observed that you can construct three or more keys the same way:
(d,n), (e,n), (f,n) where d.e.f is congruent to (p-1)(q-1).

I can give a server (f,n), declare (e,n) to be my public key, and retain
(d,n) for myself. Together (d,n) and (f,n) comprise my private key. Encrypt
as normal c = (m**e) mod n; decrypt by computing m = (((c**f) mod n) ** d)
mod n. The server participates in decryption but can't complete the
decryption operation. I can add further servers in a similar manner.

What I like about Simmons's scheme is that (e,n) is a normal RSA key so I
may publish an S/MIME certificate for it. People who wish to send me
encrypted messages don't need special software; they don't even need to be
aware that my decryption is unusual.

Mark




On 23 March 2014 19:59, Peter Fairbrother <zenadsl6186 at zen.co.uk> wrote:

> On 21/03/14 07:10, Caspar Bowden (lists) wrote:
>
>> On 03/20/14 22:46, Peter Fairbrother wrote:
>>
> [...]
>
>
>  But FISA 702 in particular can force arbitrary service provider
>> "co-operation" (as per Hushmail case, but that was actually Canada -
>> anyone get to the bottom of that?)
>>
>> So anything you depend on the email service provider to do for your
>> confidentiality can be subverted by law
>>
>
>
> Yes, that can be a problem.
>
> A suggestion, a distributed key service.
>
> Each keyserver accepts keys from (and generated by) users, sends them a
> confirm message to the email address attached to the key, then on receipt
> of the (signed) confirm reply adds the key to the shared list.
>
> Each shared list entry consists of: email address, server, date added,
> key. The list is hashed and updated between servers a bit like the bitcoin
> list (which might also pay for the key servers, eg the right to send spam).
>
> When a user wants to send an email he contacts his list server, the
> recipient's list server, and another list server chosen at random and asks
> each for the key. The recipient's key server also replies with a
> signed-by-the-recipient ephemeral key as well as the recipient's key.
>
> If there is only one key for the email address, and the three responses
> match, and the sender's own copy of the recipient's key (if he has one) all
> match, then he uses the signed and dated ephemeral key provided by the
> recipients key server.
>
> The replies from the servers are all signed, so if they don't match we
> want to know why - the replies can then be published, so if a server cheats
> then it can be found out and shamed.
>
> There is a little more, eg when there is no key or more than one key
> attached to a single email address, but that's basically how to find a new
> correspondent's key from his email address.
>
> Note that the key servers are separate from the email servers which just
> work in the normal way.
>
>
>
> *_You'll have to write some decent email and webmail clients_*  but after
> that in most cases it can be almost entirely transparent to the user - in
> that respect the gpg etc clients/addons/etc, not to put too fine a point on
> it, suck.
>
> I think most of the people who write secure email software don't spend
> nearly enough time and effort writing good clients, and good clients are
> essential if their solution is to be used.
>
>
>
>>  eg, what happens if someone sends you an unencrypted email on your
>>> encrypted service?
>>>
>>
>> Would be nice to have an autoresponder which bounced mail without right
>> GPG header?
>>
>
> I don't know. That's the "security" answer, but it isn't necessarily
> correct - I don't know whether there is a single correct answer.
>
> The idea is to get people to use it, and use it in a secure manner. If eg
> secure m-messages are presented onscreen in red in one window, and insecure
> messages are in black in a differently-designed window, and the user both
> knows this and uses it correctly - then there is no need for an
> autoresponder-rejecter.
>
> Also, does it have to be secure all the time? If the idea is to have a
> generally secure encrypted email service on which you can send highly
> secure emails, the rest of the mails don't have to be super-secure against
> eg malware or phishing - especially if the supersecure and normally-secure
> versions look the same to an attacker. There is room there for some
> unencrypted emails too.
>
> But I can also think of situations where an autoresponder-rejecter is the
> correct solution.
>
>
> -- Peter
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.chiark.greenend.org.uk/pipermail/ukcrypto/attachments/20140324/70368253/attachment.html>