The code is open, the algorithms were checked by different guys who understand these intricacies.
and these guys did not say, by chance, why do I need my phone number on the server?
OTR is a messaging protocol that regulates encryption, authentication, key exchange, but in no way concerns the process of producing these keys. And if the key is used as a hash from a phone number or any other sets of bits that someone can replay, the encryption and exchange protocol lose their meaning.
Further, if at least one of the session keys is known, then this criticism becomes relevant:
https://ru.wikipedia.org/wiki/Off-the-Record_Messaging
The authors of the article “Secure Off-the-Record Messaging” criticized the key update scheme used in OTR as not providing additional security [17]. So, in the case of the compromise of the still used ephemeral key k_ {ij}, the side that carries out the man-in-the-middle attack can modify all subsequent messages and ephemeral keys used [18].
which means messages become readable to outsiders
Formobe120, Well, you took it with your own, that even I already get bored.
Yes, I asked the same question 3 times, but there is a reason for that - nobody answered it once.
and the lack of an answer to fundamental questions, including in the faq program, says that it is not open enough, and the developers are not credible
everyone's business, what to use and what not to use, but every time someone reasserts about openness, reliability and security, you should repeatedly ask for what purpose the authors require my number.
And it says not about reading intercepted messages, but about their modification. These are kind of different things.
it was just that this was discussed in the article, but if one is possible, the second is also possible. The bottom line is that many consecutive keys are stored at the same time, which means that the old key can be used to access new messages with new keys. Dale, you can modify the keys by inserting your own, and read messages. You can even several options to compromise suggest. The joke is that all these actions occur automatically at the protocol level, and the user does not notice the substitution of the key and the ability to read SMS in the middle, without analyzing the logs, he will not see it looking only at the program window.
Here are just a more detailed options for compromising the ephemeral key.
I don’t know where it’s going to be, I’ll just have to see how this key is created and whether there is a unique mathematical connection between the keys and some client parameters known on the server. Well, a simple example, instead of a full-fledged random house, use 000 as a key ... or 111 .... that is, a deliberately defined sequence. Or a phone number, or a hash from a phone number, or the like. In short, the key is not transmitted anywhere, no one steals it, but at the right moment, developers can easily calculate it independently of the client. And the protocol is such that only one key is enough to be able to read everything with certain efforts.
Post has been editedformobe120 - 23.12.15, 20:12