Hi everyone,
I've been wondering about how to make asynchronous forward-secret
messaging systems work when the user is accessing message history from
multiple devices.
Say I send a bunch of messages from computer A to another user's
computer U.
Later, I buy myself a new computer B on which I
Or: facebookcorewwwi.onion
See https://lists.torproject.org/pipermail/tor-talk/2014-October/035412.html
___
Messaging mailing list
Messaging@moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging
Computer A encrypts message with a personal key and stores the message in
the cloud. The personal key is never shared so it can't be attacked,
computer B gets the messages and decrypts with the personal key.w
On 31 October 2014 21:04, Nadim Kobeissi nadim@nadim.computer wrote:
Hi everyone,
Den 31 okt 2014 14:04 skrev Nadim Kobeissi nadim@nadim.computer:
Hi everyone,
I've been wondering about how to make asynchronous forward-secret
messaging systems work when the user is accessing message history from
multiple devices.
Say I send a bunch of messages from computer A to another
On Fri, Oct 31, 2014, at 10:01 AM, George Kadianakis wrote:
As part of upcoming funded work, Tor might implement an opt-in
indexing service for HSes: a server where HSes can send their
descriptors if they want to be public. That's for HSes that have the
facebook/twitter threat model; not the
Dear Ximin,
Thanks very much for your explanation. Unfortunately, it only confirms
my pessimistic assumptions regarding the possibility of true forward
secrecy on multiple devices. I was hoping this list would be aware of
some kind of breakthrough I've missed out on, but that doesn't seem to
I should clarify a bit - it's more directly to do with *storing* decryptable
ciphertext (or plaintext, even) somewhere, and indirectly to do with multiple
devices. If you log your 2-party OTR conversations, it kind of defeats the
point of forward secrecy too - the adversary might not be able to
On 10/31/2014 08:00 AM, Ximin Luo wrote:
But if you want a scheme where any device that you might want to
connect to your account (in the future) can decrypt old history, then
I don't think you can get true forward secrecy, since this would
likely involve storing the history somewhere with a
maybe this [0] could give u ideas on how to wrap keys in a way that
provides forward secrecy. The paper comes up with a certain graph with nice
properties so that wrapped keys cannot compromise both last and future
(session) keys... it is applied to secure deletion in the paper though. It
may be
On 10/31/2014 09:10 AM, Ximin Luo wrote:
axolotl is forward-secret doesn't mean the entire application is
forward-secret.
The fact that the device stores message history, reduces the
effectiveness of having sent the message through a forward-secret
scheme like axolotl - an attacker who
-- Original Message --
From: Moxie Marlinspike mo...@thoughtcrime.org
To: messaging@moderncrypto.org
Sent: 2014-10-31 12:36:25 PM
Subject: Re: [messaging] Forward secrecy and multiple devices
On 10/31/2014 09:10 AM, Ximin Luo wrote:
axolotl is forward-secret doesn't mean the
Not sure if this is really on-topic for this list as it seems to be more
about server-to-server messaging / replacing TLS than human-to-human
messaging, but I figured it'd at least be interesting to the people on this
list:
A new paper by Frosch et al. here: http://eprint.iacr.org/2014/904
--
They present an unknown key-share attack on TextSecure; this is rather
serious, to say the least.
Rather puzzling, however:
1. They claim that HMAC(key=constant, message=secret) is not provably
a PRF. The security reduction
13 matches
Mail list logo
