Re: [cryptography] [Cryptography] RSA equivalent key length/strength

2013-09-18 Thread Lucky Green
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2013-09-14 08:53, Peter Fairbrother wrote:

> I get that 1024 bits is about on the edge, about equivalent to 80
> bits or a little less, and may be crackable either now or sometime
> soon.

Moti Young and others wrote a book back in the 90's (or perhaps) 80's,
that detailed the strength of various RSA key lengths over time. I am
too lazy to look up the reference or locate the book on my bookshelf.
Moti: help me out here? :-)

According to published reports that I saw, NSA/DoD pays $250M (per
year?) to backdoor cryptographic implementations. I have knowledge of
only one such effort. That effort involved DoD/NSA paying $10M to a
leading cryptographic library provider to both implement and set as
the default the obviously backdoored Dual_EC_DRBG as the default RNG.

This was $10M wasted. While this vendor may have had a dominating
position in the market place before certain patents expired, by the
time DoD/NSA paid the $10M, few customers used that vendor's
cryptographic libraries.

There is no reason to believe that the $250M per year that I have seen
quoted as used to backdoor commercial cryptographic software is spent
to any meaningful effect.

- ---Lucky

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)

iQIcBAEBAgAGBQJSOhm/AAoJEARVjUj9NCi09/wP/jlBE78qlZdPctkhXXC8CblP
oOYD7OhrxP5eaI6UVHN8gJBZidrYZmGp6a9bGLtqzLZmx1L2DEhrKojyUy8lic71
LyZs2ulIY6GU87xr4k7w9ce25+WvK7LviGCjq1WfRxJtmoTSUpNcRI/CNHHnueWE
lGKFip0RVS0YPnVvgQ5pvDmJUW+2vb/4xi6cx592TaQKmgRQoY7gsFCDwuJsy3K/
OUhaEoM6OIMkboCU7CAtC7w1sqP+6GnDg0ZEUvZ8ILFkPYKyEGgJ+RNiUNOsMlIt
dvCEgmT1jL6tgZWHfByAfsYN54uWp5QMuL277ZKlvcjF2KNN7cPcsA4Y76RxTH7L
7gnzB2aQUn13O4dsmsB/54Mbg2Y+LvYCa40Q5RIi45evjANxx9Bx3sFMr3HbXArO
ijT081OUy6/tZYDXruWHlh3j4RAYp/fHecm4/25pQS9NrTAQnaCCnGMHRiP6/PEw
GtMWsW3TkDts3h41HJ5wU6Rppr1hX3pRn1ZgeNJbtRezcC4BL0pTX0PEZ76bhXze
231wdd15/Fnb8e30HbWLUiRSLKAbY4KWSdfdZBRzty7ZiiCTI3O8vQLg2Ld0iR1a
VYZX+hySDG8ZJvj8qoN3d7AR9q7WJk554aOSGb1ooBafm4YjbzAVglu/Afi48DHu
xZFLLjzDm5BhP5eGvsli
=TsSq
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Asynchronous forward secrecy encryption

2013-09-18 Thread 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

2013-09-18 Thread Trevor Perrin
On Wed, Sep 18, 2013 at 10:22 AM, Michael Rogers
 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.

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).
"""

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


>> 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.

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.


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


Re: [cryptography] Asynchronous forward secrecy encryption

2013-09-18 Thread Trevor Perrin
On Wed, Sep 18, 2013 at 10:22 AM, Michael Rogers
 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

2013-09-18 Thread 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


[cryptography] [liberationtech] "Ibis: An Overlay Mix Network for Microblogging" by Ian Goldberg

2013-09-18 Thread Eugen Leitl
- Forwarded message from Steve Weis  -

Date: Wed, 18 Sep 2013 08:50:09 -0700
From: Steve Weis 
To: "liberationt...@lists.stanford.edu" 
Subject: [liberationtech] "Ibis: An Overlay Mix Network for Microblogging" by 
Ian Goldberg
Reply-To: liberationtech 

Ian Goldberg is speaking about "Ibis: An Overlay Mix Network for
Microblogging" today at the Stanford security seminar. The talk is 4:30pm
in the Gates building, room 463A.

http://crypto.stanford.edu/seclab/sem-12-13/goldberg.html

Abstract:

Microblogging services such as Twitter are extremely popular. While they
are commonly used by people who wish to reveal their names and friends to
the world, some users, such as activists on the ground, may wish to be able
to post without automatically revealing their identities or locations.  An
obvious approach is to use a low-latency anonymity system, such as Tor.
However, low-latency systems fall prey to end-to-end timing attacks easily
accomplished by an ISP or a government monitoring clients while also
watching for posts to appear in real time on the microblogging site.

We present Ibis, a high-latency mix network designed specifically for
microblogging.
Ibis is an overlay network: the mix nodes can be microblogging clients that
come online only sporadicly, and the intermediate encrypted messages are
themselves posted as microblogged entries.  We accomplish this through a
novel cryptographic mix message format that uses only 47 bytes of overhead,
while maintaining three-hop, 128-bit security against offline attack.

This is joint work with Paul Hendry.

Bio:

Ian Goldberg is an Associate Professor of Computer Science and a University
Research Chair at the University of Waterloo, where he is a founding member
of the Cryptography, Security, and Privacy (CrySP) research group.  He
holds a Ph.D. from the University of California, Berkeley, where he
discovered serious weaknesses in a number of widely deployed security
systems, including those used by cellular phones and wireless networks. He
also studied systems for protecting the personal privacy of Internet users,
which led to his role as Chief Scientist at Zero-Knowledge Systems (now
Radialpoint).  His research currently focuses on developing usable and
useful technologies to help Internet users maintain their security and
privacy.  He is a Senior Member of the ACM and a winner of the Early
Researcher Award, the Outstanding Young Computer Science Researcher Award,
and the Electronic Frontier Foundation's Pioneer Award.

-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.


- End forwarded message -
-- 
Eugen* Leitl http://leitl.org";>leitl http://leitl.org
__
ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B  47EE F46E 3489 AC89 4EC5


signature.asc
Description: Digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Asynchronous forward secrecy encryption

2013-09-18 Thread Trevor Perrin
On Wed, Sep 18, 2013 at 12:12 AM, Adam Back  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

2013-09-18 Thread Trevor Perrin
On Wed, Sep 18, 2013 at 7:35 AM, Michael Rogers
 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

2013-09-18 Thread 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

2013-09-18 Thread 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

2013-09-18 Thread 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

2013-09-18 Thread 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

2013-09-18 Thread 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
 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