[Cryptography] Asynchronous forward secrecy encryption

[Felix Ruzzoli]

Hi Michael,
I am not sure if you consider mobile clients, and I am speaking primarily
about smartphones and tablets, with a fragile network connection
to be part of DTN (Delay-tolerant Network?). But I believe the connection
issues in that case can be overcome by good coding practices;
at least in most instances.

About number 6 - Key Exhaustion attacks:
Well those can only occur if the receiver is offline. While online, the
server would alert a client whose key pool is near extinction. One simple
method to lower the attack surface, which is also currently implemented
in my system, is to only allow message sending between known (and trusted)
contacts. This way an adversary would have to gain control over the 
device of
a trusted contact before being able to launch a key exhaustion attack.

Actually I wouldn't know how to do better than this. This disables key
exhaustion for anyone but a trusted communication partner. Obviously
it is impossible to detect an attack without introducing artificial 
thresholds
at this point.

Any thoughts?

Regards,
felix

Am 05.11.2013 14:26, schrieb Michael Rogers:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Felix,
>
> It seems to me that your suggestion works, given some assumptions:
>
> 1. Long-lived process on the receiving client
> 2. Long-lived process on the server
> 3. Receiving client can contact server regularly to upload keys
> 4. Sending client can contact server before sending to receive a key
> 5. Receiving client can contact sender if message can't be decrypted
> (presumably this response isn't encrypted, to avoid infinite regress)
> 6. Some kind of protection against key exhaustion attacks
>
> Those seem like reasonable assumptions on the internet, but perhaps
> not for other settings like mesh networks or DTNs.
>
> Any thoughts about how to achieve number 6?
>
> Cheers,
> Michael
>
> On 29/10/13 17:49, Felix Ruzzoli wrote:
>> I believe that the memory on current smartphones running android
>> is stable enough for the purpose.
>>
>> I have a setup where the server stores some pre-generated DH keys
>> in memory only. Clients would query for a key for every message
>> they want to send in order to complete the DH agreement and send
>> the encrypted message plus the public key needed for the other
>> party's part of the protocol.
>>
>> So obviously there is a small gap. If the process has been killed
>> in between, the private key for decrypting that last message is
>> lost. The best we can do in that case is to tell the other party
>> that we could not decrypt that last message and they'd have to
>> resend with a fresh key we just sent along.
>>
>> Apart from the problem stated in the last paragraph, that would
>> enable PFS with asynchronous messages with a relatively simple
>> protocol. Or am I missing something here?
>>
>> Regards, felix
>>
>> _______________________________________________ The cryptography
>> mailing list cryptography at metzdowd.com
>> http://www.metzdowd.com/mailman/listinfo/cryptography
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEcBAEBAgAGBQJSePICAAoJEBEET9GfxSfMokUH/38jhnGnZJ74Kw6f3mX8B6uP
> M7Je+Ai3CdqQ1Y4bxIaAQVUEdT1sXbb1WpHAsmuZxEVsbmykRdS7T9rsSOSVw0Ol
> loAECrVo3UkRzTrWqcD0G7FXhDFXb/FjtE/m9Wf3BodL2lY8Zx+bjo/8LgHB7o2a
> 8N5NBuVKPgICYy85EsOtyVr8hsYytTETIdTgcQ8nQyS2EZJx4JRxjv73PUSPL/uw
> G0+aLACN+TgYBxoFjU/PVsLO3xqR/jA2IP5UTtS0yj5f99jUiBaGjFDeIoJdJprL
> dVzq/pXaSjGGqXNW24ZqYva/lQUymB5Pt54zhiiEC0ZUNvgj3AxoeXGEIj7vNQ8=
> =3QsG
> -----END PGP SIGNATURE-----