>> Once a crisp and nicely implementable asynchronous protocol with forward
>> secrecy comes up, however, we should have it implemented
>> immediately.(The synchronous ones are easy, of course.)
>Whispersystems has done a good job with Textsecure as ar as I read the
>opinions about it. In practice their application is very usable too,
>except that MMS does not work in some circumstances (but who uses that
>anyway in 2014?)
Think about implementing forward secrecy for a moment and imagine, you had to develop a "forward secret PGP"(actually in my opinion it should properly be called backward secrecy for that matter.....)
You have to keep track of all one to one communications with their current status of shared secrets. This is much more data to be kept secret than without fs. In fact depending on your activity possibly so much more that simply enciphering the whole database would not be efficient anymore. You would have to use a random access cipher (like e.g. in truecrypt). You don't have it yet? Then you have to code it - a formidable task- or get it from some other source. Just in case - do you trust the other source...?
And if you have a random access cipher, what amount of information is visible to the intruder just from viewing the outer structure and its reaction to activity of this random access database cipher?
How do you deal with simultaneously maintaining one to one communications that exchange messages 10 times a day as well as comms that talk to each other once every other year. This is a problem if you have a systen that changes public keys on a time basis.
You will have to delete info regarding dead communication strands to keep the database compact. What time do you set to declare a strand dead?
How do you recover if messages were lost or if a deleted strand suddenly is reanimated by your peer? How do you recover without opening a soft flank to attackers who want to highjack the strand?
How do you recover if messages were lost or if a deleted strand suddenly is reanimated by your peer? How do you recover without opening a soft flank to attackers who want to highjack the strand?
How do you detect it when a strand was highjacked by a MITM-Attack?
How do you deal with highly asymmetric communication strands, once a year into one direction, twice a day into the other direction?
How about a busy strand where one strand sends two messages in rapid succession and resets his timer in between and the messages arrive in reversed order? How do you recover in this case?
How do you synchronize databases if a user wants to sustain the one to one communication using different systems(e.g. office PC - netbook-smartphone) intermittingly.
I can go on and on and on. To me this IS like opening a can of worms. And I seriosly doubt if the pain is worth the reward(forward secrecy).
Matthew Green mentions the Axolotl protocol and TextSecure(which you refer to in your post as well) as a product that uses it. Well if TextSecure/Axolotl -which I haven't used and don't seriously know yet- solved all these problems satisfactorily and securely I bow in humble adoration(seriously).
You should have a look at the Axolotl protocol https://github.com/trevp/axolotl/wiki
First look at the humongous state variable!
Then it takes about 60 lines of description where a standard public key protocol would take about 5. From studying the protocol, you can see that some of the above mentioned problems might be solved, yet we don't know how it stands against a brilliant attacker. The sheer complexity makes me feel very uneasy.
Then it takes about 60 lines of description where a standard public key protocol would take about 5. From studying the protocol, you can see that some of the above mentioned problems might be solved, yet we don't know how it stands against a brilliant attacker. The sheer complexity makes me feel very uneasy.
In my view, the axolotl protocol has the elegance of transporting water in a bucket with twenty something holes, where each hole got a cork plugged into it. I wouldn't want to code it.
By the way - Green (rightfully) critizises PGP for bad defaults (e.g. using SHA1) yet he praises TextSecure which heavily relies on SHA1. This leaves me baffled.
Cheers,
Michael Anders
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
