
Advanced cryptographic ratcheting - ali71
https://whispersystems.org/blog/advanced-ratcheting/
======
zmanian
This isn't a great post for explain the simple elegance of Axolotol. There
probably needs to be one.

My favorite parts comes from combining of Diffie–Hellman operations on both
long term and ephemeral keys to integrate identity verification and creation
of deniable shared secret into one operation.

It's a really elegant extension of NaCL's secret box to include Perfect
Forward Secrecy.

There are some things that are objectionable.

GPL licensing makes Open Whisper Systems a gate keeper to using the battle
tested code base for most users. This is probably unnecessary. It isn't that
hard to implement yourself giving a working curve library.

We need to better explain to developers with Ellitic Curve Crypto and
Curve25519 aren't scary just because the math is a little unfamiliar and that
RSA and integer field Diffie Hellman are code smell.

~~~
NateLawson
The reason it works so well is that Trevor started with the question "why is
OTR so complicated?" and began removing parts until he had the minimum. Then,
he looked at that and built a completely different protocol that achieved the
same goals but where every part mattered.

That's usually the sign of a good crypto design -- every bit of the message
and computation is vital and can't be removed without everything else falling
apart. Excessive round trips, duplicate fields, data sent twice -- these are
all signs of a lousy design that probably has security flaws.

~~~
dvanduzer
It would be a far simpler crypto design if it didn't insist on deniability as
a feature.

OTR always operated in a weird niche, but it solved a specific problem for IM
that everyone had. But simpler / more elegant protocols don't always win, and
never because of the quality of the crypto. For example:
[https://en.wikipedia.org/wiki/Simple_public-
key_infrastructu...](https://en.wikipedia.org/wiki/Simple_public-
key_infrastructure)

~~~
rosser
If you need deniability, you _need_ it. Like, your life could literally depend
on having it.

I'd say that justifies some protocol complexity.

------
acqq
If I understand correctly, Open Whisper servers are still needed for
TextSecure/Signal applications to work, there are even some initial keys
involved, and if these servers were actually malicious, everything would be
compromised?

That would mean that checking the open sources they publish doesn't help as we
don't know what they actually do on the server side.

Now I'd very much like to be proven wrong, so if anybody knows any independent
work that claims that the protocols are made so that what's on the server
doesn't matter, please post and I thank you in advance.

Also, does anybody know if the sources they publish are enough to make the
fully independent infrastructure (run own servers)?

~~~
zmanian
Out of band verification of key fingerprints is necessary to protect against a
malicious server. Users are encouraged to tweet their public keys and verify
in person.

We don't have any mechanism other than trusting Whisper Systems that their
client binaries matches the sources.

The truly paranoid could be their own client application from source.

~~~
acqq
Do you talk about TextSecure or PGP when you talk about "out of band
verification of key fingerprints"? I'm talking about TextSecure.

And I'm not interested in the client side, but in the server side of the
security. I assume I can rebuild the client using the sources and compare
their client with my build.

What I can't assume is that their servers aren't, for example, infested by
some state security malware which takes over the control. I want the protocols
that work even when the server is subverted.

~~~
zmanian
Textsecure has out of band fingerprint verification.

There are that are working on eliminating the need for central server for
message delivery and key server roles like

[https://briarproject.org/](https://briarproject.org/)

[https://github.com/muttr/whitepaper/blob/master/README.md](https://github.com/muttr/whitepaper/blob/master/README.md)

~~~
acqq
I don't see what these other projects you link to change to the TextSecure
protocol. What I'm interested in is this part of the protocol description:

[https://whispersystems.org/blog/asynchronous-
security/](https://whispersystems.org/blog/asynchronous-security/)

"At registration time, the TextSecure client preemptively generates 100 signed
key exchange messages and sends them to the server. We call these “prekeys.” A
client that wishes to send a secure message to a user for the first time can
now: - Connect to the server and request the destination’s next “prekey.”"
Etc.

How is this not giving the server chance to insert its own keys and not the
ones user generated?

What the QR code thing is actually doing? From what I understand, the
TextSecure/Signal in one way or another send your contacts to the server and
the server stores "prekeys" and delivers them to the clients. Where is any
analysis that says that all this stuff doesn't mean that we have to trust that
the server is not evil?

If the QR code means "yes it's the person you want to communicate to" but the
contacts are on the server and the prekeys are delivered from the server, am I
any better?

I need to read somewhere that the server is not weak point and why it is not.
Any link?

~~~
caf
_How is this not giving the server chance to insert its own keys and not the
ones user generated?_

Because the server can't sign the key exchange messages - the private key is
generated on the client and never leaves it.

~~~
acqq
So would everything be safe if the server is controlled by an attacker and the
attacker can also act as MtM for the communication data? Is there any
analysis/verification of the full protocol and/or whole process of
TextSecure/Signal as they are commonly used? I'd greatly appreciate the link.

------
InfiniteEntropy
It'd be even better if their libraries didn't have cancer.

