[guardian-dev] ChatSecure

[Michael Rogers]

Hi Tim,

Thanks for clearing up my misunderstanding of your proposal. A couple of new questions come to mind:

* Does Alice give the same half-key to all her contacts? If so, a mutual contact of Alice and Bob receives both their half-keys and can work out the key they share. If not, how does Alice create different half-keys for all her contacts?

* Can Alice carry out a dictionary attack on the half-key she receives from Bob to discover his password?

Cheers,
Michael

Tim Prepscius <timprepscius at gmail.com> wrote:

>Um, just to clarify.
>
>My proposal, however flawed it might be would not require anybody
>remembering lots of passwords.
>
>Basically, all the clients store "halves of keys."
>
>So, Client A computes a half key KA, sends it to Client B, who stores it.
>Client B computes a different half key KB and sends it to Client A,
>who stores it.
>
>Client A stores KB.
>Client B stores KA.
>
>
>
>So algorithm would be, "Tim" wants to send "Bob" a text.
>Bob is not on line.
>
>Tim looks up Bobs "half-key" KB in his local DB.
>Tim has Bobs KB, yay.
>Tim computes his own half key KT, using his password
>"f09jwef90jwef0j9ewf" and something else.
>Tim finds the AES-256 key by combining KB & KT.
>
>Tim sends somewhere message encryted with Key-Final.
>Bob picks up message later.
>
>
>--
>
>Of course there are lots of problems, but just to clarify, only one
>password per person.
>The password sort of becomes the "private-key."
>
>
>
>-tim
>
>
>On 8/28/13, Tom Ritter <tom at ritter.vg> wrote:
>> On 28 August 2013 13:22, Michael Rogers <michael at briarproject.org> wrote:
>>> On 28/08/13 01:41, Tom Ritter wrote:
>>>> In Guardian does move forward with a prekeying approach (and I
>>>> think it makes sense), I would love to see it support Federation,
>>>> so I can give my prekeys to a server I control, and not rely on the
>>>> prekey server you run. [1]  However, as elijah pointed out [2], my
>>>> concern goes away if we can check a signature on the prekey from a
>>>> longterm key we trust.  That key could be PGP, or an Identity Key
>>>> for OTR.
>>>
>>> Even if the keys are signed, forward secrecy can be lost if the server
>>> misbehaves. (This may require the cooperation of the chat server or a
>>> network attacker if the chat server's separate from the prekey server.)
>>>
>>> Attack: The server hands out a prekey and then keeps the encrypted
>>> message instead of delivering it to the recipient.
>>
>> The prekey server is not necessarily the server who receives the
>> message however.  (Moxie's prekey server doesn't receive the messages
>> at all.)  The messages are delivered to the XMPP server if the contact
>> is offline, or in the case of SMS, stored by the telco.
>>
>>> The recipient
>>> doesn't know the prekey has been used and therefore doesn't delete the
>>> corresponding private key, which may be recovered at a later time,
>>> breaking forward secrecy.
>>
>> What I said above notwithstanding, messages encrypted to prekeys
>> definitely do not have as much 'forward secrecy' as others.
>> Rephrasing your attack, if Alice sends a message to Bob encrypted to a
>> prekey, the government-run telco pauses the SMS in transit, and then
>> compels Bob to hand over the private key, which Bob is hanging onto
>> waiting to receive a message encrypted to it.
>>
>>> Defence: The recipient numbers the prekeys before signing them. The
>>> server should hand them out in order, and should deliver the encrypted
>>> messages to the recipient in order. If the recipient receives a
>>> message out of order, all older private keys are deleted and the user
>>> is alerted.
>>
>> This makes me nervous.  Just like UDP, I don't believe there's any
>> guarantee that SMS' sent first will arrive first.  Similarly for XMPP.
>>
>>> Attack 2: A malicious sender requests a prekey from the server and
>>> then doesn't send an encrypted message. The server can't deliver any
>>> subsequent messages without triggering an alert.
>>
>> That one's pretty bad - a problem with the prekey approach is if
>> someone Denial of Services a user's prekey, in Moxie's design, the
>> server will send a last-ditch, reused, key to all future recipients,
>> until it is restocked with prekeys.
>>
>> -tom
>> _______________________________________________
>> Guardian-dev mailing list
>>
>> Post: Guardian-dev at lists.mayfirst.org
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>
>> To Unsubscribe
>>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>         Or visit:
>> https://lists.mayfirst.org/mailman/options/guardian-dev/timprepscius%40gmail.com
>>
>> You are subscribed as: timprepscius at gmail.com
>>