[guardian-dev] ChatSecure

Tim Prepscius timprepscius at gmail.com
Fri Aug 30 09:08:08 EDT 2013


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


More information about the Guardian-dev mailing list