[guardian-dev] ChatSecure

Fri Aug 30 12:29:56 EDT 2013

I think you could thwart the dictionary attack via an appended random
semi-permanent salt to the original password.

But then messages would be per device and not per user.

.. end train of thought ..

-tim

On 8/30/13, Tim Prepscius <timprepscius at gmail.com> wrote:
> Actually, dictionary attacks would work.
>
> I don't know how computationally expensive they would be.
> But since you could perform the attack on real hardware and not a phone....
>
> -tim
>
> On 8/30/13, Tim Prepscius <timprepscius at gmail.com> wrote:
>>> * 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?
>>
>>
>> Alice gives different keys to contacts, and each key would be
>> temporary.  There is no "permanent Alice half key."
>>
>>
>> For instance, the idea in my head would be:
>>
>> Let's say Alice's password is "sumpasswd"
>>
>> 1. On program start up, Alice would compute a derived password using PBE.
>> So PBE of "sumpasswd" = "somelongstring"
>>
>>
>> Each time Alice talks to Bob  (NOT ASYNC):
>>
>> 2. Alice would compute, PBE(X iterations) on
>> "somelongstring+2013-08-30-0850:23.123"
>> And send it to Bob, let's say "wef09jwefj09we0fj9w9e0fw"
>>
>> 3. Alice would also send to Bob, "2013-08-30-0850:23.123"
>>
>>
>> 4. Bob in return would do the same process, using the same time-stamp.
>> And send back "0wef09jewewf09jwe"
>>
>>
>> Bob would store the Alice half key and the timestamp.
>> Alice would store the Bob half key and the timestamp.
>>
>> ---
>>
>> Dictionary attacks - I don't think will work.
>>
>>
>> But I was once told that the inviso shirts have dedicated hardware to
>> breaking PBEs.
>> I was told, probably he was just making it up, that my, 100,000
>> iteration PBE in Mailiverse would take a half day to break.
>> I can only imagine that 100 iterations is a second or so.
>> But again, he could have just been completely making things up, so
>> take this with a large grain of salt.
>>
>>
>> But if I were an adversary, I think I would talk to google/apple and
>> remotely root your phone, not break a PBE.
>>
>>
>> -tim
>>
>>
>> On 8/30/13, Michael Rogers <michael at briarproject.org> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 29/08/13 03:37, Tom Ritter wrote:
>>>> On 28 August 2013 13:22, Michael Rogers <michael at briarproject.org>
>>>> wrote:
>>>>> On 28/08/13 01:41, Tom Ritter wrote: 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.
>>>
>>> Yup, I mentioned that above.
>>>
>>>>> 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.
>>>
>>> Good point! That's a worse attack, as it doesn't require the
>>> cooperation of the prekey server.
>>>
>>>>> 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.
>>>
>>> Wow. The P in PFS seems particularly inappropriate in that case. :-/
>>>
>>> Cheers,
>>> Michael
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.10 (GNU/Linux)
>>>
>>> iQEcBAEBAgAGBQJSID9uAAoJEBEET9GfxSfMXNUH/1BL6fypYKb+V6kpM+BNJ+AH
>>> i5F3ulSE/jypbxY5IlAtZHmsUP8wgBE4biOrQMTXAGAyTWOLKTSepSTRq02xMp84
>>> tTs8u6/2CpoqzudDYdmM8fARKDKBseZpCACjk8GvyUCIhJw05130p1XtH04PCNMK
>>> T3cTDxjrKq+5+V4RR9w6Umh62g8b8BoCKH6smaOwbLS0GshsUr/RlWynMuI/qh+O
>>> 3FO79h6I83CpIrABwIz5akSoA9tKtkiZJe/bWYgn+Pdikg005RpXYVFhKBtoCieL
>>> KnipUx6zeIsGljYaiCs7aMsRNM5xqT3d3hKfyr7kX9kxWyWQijGH+LpFUMXr7Sc=
>>> =8xvn
>>> -----END PGP SIGNATURE-----
>>> _______________________________________________
>>> 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
>>>
>>
>