-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
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 =
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
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,
-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
-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
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
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
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
-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:
-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
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
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
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
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
-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
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
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
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
-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
-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
-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,
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
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
-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
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
-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.
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,
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
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
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
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,
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:
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
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?
35 matches
Mail list logo
