Re: [cryptography] Asynchronous forward secrecy encryption

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30/09/13 23:40, Trevor Perrin wrote:
 It'd be nice if Alice and Carol could use some additional,
 out-of-band channel to authenticate the ephemeral DH exchange.

To fill in some background: the use case for this feature is
introducing two people who aren't face-to-face right now and don't
share an authenticated channel, but who each share a confidential and
authenticated channel with a third party.

Users aren't assumed to know which channels are confidential or
authenticated, so we shouldn't create any opportunities for mistakes
in that regard. I think that rules out PAKE.

 Best I can think of are short auth strings (SAS), public-key 
 fingerprints (if you added long-term identity keys), and PAKE.
 
 The tradeoffs are something like: * Key fingerprints and SAS are
 non-secret (unlike PAKE passwords) * SAS and PAKE can use short
 strings of several chars (unlike fingerprints) * Fingerprints can
 be exchanged before *or* after the ephemeral DH handshake (unlike
 PAKE passwords or SAS) * Fingerprints can be confirmed with 3rd
 parties or public records (unlike PAKE passwords or SAS) *
 Fingerprints and PAKE can be compatible with a single, unordered 
 handshake exchange of ephemeral DH values, unlike SAS

Thanks, this is a really useful comparison.

Perhaps we can combine some of the advantages of fingerprints and SAS:

* The introducees exchange single-use public keys, signed with their
long-term private keys, via the introducer
* The introducees derive a shared secret, destroy their single-use
private keys, and start key rotation
* The introducees exchange acks via the introducer
* The introducees can optionally obtain each other's long-term public
keys from other third parties, before or after the introduction
* If the introducees meet face-to-face, they can confirm each other's
long-term public keys using SAS:
  - The users verbally exchange short codes to enable their devices to
find each other over a short-range transport such as wifi
  - The devices exchange hash commitments and ephemeral public keys
  - The users verbally exchange short authentication strings
  - If the strings match, the devices derive symmetric encryption and
authentication keys from the ephemeral shared secret
  - Within the ephemeral secure channel, the devices exchange
long-term public keys and a value derived from the current temporary
secret, signed with their long-term private keys, as verification that
they own those keys and have the same shared secret
* Nobody signs anything that proves who their contacts are

Any thoughts on cryptographic or usability aspects?

Cheers,
Michael

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

iQEcBAEBAgAGBQJSTYr1AAoJEBEET9GfxSfMYx8H/0RxYl3gEqu7KUz/D5053o2T
2cZIUopdSiZs6SYH2gnTzrGPXAyd3xvGMmTFKV40EAWdix1+ZHpg6fs1i7wWZ6Q9
NbUNX5C1L8hbmMI4aK0ebq69J54N/iZqiQte/utQ3fwjq28U0xARuwq5VqPuJRlS
2TGt5tZG9tN5vAtb3R8I94OGwpF1PwFYEpUlyhG7LRRSoQBV5Xw5QwDaf7VKkeBM
UoZ6JlAjI0wl17U01E6dYHmZpcq10EZ+BTomD+Kw1lioPGj15S97a4odOo0y2gd+
0uW+yXoVRhRO4Hq2f9HPfMhoNE34eXt9ube1a6PrOmXMT2Dan/g10cVSOowZRMw=
=O6PJ
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Asynchronous forward secrecy encryption

[Trevor Perrin]

On Thu, Oct 3, 2013 at 8:19 AM, Michael Rogers mich...@briarproject.orgwrote:


 Perhaps we can combine some of the advantages of fingerprints and SAS:


Sure, and I should point out that fingerprints, SAS, and PAKE could all be
done in parallel.  For example, OTR offers all three (session IDs = SAS;
Socialist Millionaire's Protocol = PAKE).



 * The introducees exchange single-use public keys, signed with their
 long-term private keys, via the introducer
 * The introducees derive a shared secret, destroy their single-use
 private keys, and start key rotation


Having each party sign an ephemeral public key with a long-term signing key
is not, by itself, a good key agreement protocol, due to:

 * The identity misbinding possibility of an an attacker signing a
victim's ephemeral key, tricking others into thinking the victim's
communications originated from the attacker.

 * The lack of freshness on the authentication - if an attacker compromises
one ephemeral private key, it can be reused without needing additional
signatures.

Earlier I was suggesting triple Diffie-Hellman as a better option.



 * The introducees exchange acks via the introducer
 * The introducees can optionally obtain each other's long-term public
 keys from other third parties, before or after the introduction
 * If the introducees meet face-to-face, they can confirm each other's
 long-term public keys using SAS:
   - The users verbally exchange short codes to enable their devices to
 find each other over a short-range transport such as wifi
   - The devices exchange hash commitments and ephemeral public keys
   - The users verbally exchange short authentication strings
   - If the strings match, the devices derive symmetric encryption and
 authentication keys from the ephemeral shared secret
   - Within the ephemeral secure channel, the devices exchange
 long-term public keys and a value derived from the current temporary
 secret, signed with their long-term private keys, as verification that
 they own those keys and have the same shared secret
 * Nobody signs anything that proves who their contacts are


If you care about deniability I would avoid signatures entirely (e.g. use
Diffie-Hellman based protocols).


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

Re: [cryptography] Asynchronous forward secrecy encryption

[Trevor Perrin]

On Thu, Oct 3, 2013 at 9:57 AM, Michael Rogers mich...@briarproject.orgwrote:


 Great points, thanks! I'd forgotten about triple Diffie-Hellman
 (already, tut tut). Has it received any peer review other than being
 adopted by Moxie?


It was analyzed in a paper by Kudla  Paterson.  See Section 5.1, and the
note near the end that Protocol 1 can easily be extended to have perfect
forward secrecy [...].

http://www.isg.rhul.ac.uk/~kp/ModularProofs.pdf

The Ntor protocol by Goldberg et al is also similar.  It's essentially a
server-authenticated (instead of mutually-authenticated) version of this,
so it's a double-DH (omitting the ephemeral-static DH that would involve
the client's static key).  I believe Ntor is being considered for use in
Tor.

http://cacr.uwaterloo.ca/techreports/2011/cacr2011-11.pdf



 Have you patented it? ;-)


No, nor am I aware of any patents or IPR covering it.



 So a triple-DH version of the protocol would look like this:

 * The introducees exchange single-use public keys and long-term public
 keys via the introducer
 * The introducees use triple-DH to derive a shared secret, destroy
 their single-use private keys, and start key rotation


To state the obvious, you'll need to be quite careful with key derivation
from the 3 ECDH secrets, e.g. also hash in all relevant public keys and
other identifiers, handshake messages, etc., perhaps using something like
HKDF.



 * The introducees exchange acks via the introducer
 * The introducees can optionally obtain each other's long-term public
 keys from other third parties, before or after the introduction
 * If the introducees meet face-to-face, they can confirm each other's
 long-term public keys using SAS:
   - The users verbally exchange short codes to enable their devices to
 find each other over a short-range transport such as wifi
   - The devices exchange hash commitments and ephemeral public keys
   - The users verbally exchange short authentication strings
   - If the strings match, the devices derive symmetric encryption and
 authentication keys from the ephemeral shared secret
   - Within the ephemeral secure channel, the devices exchange
 long-term public keys and a value derived from the current temporary
 secret as verification that they have the same shared secret
 * Nobody signs anything at all


Nothing horrible jumps out at me, though I'm not saying that's a thorough
review!


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

Re: [cryptography] Asynchronous forward secrecy encryption

[Trevor Perrin]

On Sun, Sep 29, 2013 at 8:57 AM, Michael Rogers
mich...@briarproject.org wrote:

 We're also planning to support introductions through mutually trusted
 third parties.
[...]
 Alice and Carol must trust Bob not to MITM the key exchange.

It'd be nice if Alice and Carol could use some additional, out-of-band
channel to authenticate the ephemeral DH exchange.

Best I can think of are short auth strings (SAS), public-key
fingerprints (if you added long-term identity keys), and PAKE.

The tradeoffs are something like:
 * Key fingerprints and SAS are non-secret (unlike PAKE passwords)
 * SAS and PAKE can use short strings of several chars (unlike fingerprints)
 * Fingerprints can be exchanged before *or* after the ephemeral DH
handshake (unlike PAKE passwords or SAS)
 * Fingerprints can be confirmed with 3rd parties or public records
(unlike PAKE passwords or SAS)
 * Fingerprints and PAKE can be compatible with a single, unordered
handshake exchange of ephemeral DH values, unlike SAS


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

Re: [cryptography] Asynchronous forward secrecy encryption

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 24/09/13 07:52, Trevor Perrin wrote:
 On Mon, Sep 23, 2013 at 4:51 AM, Michael Rogers
 The key agreement starts with a hash commitment, followed by an 
 exchange of ephemeral ECDH public keys. Two short authentication 
 strings (again, six decimal digits) are derived from the shared 
 secret; the users exchange the authentication codes verbally to 
 complete the process.
 
 Sounds reasonable but you'll need a 3-way handshake for the short
 auth strings, which could be awkward in an asynchronous
 messaging scenario.

Good point, I should've mentioned that the key exchange protocol is
designed to be carried out face to face; it requires a low-latency
duplex channel, such as wifi or Bluetooth.

We're also planning to support introductions through mutually trusted
third parties. The protocol for Alice to introduce Bob and Carol to
each other will look something like this:

Bob - Alice: I'd like to introduce you to Carol
Bob - Carol: I'd like to introduce you to Alice
Alice - Bob: OK, here's a single-use public key I just generated
Carol - Bob: OK, here's a single-use public key I just generated
Bob - Alice: Here's Carol's single-use public key and contact details
Bob - Carol: Here's Alice's single-use public key and contact details
Alice - Bob: I've deleted my private key and started key rotation
Carol - Bob: I've deleted my private key and started key rotation
Bob - Alice: Carol has started key rotation, you can contact her now
Bob - Carol: Alice has started key rotation, you can contact her now

This process requires two-way communication between Alice and Bob, and
between Bob and Carol, but that communication can be asynchronous and
long distance.

Alice and Carol must trust Bob not to MITM the key exchange. If they
ever meet face to face, they can carry out a fresh key exchange with
short authentication strings to check that Bob didn't MITM them.

Cheers,
Michael

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

iQEcBAEBAgAGBQJSSE3/AAoJEBEET9GfxSfMo7MIAKeQDFLChMyKBBuzmSq29/Wc
rI5HXiCD6CoPj6AU+TrFlpl+WknM/PlqTtYR1RXxmE2uDKyTUij5+ntZhvLg70uG
9D64bAW8gZ41T+MIMp1+7e55XYQt2+WcZen7Cmk78PFuMvexqtOI8OZShfqKYm/y
rwpn5YfC7qV5mqJRM90PfwmEKgoom4mzl0VBw39SMjtXA1vHd4bEBseiAcp3d0h4
momQLGcd5ELbI3n2AfX8grFOcF4QuYBxHRK+bESdzSkKy40cBzdI3T5jaBvRQz5O
SAdrvcw/XR/B40hXc8kzrLuFDPezpAa6ReGwB2ioa0IPJsxXVWpRS/QjmKwo+Xs=
=3Q27
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Asynchronous forward secrecy encryption

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/09/13 12:36, ianG wrote:
 On Thu, Sep 19, 2013 at 09:20:04PM +0100, Michael Rogers wrote:
 
 The key reuse issue isn't related to the choice between
 time-based and message-based updates. It's caused by keys and
 IVs in the current design being derived deterministically from
 the shared secret and the sequence number. If an endpoint
 crashes and restarts, it may reuse a key and IV with new
 plaintext. Not good.
 
 
 Either the whole session has to be renegotiated then, or you need a
 way to inject fresh randomness post-crash.  It's not good to rely
 on counters or RNGs in those circumstances.  Time ?

I'm assuming that if a crash occurs, we can get fresh randomness (e.g.
from the OS) after restarting. Is that not a safe assumption?

I'd prefer not to rely on time, as the rotation periods for
high-latency transports are necessarily long (we don't want to rotate
keys while a message is in transit), so after crashing and restarting
we may have to wait a long time until the next rotation period starts.

 I'm assuming the IV is shared in the enciphered message, as
 otherwise it is unknowable to the recipient if it has 1. in it.

Yes - the format is (random IV || ciphertext || MAC), where the MAC is
calculated over the IV and ciphertext. (If using an authenticated
encryption mode instead of a separate MAC, the IV is included in the
additional authenticated data.)

 It seems we're getting closer to MAC-then-Encrypt.  That is, take a
 HMAC of the plaintext (uses 1, 2).  Use that as (part of?) the IV.
 Encrypt. Deliver the IV + ciphertext.

To be honest I don't see a reason to use any function of the plaintext
as an IV - I'd prefer the IV to simply be a fresh random value,
unrelated to the plaintext, unless there's a reason to doubt that we
can generate such a value.

 I guess I would go back to first principles and ask why we're doing
 this.

Yes, great idea. Here are the requirements as I see them:

1. Protocol obfuscation: Nobody except the intended recipient should
be able to distinguish any part of an encrypted message from random bits

2. Unlinkability: Nobody except the intended recipient should be able
to tell whether two encrypted messages have the same sender or
recipient (except by observing who sends and receives them, of course)

3. Asynchrony: Messages should be deliverable via high-latency
transports such as migrating geese

4. Forward secrecy: Encrypted messages should eventually become
undecipherable by their senders and recipients

5. Error tolerance: None of the above properties should be lost if
messages are lost or reordered in transit

And of course the standard requirements of confidentiality, integrity
and authenticity.

Cheers,
Michael

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

iQEcBAEBAgAGBQJSSFO4AAoJEBEET9GfxSfMWOwIAMUXpoCPePO8pwrt4OhEsruS
WNXw3DZGzTfEf+Rfe7tYulpxwEgz4BHUUjhTHiNe7jEwyYzq47vA5cglgJQAnvMf
fOyeIk4FWhnpgC9MJcBeasBwr9lCxHBm/w2jBfYI5/z9F9fZa8CW7MDhVSrJMdrK
rdVwb5hbyfr9UNPrzGfZ0zw6I9uk7e+1x+L7q+ia4ADGIZ3AuJK9JoYz/FGCQbbB
5HWAGoMvGMKqVMvSItN1Aj25oEyOkaPTb6B5ldrFqa97xsQClh1gQZyHJVcC+FTD
EvyN06Fl1f9KKjLoDr21hSalqsrV9H3F3iim6y/eXYLbr6PCLNupnmWGdnUWvJw=
=3kLK
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Asynchronous forward secrecy encryption

[ianG]

Some thoughts...

On 26/09/13 23:08 PM, zooko wrote:

Let me just mention that this conversation is AWESOME. I only wish the folks
over at Perry's Crypto List (http://www.metzdowd.com/pipermail/cryptography/)
knew that we were having such a great conversation over here.

On Thu, Sep 19, 2013 at 09:20:04PM +0100, Michael Rogers wrote:


The key reuse issue isn't related to the choice between time-based and 
message-based updates. It's caused by keys and IVs in the current design being 
derived deterministically from the shared secret and the sequence number. If an 
endpoint crashes and restarts, it may reuse a key and IV with new plaintext. 
Not good.



Either the whole session has to be renegotiated then, or you need a way 
to inject fresh randomness post-crash.  It's not good to rely on 
counters or RNGs in those circumstances.  Time ?




Another defense against this is to generate the IV from the plaintext, possibly
from the plaintext in addition to other stuff. There are three things that you
might want to throw into your IV generator: 1. the plaintext, 2. a persistent
secret key used only for this purpose and known only to this client, 3. a
random nonce read from the operating system.

I would suggest including 1 and 2 but not 3.



I'm assuming the IV is shared in the enciphered message, as otherwise it 
is unknowable to the recipient if it has 1. in it.


It seems we're getting closer to MAC-then-Encrypt.  That is, take a HMAC 
of the plaintext (uses 1, 2).  Use that as (part of?) the IV.  Encrypt. 
 Deliver the IV + ciphertext.


(I know there is a lot of disrespect about the MAC-then-Encrypt ordering 
but I think it is more to do with certain trickinesses than a wholesale 
ban.  I haven't read up on it tho.  I recall when I was looking many 
moons ago the consensus was that the problems found were easily fixed. 
Dunno.)




This *could* be seen as an alternative to the defense you described:


In the new design, the temporary keys are still derived deterministically from 
the shared secret, but the IVs and ephemeral keys are random.


Or it could be used as an added, redundant defense. I guess if it is an added,
redundant defense then this is the same as including the random nonce -- number
3 from the list above.



Which would mean that the nonce and the IV plaintext hash/HMAC would 
need to be distro'd ?


And the sequence number?

Leaving the time to be guessed and retried +/- n quanta.  That's the 
reason I don't like using the time.  It might be OK if the two parties 
are in live comms, but this is specifically a situation where the 
requirements say nothing nice about the time.


I guess I would go back to first principles and ask why we're doing this.





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

Re: [cryptography] Asynchronous forward secrecy encryption

[zooko]

Let me just mention that this conversation is AWESOME. I only wish the folks
over at Perry's Crypto List (http://www.metzdowd.com/pipermail/cryptography/)
knew that we were having such a great conversation over here.

On Thu, Sep 19, 2013 at 09:20:04PM +0100, Michael Rogers wrote:

 The key reuse issue isn't related to the choice between time-based and 
 message-based updates. It's caused by keys and IVs in the current design 
 being derived deterministically from the shared secret and the sequence 
 number. If an endpoint crashes and restarts, it may reuse a key and IV with 
 new plaintext. Not good.

Another defense against this is to generate the IV from the plaintext, possibly
from the plaintext in addition to other stuff. There are three things that you
might want to throw into your IV generator: 1. the plaintext, 2. a persistent
secret key used only for this purpose and known only to this client, 3. a
random nonce read from the operating system.

I would suggest including 1 and 2 but not 3.

This *could* be seen as an alternative to the defense you described:

 In the new design, the temporary keys are still derived deterministically 
 from the shared secret, but the IVs and ephemeral keys are random.

Or it could be used as an added, redundant defense. I guess if it is an added,
redundant defense then this is the same as including the random nonce -- number
3 from the list above.

Regards,

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

Re: [cryptography] Asynchronous forward secrecy encryption

[Trevor Perrin]

On Mon, Sep 23, 2013 at 4:51 AM, Michael Rogers
mich...@briarproject.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Thanks Trevor and Adam for your comments on this - I take your point
 about the importance of forward secrecy for metadata, so I'll abandon
 the idea of using ephemeral-static ECDH to protect the metadata.

You could update the static ECDH keys used for metadata encryption,
so these aren't necessarily exclusive.  But since you'll probably need
trial decryption for different conversations, I can see why you might
prefer more efficient symmetric crypto.

Ephemeral-static ECDH is still a nice way to add sender forward
secrecy though, since compromise of sender private keys wouldn't
allow decryption of sent messages.  So it could be used with other
forward-secrecy techniques.  For example, Pond uses an OTR-like
Diffie-Hellman ratchet, but adds an extra ephemeral-static ECDH per
message [1].


 The key agreement starts with a hash commitment, followed by an
 exchange of ephemeral ECDH public keys. Two short authentication
 strings (again, six decimal digits) are derived from the shared
 secret; the users exchange the authentication codes verbally to
 complete the process.

Sounds reasonable but you'll need a 3-way handshake for the short auth
strings, which could be awkward in an asynchronous messaging
scenario.


 (Elligator + DH-EKE makes a nice PAKE, fwiw.)

 Thanks, I'll look into it. The protocol I described above is (loosely
 ZRTP-inspired) homebrew, and it would be nice to move to something
 more standard.

Oh, that's not standard at all, it may even need something weird like
a cipher with 256-bit block length... but should be doable [2].


Trevor

[1] See Message encryption at:
https://pond.imperialviolet.org/tech.html

[2] See EKE2 at:
http://www.iacr.org/archive/eurocrypt2000/1807/18070140-new.pdf
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Asynchronous forward secrecy encryption

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks Trevor and Adam for your comments on this - I take your point
about the importance of forward secrecy for metadata, so I'll abandon
the idea of using ephemeral-static ECDH to protect the metadata.

On 20/09/13 01:55, Trevor Perrin wrote:
 Interesting, are the codes passwords?  Short Auth Strings?

Each endpoint generates a random code (19 bits, represented as 6
decimal digits). The users exchange codes verbally, and the endpoints
use the two codes to find each other and obfuscate the key agreement.

The meaning of find each other depends on the communication channel;
in the case of Bluetooth, the endpoints use the codes to generate a
Bluetooth service UUID; each endpoint advertises a service with that
UUID, looks for nearby devices advertising that UUID, and makes an
unpaired RFCOMM connection to any it finds.

The key agreement starts with a hash commitment, followed by an
exchange of ephemeral ECDH public keys. Two short authentication
strings (again, six decimal digits) are derived from the shared
secret; the users exchange the authentication codes verbally to
complete the process.

 (Elligator + DH-EKE makes a nice PAKE, fwiw.)

Thanks, I'll look into it. The protocol I described above is (loosely
ZRTP-inspired) homebrew, and it would be nice to move to something
more standard.

Cheers,
Michael

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

iQEcBAEBAgAGBQJSQCs5AAoJEBEET9GfxSfMLyIH/i1x/yxCsge/QSoYVUhF4tSs
xBeEcZkRzsvaOdA97c02cFBQJqThnS5m3af0T6dxZWr5PfNJBnxO8j0T5gSkjgVL
lSwHUZG17IGWq9xGY49XTkpO/yw91qjvZhoIuzJf4BSnSV3c37sNIC/4GrXT88TA
2yP80YaWJtiLHFBgFoLkK6qKWyB3asIQ+zxd2AOcPtxT4QoQ8ySksSu3SWT9M8do
08hooVd6uVifHvWHSzBGnPIYGdoxeyUYEBwDWXC/ogMRIBqoAZA+nWtScm+cYqZI
um2UIByTRLcE5JOxQHw2IV1FdurBIH/zZJ2Dsc1CbFhEbhEupPxP6Dl/XZM6VsU=
=Otj3
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Asynchronous forward secrecy encryption

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 23/09/13 05:12, Dev Random wrote:
 I've been thinking about this for a while now and I don't see a way
 to do this with today's mobile devices without some external help.
 
 The issue is that it's pretty much impossible to delete data
 securely from a flash device.  That means that in order to
 guarantee PFS, you have to store the keys in memory only.  But
 again, in a mobile environment, you don't have access to stable
 memory either, because of the OS restarting your app, or the device
 itself rebooting.
 
 Let's call this the persistence/deletion issue.

Yes, this is a major issue with current mobile devices. As far as I'm
aware, SSD commands like Trim and Secure Erase aren't available on SD
cards or the built-in flash storage of mobile devices.

Apple came within a whisker of solving the problem in iOS by creating
an 'effaceable storage' area within the flash storage, which bypasses
block remapping and can be deleted securely. However, iOS only uses
the effaceable storage for resetting the entire device (by deleting
the key that encrypts the user's filesystem), not for securely
deleting individual files.

http://web.archive.org/web/20130302170747/http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf

http://esec-lab.sogeti.com/dotclear/public/publications/11-hitbamsterdam-iphonedataprotection.pdf

A similar approach would be possible on Android, but I don't know of
any Android devices with effaceable storage. The closest I've seen is
hardware-backed key storage, where keys are generated, wrapped and
deleted by a TPM-like chip. Software can use the TPM to perform
operations using the wrapped keys but can't directly access them, and
thus they can't be exported from the device without cracking open the
TPM (physically or via a vulnerability).

http://nelenkov.blogspot.co.uk/2013/08/credential-storage-enhancements-android-43.html

In combination with a hardware-based flash controller, this raises the
bar for undeleting data pretty high: the adversary must compromise the
flash controller to get access to data that's been logically but not
physically deleted, then compromise the TPM to unwrap or undelete the
deleted key with which the deleted data was encrypted.

I'm not saying the bar is too high for a national security agency, but
it's too high for some adversaries, so I believe it's worthwhile to
think about forward secrecy on current mobile devices.

 So, I submit that PFS in async messaging is impossible without help
 from some kind of ephemeral, yet persistent storage.  A possible
 solution might be to store a portion of the key material (through
 Shamir's secret sharing) on servers that you partially trust.

Sounds like a great idea, especially in combination with a panic
button or dead man's switch feature that alerts the servers to delete
their shares.

Cheers,
Michael

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

iQEcBAEBAgAGBQJSQDaHAAoJEBEET9GfxSfMw/EH/RQ9nmgB0TfTboQJQThHOD3k
qDD0UrsjHqVwLD4oZu/rFMxIjQv0ECnLh2zJsbR9E0DqEbJAaOQ/GuDcY9RzzZ7S
w1H0Ly1ecJu/iaBQ0Ah0VC+SH0qBWupsk+mSLxeXICMR/6JuMslVYhiErM6mM94O
OLaia9slAoYDSTs+l/fOXXOtzrTTT3Nkn2M9mOhPVe6HAKNi7Ks1qXl/XMe4WZhJ
eTttbqHhkoZDHLnCjKvskwPDUGlcAhNXkZ8sfphWyr77xEOK2md8Okx6oIBzRI53
UgKiVi3g+VwgY9jxeuUUc8xR6/yYXKncEuSCoF+oVKNsRqBTM7trKh1tU+J3Jqk=
=G1oY
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Asynchronous forward secrecy encryption

[Natanael]

I made a suggestion like this elsewhere:

Store the keys split up in several different files using Shamir's Secret
Sharing Scheme. Encrypt each file with a different key. Encrypt those keys
with a master key. XOR each encrypted key with the SHA256 of their
respective encrypted files. Put those XORed keys in the headers of their
respective files.

If you manage to securely wipe just ~100 bits of any of the files, the keys
are unrecoverable.

I don't know if that can provide enough assurance of secure deletion on a
flash memory, but it's better than nothing.
Den 23 sep 2013 14:40 skrev Michael Rogers mich...@briarproject.org:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 23/09/13 05:12, Dev Random wrote:
  I've been thinking about this for a while now and I don't see a way
  to do this with today's mobile devices without some external help.
 
  The issue is that it's pretty much impossible to delete data
  securely from a flash device.  That means that in order to
  guarantee PFS, you have to store the keys in memory only.  But
  again, in a mobile environment, you don't have access to stable
  memory either, because of the OS restarting your app, or the device
  itself rebooting.
 
  Let's call this the persistence/deletion issue.

 Yes, this is a major issue with current mobile devices. As far as I'm
 aware, SSD commands like Trim and Secure Erase aren't available on SD
 cards or the built-in flash storage of mobile devices.

 Apple came within a whisker of solving the problem in iOS by creating
 an 'effaceable storage' area within the flash storage, which bypasses
 block remapping and can be deleted securely. However, iOS only uses
 the effaceable storage for resetting the entire device (by deleting
 the key that encrypts the user's filesystem), not for securely
 deleting individual files.


 http://web.archive.org/web/20130302170747/http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf


 http://esec-lab.sogeti.com/dotclear/public/publications/11-hitbamsterdam-iphonedataprotection.pdf

 A similar approach would be possible on Android, but I don't know of
 any Android devices with effaceable storage. The closest I've seen is
 hardware-backed key storage, where keys are generated, wrapped and
 deleted by a TPM-like chip. Software can use the TPM to perform
 operations using the wrapped keys but can't directly access them, and
 thus they can't be exported from the device without cracking open the
 TPM (physically or via a vulnerability).


 http://nelenkov.blogspot.co.uk/2013/08/credential-storage-enhancements-android-43.html

 In combination with a hardware-based flash controller, this raises the
 bar for undeleting data pretty high: the adversary must compromise the
 flash controller to get access to data that's been logically but not
 physically deleted, then compromise the TPM to unwrap or undelete the
 deleted key with which the deleted data was encrypted.

 I'm not saying the bar is too high for a national security agency, but
 it's too high for some adversaries, so I believe it's worthwhile to
 think about forward secrecy on current mobile devices.

  So, I submit that PFS in async messaging is impossible without help
  from some kind of ephemeral, yet persistent storage.  A possible
  solution might be to store a portion of the key material (through
  Shamir's secret sharing) on servers that you partially trust.

 Sounds like a great idea, especially in combination with a panic
 button or dead man's switch feature that alerts the servers to delete
 their shares.

 Cheers,
 Michael

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

 iQEcBAEBAgAGBQJSQDaHAAoJEBEET9GfxSfMw/EH/RQ9nmgB0TfTboQJQThHOD3k
 qDD0UrsjHqVwLD4oZu/rFMxIjQv0ECnLh2zJsbR9E0DqEbJAaOQ/GuDcY9RzzZ7S
 w1H0Ly1ecJu/iaBQ0Ah0VC+SH0qBWupsk+mSLxeXICMR/6JuMslVYhiErM6mM94O
 OLaia9slAoYDSTs+l/fOXXOtzrTTT3Nkn2M9mOhPVe6HAKNi7Ks1qXl/XMe4WZhJ
 eTttbqHhkoZDHLnCjKvskwPDUGlcAhNXkZ8sfphWyr77xEOK2md8Okx6oIBzRI53
 UgKiVi3g+VwgY9jxeuUUc8xR6/yYXKncEuSCoF+oVKNsRqBTM7trKh1tU+J3Jqk=
 =G1oY
 -END PGP SIGNATURE-
 ___
 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

Re: [cryptography] Asynchronous forward secrecy encryption

[Randolph D.]

Http://spot-on.sf.net
This should have what you search for. Rgds.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Asynchronous forward secrecy encryption

[Adam Back]

Depending on what you're using this protocol for you maybe should try to
make it so that an attacker cannot tell that two messages are for the same
recipient, nor which message comes before another even with access to long
term keys of one or both parties after the fact.  (Forward-anonymity
property).

Otherwise it may not be safe for use via remailers (when the exit is to a
public drop box like alt.anonymous.messages).  And being able to prove who
sent which message to who after the fact is not good either, if that can be
distinguished with access to either parties long term keys (missing
forward-anonymity).

Adam

On Thu, Sep 19, 2013 at 09:20:04PM +0100, Michael Rogers wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 19/09/13 08:04, Trevor Perrin wrote:

I'd have to see a writeup to have real comments.  But to address
the issue of fragility:

It seems you're worried about per-message key updates because in
the (infrequent?) case that a sender's write to storage fails, an
old key would be reused for the next message.

What happens in that case?  You mentioned random IVs, so I assume
the only problem is that the recipient can't decrypt it (as she's
already deleted the old key on receipt of the previous message).


The key reuse issue isn't related to the choice between time-based and
message-based updates. It's caused by keys and IVs in the current
design being derived deterministically from the shared secret and the
sequence number. If an endpoint crashes and restarts, it may reuse a
key and IV with new plaintext. Not good.

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

Re: [cryptography] Asynchronous forward secrecy encryption

[Adam Back]

btw as I didnt say it explicitly, why I claim (forward-anonymous) sequence
security is important is that mixmaster remailers shuffle and reorder
messages.  If the message sequence is publicly viewable that property is
broken up-front, and if the message sequence is observable backwards in time
with disclosure of current keys, in the event of a key compromise anonymity
is lost.

Adam

On Fri, Sep 20, 2013 at 11:19:58AM +0200, Adam Back wrote:

Depending on what you're using this protocol for you maybe should try to
make it so that an attacker cannot tell that two messages are for the same
recipient, nor which message comes before another even with access to long
term keys of one or both parties after the fact.  (Forward-anonymity
property).

Otherwise it may not be safe for use via remailers (when the exit is to a
public drop box like alt.anonymous.messages).  And being able to prove who
sent which message to who after the fact is not good either, if that can be
distinguished with access to either parties long term keys (missing
forward-anonymity).

Adam

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

Re: [cryptography] Asynchronous forward secrecy encryption

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 19/09/13 08:04, Trevor Perrin wrote:
 I'd have to see a writeup to have real comments.  But to address
 the issue of fragility:
 
 It seems you're worried about per-message key updates because in
 the (infrequent?) case that a sender's write to storage fails, an
 old key would be reused for the next message.
 
 What happens in that case?  You mentioned random IVs, so I assume
 the only problem is that the recipient can't decrypt it (as she's
 already deleted the old key on receipt of the previous message).

The key reuse issue isn't related to the choice between time-based and
message-based updates. It's caused by keys and IVs in the current
design being derived deterministically from the shared secret and the
sequence number. If an endpoint crashes and restarts, it may reuse a
key and IV with new plaintext. Not good.

In the new design, the temporary keys are still derived
deterministically from the shared secret, but the IVs and ephemeral
keys are random. The sequence number's only used for generating tags.
So if an endpoint crashes and restarts, it may reuse a tag, but it
will use a fresh IV and ephemeral key, so confidentiality and
integrity won't be lost.

 That's not great, but again this should be rare.  I think you're 
 trying to make decryption failures even rarer by performing less 
 frequent time-based updates (instead of message-based).  But that 
 introduces time-sync and latency failure cases that didn't exist 
 before.  So I'm skeptical it's a reliability win.

We're not using time-based updates because of the storage reliability
issue. We're using them because of two issues with message-based updates.

First, if messages are lost, the sender and recipient can lose
synchronisation: if the sender's sequence number moves beyond the
recipient's window, the sender will start using tags that the
recipient doesn't recognise. To re-synchronise they need to reset the
sequence number periodically.

Second, if a message is intercepted by the adversary and not received,
the recipient will keep the corresponding key until it moves out of
the sliding window. If the sender stops sending messages or the
adversary keeps intercepting them, that may never happen, so there
won't be forward secrecy for the intercepted message. With time-based
updates, the recipient will delete the key regardless of whether the
message is received.

 We've tried to avoid plaintext fields in BTP to make it harder
 to design filter rules to detect or block the protocol.
 
 Makes me curious to see your key agreement.  Elligator?

I hadn't heard of Elligator - thanks for the tip!

Briar's initial key agreement takes place face-to-face over a
short-range transport such as Bluetooth. The key agreement protocol is
weakly obfuscated using the invitation codes the parties verbally
exchange to enable their devices to find each other.

 If you don't want recipients to have to check so many tags, you
 could encrypt the metadata with longer-lived keys (trading off 
 forward-secrecy of metadata for easier processing).  For example,
 each pair of users could have 2 symmetric keys they use to encrypt
 metadata (one for each direction).  Perhaps they could even update
 their sending key whenever the other party ACKs it?

This is a possibility we've discussed. But if the recipient
corresponds with several senders, she has to try decrypting the
metadata with all their keys. Apart from being inefficient, the timing
reveals how many senders she corresponds with.

The recipient could have a long-term public key that senders would use
for encrypting metadata. Until now I didn't know of any public key
cryptosystems with ciphertexts that were indistinguishable from random
strings - but maybe Elligator can serve that purpose:

* Each recipient has a long-term ECDH key pair
* Each message starts with an ephemeral ECDH public key
* The ephemeral public key is indistinguishable from random (Elligator)
* The sender and recipient derive an ephemeral shared secret from the
ephemeral key pair and the recipient's long-term key pair
* A key derived from the ephemeral shared secret is used to obfuscate
the metadata (sender's identity and sequence number)
* The recipient uses the metadata to know which keys to use for
authenticating and decrypting the message

This would work with time-based or message-based updates, and would
allow us to get rid of tags and sliding windows, which would be
fantastic. Any thoughts?

Cheers,
Michael

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

iQEcBAEBAgAGBQJSO1x0AAoJEBEET9GfxSfMmFYIALHFKgC73PHLtxXOktSEnaKh
ZfAala6xYjFLgJWfPNnpH9Zzk3qrVf3CSUdvw/opFh2mEcx1cVyFbx+7i3YeEA89
CH9ISddmOP0j1QMVrA1KFAYhLsQxeGUjgTp88GbCo5hrRNvFd6F8/EwUzp8AyNqG
7fJ8z4YzD6Lis00/bkLWlfqABcymL0ZIwFxpmL95JQSmcgspO9cYAUwjRlz6WVNH
cE+bwL8pmnrwVIXKY/3ONDudlnC31lSaHMnDm7knNE6FkvsYK5Rg62k+KFwe6MTO
+I7XPzGjR4Mje6C3Uq8HLvwYpqJbNgtgYJvzS4kTYmBQ5turAF3MsbacN1nqf08=
=GGzM
-END PGP SIGNATURE-

Re: [cryptography] Asynchronous forward secrecy encryption

[Trevor Perrin]

On Thu, Sep 19, 2013 at 1:20 PM, Michael Rogers
mich...@briarproject.org wrote:

 We're not using time-based updates because of the storage reliability
 issue. We're using them because of two issues with message-based updates.

 First, if messages are lost, the sender and recipient can lose
 synchronisation: if the sender's sequence number moves beyond the
 recipient's window, the sender will start using tags that the
 recipient doesn't recognise. To re-synchronise they need to reset the
 sequence number periodically.

 Second, if a message is intercepted by the adversary and not received,
 the recipient will keep the corresponding key until it moves out of
 the sliding window. If the sender stops sending messages or the
 adversary keeps intercepting them, that may never happen, so there
 won't be forward secrecy for the intercepted message. With time-based
 updates, the recipient will delete the key regardless of whether the
 message is received.

Good points.

If you can do encrypted metadata instead of tags you can solve the
first issue.

The second seems more of a tradeoff:  Message-based updating is better
than time-based against a passive attacker.  But if the attacker is
blocking messages, time-based becomes better.

I'd still prefer message-based for most uses.  It avoids clock issues
and will be better unless the attacker blocks traffic flow, which will
often raise alarms.

You could also combine approaches, and update keys whenever a message
is sent or received, *or* whenever X (hours/days/whatever) have
elapsed since the key was last used.


 Briar's initial key agreement takes place face-to-face over a
 short-range transport such as Bluetooth. The key agreement protocol is
 weakly obfuscated using the invitation codes the parties verbally
 exchange to enable their devices to find each other.

Interesting, are the codes passwords?  Short Auth Strings?

(Elligator + DH-EKE makes a nice PAKE, fwiw.)


 If you don't want recipients to have to check so many tags, you
 could encrypt the metadata with longer-lived keys (trading off
 forward-secrecy of metadata for easier processing).  For example,
 each pair of users could have 2 symmetric keys they use to encrypt
 metadata (one for each direction).  Perhaps they could even update
 their sending key whenever the other party ACKs it?

 This is a possibility we've discussed. But if the recipient
 corresponds with several senders, she has to try decrypting the
 metadata with all their keys. Apart from being inefficient, the timing
 reveals how many senders she corresponds with.

It's not elegant.  But the inefficiency and timing leak might not be a
huge problem.


 * Each recipient has a long-term ECDH key pair
 * Each message starts with an ephemeral ECDH public key
 * The ephemeral public key is indistinguishable from random (Elligator)
 * The sender and recipient derive an ephemeral shared secret from the
 ephemeral key pair and the recipient's long-term key pair
 * A key derived from the ephemeral shared secret is used to obfuscate
 the metadata (sender's identity and sequence number)
 * The recipient uses the metadata to know which keys to use for
 authenticating and decrypting the message

Seems fine, with a couple caveats:
 - You're giving up forward-secrecy for metadata.  If a user's
long-term key is compromised, the metadata of her inbound messages can
be revealed.
  - Handling key rollover could be tricky (ie transitions from one
long-term key to another).

There's also some crypto costs (asymmetrics ops on every message,
message expansion).

But there could be side benefits.  For example, you could use the
ephemeral-static ECDH for encrypting the message as well as the
metadata.  Then, even if all the sender's keys have been stolen
earlier, new messages from her would not be decryptable by an
eavesdropper.


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

Re: [cryptography] Asynchronous forward secrecy encryption

[Adam Back]

Thats a good approach but note it does assume your messages are delivered in
the same order they are sent (even though they are delivered
asynchronously).  That is generally the case but does not have to be -
neither email nor UDP for example guarantee that.  


Maybe you would want to include an authenticated sequence number so the
recipient can detect gaps and out of order messages, though that does create
an attack where the attacker can delete a message, and cause the recipient
to keep messages.

Or better the actual key used could be derived to fix that.  eg
k_{i+1}=H(k_i) delete k_i; but also sk_i=H(1||k_i) then use sk_i values.  In
that way you can keep keys for a gap with no security implication other than
the missing/delayed message security.  Other messages that come afterwards
would be unaffected.

Adam

On Tue, Sep 17, 2013 at 04:14:09PM -0700, Trevor Perrin wrote:

On Tue, Sep 17, 2013 at 2:01 PM, Michael Rogers
mich...@briarproject.org wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Marco,

This is a problem we're working on as part of the Briar project. Our
approach is pretty simple: establish a shared secret when you first
communicate, periodically run that secret through a one-way function
to get a new shared secret, and destroy the old one.


Why not have separate symmetric keys for each direction of
communication (Alice - Bob, Bob-Alice).

Then whenever a party encrypts or decrypts a message, they can update
the corresponding key right away, instead of having to wait.

(Or look at OTR's use of updating Diffie-Hellmans).

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

Re: [cryptography] Asynchronous forward secrecy encryption

[ianG]

On 18/09/13 00:01 AM, Michael Rogers wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Marco,

This is a problem we're working on as part of the Briar project. Our
approach is pretty simple: establish a shared secret when you first
communicate, periodically run that secret through a one-way function
to get a new shared secret, and destroy the old one. Symmetric keys
for encryption and authentication are derived from the current shared
secret.



If I compromise your first shared secret, does that mean every shared 
secret thereafter is compromised?




The rotation period depends on the latency of the underlying
communication channel. For example, if you're communicating by email,
you might rotate to a new shared secret once a week, to allow the
other party to spend a week offline without losing any messages.



How do you coordinate between endpoints for the rotation?  Is it 
strictly time-based?  Or is there some sense of searching the space by 
hashing forward multiple rotations until the message decrypts?




On
the other hand if you're communicating by SD cards attached to
migrating geese, you might rotate less often.



Ah, but does it consider the pâté attack?  ;)



On 16/09/13 12:45, Marco Pozzato wrote:



I'm looking for an asynchronous messaging protocol with support
for forward secrecy: I found some ideas, some abstract paper but
nothing ready to be used.



Without some idea of the problem space you are trying to address, it's 
hard to do more than pluck ideas from existing protocols.




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

Re: [cryptography] Asynchronous forward secrecy encryption

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 18/09/13 00:14, Trevor Perrin wrote:
 Why not have separate symmetric keys for each direction of 
 communication (Alice - Bob, Bob-Alice).

We derive separate keys for each direction from the shared secret.

 Then whenever a party encrypts or decrypts a message, they can
 update the corresponding key right away, instead of having to
 wait.
 
 (Or look at OTR's use of updating Diffie-Hellmans).

We did look at OTR, but unfortunately it's not suitable for our use
case. We want to be able to operate over a wide range of communication
channels, including one-way channels and unreliable, high-latency
channels like the postal service. OTR's forward secrecy requires an
ongoing back-and-forth between the two parties. Our approach doesn't
provide forward secrecy as quickly as OTR's if there's a constant
back-and-forth, but it tolerates lost and reordered messages, one-way
communication, and long pauses in communication.

Cheers,
Michael

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

iQEcBAEBAgAGBQJSObasAAoJEBEET9GfxSfMrRQH/1DKnD3NhMeKgX3CY/Wk0LrR
MLM3SBd6rCHYh3kcVFmR/e08jaTRIF00/6FWJMCRgB5MAxU3iP/9+fXuLhQGHM4u
O3nF2PXBnDYGv+bDwyDhErea9RjfFqIh7MIe2m6VgtOv399aiIvbUH0WrK6RADL3
Gz/VmCKZPZD6ZhPj67YQKOfG7BBmAY3znCCGv+yxDaoxGygqdydOGqRQaAumnAie
5Gvmmc63JYQTlFGd6MUgxa2HJben9PkE1mz5Qy5nlUnUY+fcoLRr9OznTxGTS7cT
W5fU00g95SCUwT3q2cBxNV6J8RMCedWuDyP1htrZcAVEs5ZLk9t/U71IqQOfccE=
=JYLo
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Asynchronous forward secrecy encryption

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 18/09/13 08:12, Adam Back wrote:
 Or better the actual key used could be derived to fix that.  eg 
 k_{i+1}=H(k_i) delete k_i; but also sk_i=H(1||k_i) then use sk_i 
 values.  In that way you can keep keys for a gap with no security 
 implication other than the missing/delayed message security.
 Other messages that come afterwards would be unaffected.

This is very close to the way we currently derive keys. We also derive
a pseudo-random tag corresponding to each key, which is prepended to
the encrypted data so the recipient can detect reordering (using a
sliding window as in IPSec) and use the correct key.

However, this approach is fragile because it requires persistent
storage of a counter - if the app crashes after using a key but before
persistently storing the updated counter, you can end up reusing a
key. Unfortunately, since hard disks and operating systems lie about
having persistently stored data, this can happen even if you store the
counter and call fsync before using the key. So we're moving to a less
fragile approach:

* Rotate the shared secret periodically
* Derive temporary encryption and authentication keys for each
direction from the current shared secret
* Each time you want to send some data, generate a random IV and
ephemeral encryption and authentication keys
* Use the temporary keys and the random IV to encrypt and authenticate
the ephemeral keys

Cheers,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJSObpCAAoJEBEET9GfxSfMrKIH/jfQwJzBaPLx7uKzJdoGHQkJ
8NWSYh3/YePrY8Ukbx9qZUMyBwghRecgf0u/pJeId5+fktgc2u1BVXQCekBIyYCO
YSxmHBDsfQ3cC+5JRMH8U7JwsRMvWDBYJdDCX3IR4ofGJ7+aaJuwqo13vhoToO4C
kkPGvXIvTSpP6YLSvy1wlbHwFy9hb3e3ywvt91jsGvk/nIfBX+eQLEixu/HqjVkN
g6IGvyMgm7B5m5puiodwH7k3fL0vIkdnWAtQZu7S3UztovyFqaJY34NCV+JgusYD
X0cmojyKf1/quePi8exMkeQaibrOPUG3a+O8f+Jhld3Gfv4fyO8EIK3PVoKIMbY=
=2Vz/
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Asynchronous forward secrecy encryption

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 18/09/13 08:23, ianG wrote:
 If I compromise your first shared secret, does that mean every
 shared secret thereafter is compromised?

Yes. (Improvements are possible here, by sending and acking fresh key
material inside the encrypted envelopes, but that requires two-way
communication, so in the one-way case we'd always be vulnerable to the
initial secret being compromised.)

 How do you coordinate between endpoints for the rotation?  Is it 
 strictly time-based?  Or is there some sense of searching the
 space by hashing forward multiple rotations until the message
 decrypts?

It's strictly time-based. The rotation period is based on the maximum
latency of the communication channel and the maximum difference
between the endpoints' clocks, such that if the sender thinks it's
rotation period p at the time of sending, the recipient will think
it's no earlier than period p-1 and no later than period p+1 at the
time of receipt.

If the endpoints have very inaccurate clocks, you get longer rotation
periods but the protocol still works - as long as the endpoints know
roughly how inaccurate their clocks might be.

 Ah, but does it consider the pâté attack?  ;)

Is that a type of meat-in-the-middle attack?

Cheers,
Michael

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

iQEcBAEBAgAGBQJSOb2KAAoJEBEET9GfxSfMae8IAMR0HxXQYUwIgJrQ5byQnIdO
/z8frXW4qhBKtyt+zimpS1N0qBxg5hbQKoSYqSsIq/Et80/Lmjivnv/bHrVvfCeI
RX0aFVvZi3BXthuYqr8x/AAbYun9y/jGAz6UoIDyXXA9oljom//e5AqZK3p9o9sg
eWDltbuc4R5QBMEeMvbL7MM5PxrpSEVGfh0KzQZFn/MOCg6pjDuXWnfWWajf1Eg0
FZvaGNKu9DmNU9hxI8MOZePmiTy9S/Bjayp6Syt1cJTKKT9lT8IQJwRb1tERf/Go
DqrdZBUZmsR1CIlzy9eS2XSUD4hyBqfp+Y2hjWanzsA1JWx7XrcDxxy5jTRJ3+c=
=R1L+
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Asynchronous forward secrecy encryption

[Trevor Perrin]

On Wed, Sep 18, 2013 at 7:35 AM, Michael Rogers
mich...@briarproject.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 18/09/13 08:12, Adam Back wrote:
 Or better the actual key used could be derived to fix that.  eg
 k_{i+1}=H(k_i) delete k_i; but also sk_i=H(1||k_i) then use sk_i
 values.  In that way you can keep keys for a gap with no security
 implication other than the missing/delayed message security.
 Other messages that come afterwards would be unaffected.

 This is very close to the way we currently derive keys. We also derive
 a pseudo-random tag corresponding to each key, which is prepended to
 the encrypted data so the recipient can detect reordering (using a
 sliding window as in IPSec) and use the correct key.

 However, this approach is fragile because it requires persistent
 storage of a counter - if the app crashes after using a key but before
 persistently storing the updated counter, you can end up reusing a
 key. Unfortunately, since hard disks and operating systems lie about
 having persistently stored data, this can happen even if you store the
 counter and call fsync before using the key. So we're moving to a less
 fragile approach:

 * Rotate the shared secret periodically

Hmm, I would've thought clocks are *less* reliable than storage on most devices.

Certainly this has worse forward-secrecy than updating keys
per-message, as keys for old ciphertext are kept around for some
period.


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

Re: [cryptography] Asynchronous forward secrecy encryption

[Trevor Perrin]

On Wed, Sep 18, 2013 at 12:12 AM, Adam Back a...@cypherspace.org wrote:
 Thats a good approach but note it does assume your messages are delivered in
 the same order they are sent (even though they are delivered
 asynchronously).  That is generally the case but does not have to be -
 neither email nor UDP for example guarantee that.
 Maybe you would want to include an authenticated sequence number so the
 recipient can detect gaps and out of order messages, though that does create
 an attack where the attacker can delete a message, and cause the recipient
 to keep messages.

 Or better the actual key used could be derived to fix that.  eg
 k_{i+1}=H(k_i) delete k_i; but also sk_i=H(1||k_i) then use sk_i values.  In
 that way you can keep keys for a gap with no security implication other than
 the missing/delayed message security.  Other messages that come afterwards
 would be unaffected.

Yeah!  That's a great way to do it.

In case of out-of-order delivery, you could eventually delete unused
sk_i values once they get too old.

You could also encrypt the sequence numbers with some static key so as
not to leak info on the # of messages exchanged.


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

Re: [cryptography] Asynchronous forward secrecy encryption

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 18/09/13 17:27, Trevor Perrin wrote:
 Hmm, I would've thought clocks are *less* reliable than storage on
 most devices.

That may be true, but this isn't a choice between relying on the clock
or relying on storage. It's a choice between relying on both, or
relying only on the clock.

 Certainly this has worse forward-secrecy than updating keys 
 per-message, as keys for old ciphertext are kept around for some 
 period.

Yes, updating keys per-message would be preferable if we could assume
an ongoing two-way exchange of messages. For OTR's instant messaging
use case that's a reasonable assumption. For Briar's use case it's not.

Cheers,
Michael

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

iQEcBAEBAgAGBQJSOeFqAAoJEBEET9GfxSfMJFEH/jnyd3SAYKhNAhQVFOYlvyy1
zckK4VQClQPEOwRcidSud9zSxblRQXQGJSO+pB23niHgpbomzDx7fc5jKlShF/yt
sZ8qJ2gj13xZey0rp+DWK3DCcKq0erEbDd58bngJsHtFoVyjYpsZKfMi8Mqhl3iN
2QvEXkwkUzVTSX8bks30WRgGAObimvEHAOU7eOY32xZgy/l2VwUDOws5fd0lc5+p
+HcEQLyckkSZnaF6C/vXa6jbNYigRLzR+UslIVnshg1BWrgShxe+f+2TtWhLDNqD
1y0vRdhW+JzQYcwmmTQyHpKGl5qCQ6vmkYxdmsm6JvGLFR06q+FG8thaWE/VCU4=
=hmqv
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Asynchronous forward secrecy encryption

[Trevor Perrin]

On Wed, Sep 18, 2013 at 10:22 AM, Michael Rogers
mich...@briarproject.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 18/09/13 17:27, Trevor Perrin wrote:
 Hmm, I would've thought clocks are *less* reliable than storage on
 most devices.

 That may be true, but this isn't a choice between relying on the clock
 or relying on storage. It's a choice between relying on both, or
 relying only on the clock.

A quick glance at Briar makes it looks like it already uses local storage:



 Certainly this has worse forward-secrecy than updating keys
 per-message, as keys for old ciphertext are kept around for some
 period.

 Yes, updating keys per-message would be preferable if we could assume
 an ongoing two-way exchange of messages. For OTR's instant messaging
 use case that's a reasonable assumption. For Briar's use case it's not.

 Cheers,
 Michael

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

 iQEcBAEBAgAGBQJSOeFqAAoJEBEET9GfxSfMJFEH/jnyd3SAYKhNAhQVFOYlvyy1
 zckK4VQClQPEOwRcidSud9zSxblRQXQGJSO+pB23niHgpbomzDx7fc5jKlShF/yt
 sZ8qJ2gj13xZey0rp+DWK3DCcKq0erEbDd58bngJsHtFoVyjYpsZKfMi8Mqhl3iN
 2QvEXkwkUzVTSX8bks30WRgGAObimvEHAOU7eOY32xZgy/l2VwUDOws5fd0lc5+p
 +HcEQLyckkSZnaF6C/vXa6jbNYigRLzR+UslIVnshg1BWrgShxe+f+2TtWhLDNqD
 1y0vRdhW+JzQYcwmmTQyHpKGl5qCQ6vmkYxdmsm6JvGLFR06q+FG8thaWE/VCU4=
 =hmqv
 -END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Asynchronous forward secrecy encryption

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 18/09/13 18:56, Trevor Perrin wrote:
 Sorry, mis-send... I meant:
 
 A quick glance at Briar makes it looks like it already uses local
 storage:
 
  Neither endpoint can send more than 2^32 connections to the
 other during a given rotation period. Each endpoint persistently
 stores the highest connection number it has sent to the other
 during the current rotation period, together with a sliding window
 of the highest connection numbers it has received from the other
 during each of the current retention periods. The persistent
 storage of these values is vital, so BTP cannot be used by endpoint
 devices that lack writable persistent storage (unless the devices
 never reboot). 

Yup, that's the fragile current design I mentioned. :-) The new design
still depends on persistent storage, but it avoids the risk of key
reuse if the persistent storage is unreliable.

 But I don't know enough about the protocol to be giving advice, so
 I'll stop...

No, it's always good to get people's views on the design - thanks!

 The per-message symmetric-key update that Adam and I sketched
 doesn't require a 2-way exchange of messages.  Even a one-way
 stream of message would receive good forward secrecy.

Ah, sorry, I was thinking of OTR's per-message update rather than
yours! The method you and Adam suggested would be suitable for our use
case, and much more elegant than what we're using now, except that it
requires a plaintext sequence number.

We've tried to avoid plaintext fields in BTP to make it harder to
design filter rules to detect or block the protocol. So we rely on the
pseudo-random tag to tell the recipient (a) which sender the message
comes from, (b) which rotation period the sender was in when the
message was sent, and (c) the sequence number.

The recipient precalculates a limited number of tags in a sliding
window, which allows a limited amount of message loss or reordering -
but if too many messages are lost, the sender's sequence number will
move beyond the recipient's window, and they'll have to wait until the
next rotation period to resynchronise (the sequence number is reset at
the start of each rotation period).

This is all rather clunky, and I'd love to find a better way to do it,
but so far I haven't been able to work out how. Suggestions welcome! :-)

Cheers,
Michael

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

iQEcBAEBAgAGBQJSOg7cAAoJEBEET9GfxSfMZuAH/jQhZXDNMs0LszDoAE72SNaO
et+uwRk1m8wnChhU1WCuQ8Cmc//tJxcdly9BfzqUafs7q4dj1pl7YEoRI152bs9J
mFcF/Z7oF5/ueZ6m/deuR8e9Lf2oGgIvP8K87/E/DRQFGKR/As7rGs7Or9lchpey
m7OFztfP0BB+uRkHrC7vfdgWqPOQeDnuHa1pItA+zXLqRloze4pPSpuHhvc2EGz2
JqckFQ4b0GRKFdHReYv/S46TO/g96qLjz+wNu9QUw9oAUiSHcuhQcJ7FX0dEXm77
mk78jRRBpaEjLCF03Zt+wcFSHJ30/GSqtdKyYnuJ2OfjMpkF6Ym3odWfzKtoYw4=
=I+Be
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Asynchronous forward secrecy encryption

[Trevor Perrin]

On Tue, Sep 17, 2013 at 2:01 PM, Michael Rogers
mich...@briarproject.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Marco,

 This is a problem we're working on as part of the Briar project. Our
 approach is pretty simple: establish a shared secret when you first
 communicate, periodically run that secret through a one-way function
 to get a new shared secret, and destroy the old one.

Why not have separate symmetric keys for each direction of
communication (Alice - Bob, Bob-Alice).

Then whenever a party encrypts or decrypts a message, they can update
the corresponding key right away, instead of having to wait.

(Or look at OTR's use of updating Diffie-Hellmans).


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

[cryptography] Asynchronous forward secrecy encryption

[Marco Pozzato]

Hi all,

I'm looking for an asynchronous messaging protocol with support for forward
secrecy: I found some ideas, some abstract paper but nothing ready to be
used.

OTR seems the preeminent protocol, but does not have support for
asynchronous communication.
This post https://whispersystems.org/blog/asynchronous-security/ describes
an interesting variation on OTR: the basic idea is to precalculate 100
Diffie-Hellman and consume one at every new message.

On the opposite side, for OpenPGP lovers, I found an old extension
http://tools.ietf.org/html/draft-brown-pgp-pfs-01 which adopt the same
approach, using many short-lived keys, which frequently expire (eg: every
week) and are deleted.

They are both clever ideas to provide PFS, but what does it mean to the
average user? Let say that today I discover an attack run on 1st of August:

   - OTR variation: I do not know which messages were wiretapped. 100
   messages could spawn few hours or two months.
   - OpenPGP: I know I lost messages sent in the first week of August.


What do you think about it?

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

Re: [cryptography] Asynchronous forward secrecy encryption

[Adam Back]

Well aside from the PGP PFS draft that you found (which I am one of the
co-authors of) I also had before that in 1998 observed that any IBE system
can be used to make a non-interactively forware secret system.

http://www.cypherspace.org/adam/nifs/

There were prior IBE systems (with expensive setup and weak security margin
where you had to compute a 512-bit discrete log during to setup to gain
1024-bit security in the cse of Maurer  Yacobi's [1]), however that IBE -
NIFS approach become efficient with Boneh  Franklins 2001 Weil pairing
based IBE.

However personally I consider that to still be a bit experimental on the
experimantal sid and prefer still more conventional approaches.

However in the mean time here's another approach for you (all new AFAIK :)
Use the paillier (1999) cryptosystem to compute discrete log mod n^2. 
(Knowledge of lambda(n^2) (the carmichael function of n^2) allows computing

the discrete log in paillier.) Create some relatively arbitrary set of
public keys y_i in an easily (publicly) computable sequence eg y_i=KDF(i). 
Use lambda to compute x_i st y_i = h^x_i mod n^2 with generator h.  Delete

lambda (and p,q, e, d etc).

Now encryption is (randomized) Elgamal using y_i, h and x_i during epoch i. 
Or for message i (if you stash a big load of public keys on an auxilliary
server for senders to take).  Should be pretty easy to implement. 


discrete log of y = h^x mod n^2 is computed with l = lamda:

define log(y,h) {
  return (modexp(y,l,n^2)-1)/n * modinv((modexp(h,l,n^2)-1)/n,n)%n;
}

(in bc syntax).  


or x = (y^l-1 mod n^2)|n / (h^l-1 mod n^2) mod n

where | is literally divided by (no modulus) and / is multiple my modular
inverse mod n.  n is an RSA modulus.

Adam

[1] Nov 1996 - U M Maurer and Y Yacobi - A Non-interactive Public-Key
Distribution System, Designs, Codes and Cryptography vol 9 no. 3 pp 305-316

On Mon, Sep 16, 2013 at 01:45:43PM +0200, Marco Pozzato wrote:

  Hi all,
  I'm looking for an asynchronous messaging protocol with support for
  forward secrecy: I found some ideas, some abstract paper but nothing
  ready to be used.
  OTR seems the preeminent protocol, but does not have support for
  asynchronous communication.
  This post [1]https://whispersystems.org/blog/asynchronous-security/
  describes an interesting variation on OTR: the basic idea is to
  precalculate 100 Diffie-Hellman and consume one at every new message.
  On the opposite side, for OpenPGP lovers, I found an old
  extension [2]http://tools.ietf.org/html/draft-brown-pgp-pfs-01 which
  adopt the same approach, using many short-lived keys, which frequently
  expire (eg: every week) and are deleted.
  They are both clever ideas to provide PFS, but what does it mean to the
  average user? Let say that today I discover an attack run on 1st of
  August:
* OTR variation: I do not know which messages were wiretapped. 100
  messages could spawn few hours or two months.
* OpenPGP: I know I lost messages sent in the first week of August.

  What do you think about it?
  Marco

References

  1. https://whispersystems.org/blog/asynchronous-security/
  2. http://tools.ietf.org/html/draft-brown-pgp-pfs-01



___
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

Re: [cryptography] Asynchronous forward secrecy encryption

[Trevor Perrin]

On Mon, Sep 16, 2013 at 4:45 AM, Marco Pozzato mpodr...@gmail.com wrote:
 Hi all,

 I'm looking for an asynchronous messaging protocol with support for forward
 secrecy: I found some ideas, some abstract paper but nothing ready to be
 used.

 OTR seems the preeminent protocol, but does not have support for
 asynchronous communication.
 This post https://whispersystems.org/blog/asynchronous-security/ describes
 an interesting variation on OTR: the basic idea is to precalculate 100
 Diffie-Hellman and consume one at every new message.

Not at every new message.  Only for starting a conversation with a new partner.

Once a conversation is started, TextSecure uses OTR's ratcheting
algorithm for updating DH keys as messages are exchanged.

(
For a fuller picture of how this sort of key agreement could be done,
you should also read that post in conjunction with the previous post:

https://whispersystems.org/blog/simplifying-otr-deniability/
)


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

Re: [cryptography] Asynchronous forward secrecy encryption

[Patrick Baxter]

Has anyone here looked at Pond?
https://pond.imperialviolet.org/

Its by Adam Langley and while still very new and maybe in need of more
review, it seems quite promising.

On Mon, Sep 16, 2013 at 4:45 AM, Marco Pozzato mpodr...@gmail.com wrote:
 Hi all,

 I'm looking for an asynchronous messaging protocol with support for forward
 secrecy: I found some ideas, some abstract paper but nothing ready to be
 used.

 OTR seems the preeminent protocol, but does not have support for
 asynchronous communication.
 This post https://whispersystems.org/blog/asynchronous-security/ describes
 an interesting variation on OTR: the basic idea is to precalculate 100
 Diffie-Hellman and consume one at every new message.

 On the opposite side, for OpenPGP lovers, I found an old extension
 http://tools.ietf.org/html/draft-brown-pgp-pfs-01 which adopt the same
 approach, using many short-lived keys, which frequently expire (eg: every
 week) and are deleted.

 They are both clever ideas to provide PFS, but what does it mean to the
 average user? Let say that today I discover an attack run on 1st of August:

 OTR variation: I do not know which messages were wiretapped. 100 messages
 could spawn few hours or two months.
 OpenPGP: I know I lost messages sent in the first week of August.


 What do you think about it?

 Marco



 ___
 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

Re: [cryptography] Asynchronous forward secrecy encryption

[Tony Arcieri]

On Mon, Sep 16, 2013 at 4:45 AM, Marco Pozzato mpodr...@gmail.com wrote:

 I'm looking for an asynchronous messaging protocol with support for
 forward secrecy


There's also Nitro, which is a CurveCP derivative:

http://gonitro.io/

Unfortunately they didn't implement the full CurveCP handshake, which
provides both passive and active forward secrecy. It's unfortunate :(

-- 
Tony Arcieri
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Asynchronous forward secrecy encryption

[Fabio Pietrosanti (naif)]

Il 9/17/13 12:10 AM, Tony Arcieri ha scritto:
 On Mon, Sep 16, 2013 at 4:45 AM, Marco Pozzato mpodr...@gmail.com
 mailto:mpodr...@gmail.com wrote:

 I'm looking for an asynchronous messaging protocol with support
 for forward secrecy


 There's also Nitro, which is a CurveCP derivative: 

 http://gonitro.io/

 Unfortunately they didn't implement the full CurveCP handshake, which
 provides both passive and active forward secrecy. It's unfortunate :(

It's plenty of custom solution and custom technologies to achieve
those goals.

I am wondering why we don't just extend OpenPGP standard, by using
OpenPGP/Mime envelope, to include procedures to achieve Forward Secrecy?

Internet Standard are the bibble and saint text specification to look for.

Shouldn't we first try to improve Internet Standard, and only after look
for custom (and usually not interoperable) implementation?

-- 
Fabio Pietrosanti (naif)
HERMES - Center for Transparency and Digital Human Rights
http://logioshermes.org - http://globaleaks.org - http://tor2web.org

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

Re: [cryptography] Asynchronous forward secrecy encryption

[Tony Arcieri]

On Mon, Sep 16, 2013 at 3:22 PM, Fabio Pietrosanti (naif) 
li...@infosecurity.ch wrote:

  Shouldn't we first try to improve Internet Standard, and only after look
 for custom (and usually not interoperable) implementation?


Well, if you want a forward secrecy for asynchronous communication using
existing Internet standards, perhaps you could use DTLS?

http://tools.ietf.org/html/draft-ietf-sip-dtls-srtp-framework-01#page-20

But FWIW, most of the design elements of Nitro come from CurveCP (albeit
implemented atop TCP):

http://curvecp.org/

Call CurveCP custom if you wish, but it's the sort of thing that *should*
be an Internet standard ;)

-- 
Tony Arcieri
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Asynchronous forward secrecy encryption

[Trevor Perrin]

On Mon, Sep 16, 2013 at 3:36 PM, Tony Arcieri basc...@gmail.com wrote:
 On Mon, Sep 16, 2013 at 3:22 PM, Fabio Pietrosanti (naif)
 li...@infosecurity.ch wrote:

 Shouldn't we first try to improve Internet Standard, and only after look
 for custom (and usually not interoperable) implementation?


 Well, if you want a forward secrecy for asynchronous communication using
 existing Internet standards, perhaps you could use DTLS?

I think Marco was talking about messaging cases where you don't want
the roundtrips of a TLS (or CurveCP) handshake.


 Call CurveCP custom if you wish, but it's the sort of thing that *should*
 be an Internet standard ;)

For another design with a lot of attention to forward secrecy and
immediate (zero-latency) sending, see QUIC [1]...

CurveCP spends 3 DHs, so it's computationally slower than MQV but more
complex than a Kudla  Paterson-style triple DH [2].  I also don't
think it's as amenable to zero-latency data transmission based on
pre-cached or pre-distributed ephemeral info as these other things.

CurveCP is also vunerable to impersonation of a client to a server if
either the client's ephemeral or server's key is compromised, which
are unusual properties for a key agreement protocol [3].


Trevor

[1] 
https://docs.google.com/a/chromium.org/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit

[2]
https://whispersystems.org/blog/simplifying-otr-deniability/
http://www.isg.rhul.ac.uk/~kp/ModularProofs.pdf

[3] http://codesinchaos.wordpress.com/2012/09/09/curvecp-1/
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography