Good thing that I was able to implement it from scratch on Amethyst (including ChaCha20 itself) so, the audit + my own knowledge was enough to make me very confident in the approach.
Also, in 3 year...
lol.
so you do know that when you send a message you have to send two messages to the relay right?
one for you, one for the other person.
in theory you can send each one to a different relay, which decouples this.
but if both relays you sent it to have no auth, someone can be sitting there with a few clients already sitting there waiting for this kind of message.
it's called a timing attack, and it doesn't change anything about the metadata security versus nip-01 if:
a) more than one of the relays that was used has no auth, attacker can listen and find both messages and correlate them to a conversation
b) even if they do get to separate relays, if they were sent to several, and one of each has no auth. done.
and the other thing is the claims about chacha20/poly1305 being superior in any kind of reasonable term over the AES encryption that nip-04 uses are highly specious and deceptive. in actual fact, the big advantage of chacha20/poly1305 is performance. its bits of security are around the same. the only difference is aes uses rijndael in the place of chacha20. most of the internet is still running on AES encryption and at scale a compromise would have to have happened in some way by now. if there was reason to really move to another one with a smaller amount of study of its vulnerabilities and field actual usage.
the vulnerabilities that reputable cryptographic algorithms have are considered to be so small as to be negligable, so called "infeasible" attacks. the bigger problems with these have come from "side channels" and a famous one was the use of bad quality random generators, and in the case of nip-17, as i just outlined, the *protocol* itself has a vulnerability that IS NOT HANDLED.
two, in fact. one, to protect against metadata leaks you need these two conditions:
1. relay uses auth, so that a snoop can't just subscribe to catch everyone's messages
2. clients enforce sending each half of the message to separate relays (that have auth) so that the signal would have to be intercepted to catch the ip address timing and that would be the final boss, and for which somethiing like Tor might help a little.
the protocol is weak on these two points and the first point i just don't know how long it's going to be until you all understand that you are sidestepping the real main vulnerability, with this superstitious distrust of relay operators who you... don't demand they use auth, sitting there everyone smiling happily while strfry still doesn't have any kind of system of nip-42 auth usage and half the clients still don't implement it.
so you do know that when you send a message you have to send two messages to the relay right?
one for you, one for the other person.
in theory you can send each one to a different relay, which decouples this.
but if both relays you sent it to have no auth, someone can be sitting there with a few clients already sitting there waiting for this kind of message.
it's called a timing attack, and it doesn't change anything about the metadata security versus nip-01 if:
a) more than one of the relays that was used has no auth, attacker can listen and find both messages and correlate them to a conversation
b) even if they do get to separate relays, if they were sent to several, and one of each has no auth. done.
and the other thing is the claims about chacha20/poly1305 being superior in any kind of reasonable term over the AES encryption that nip-04 uses are highly specious and deceptive. in actual fact, the big advantage of chacha20/poly1305 is performance. its bits of security are around the same. the only difference is aes uses rijndael in the place of chacha20. most of the internet is still running on AES encryption and at scale a compromise would have to have happened in some way by now. if there was reason to really move to another one with a smaller amount of study of its vulnerabilities and field actual usage.
the vulnerabilities that reputable cryptographic algorithms have are considered to be so small as to be negligable, so called "infeasible" attacks. the bigger problems with these have come from "side channels" and a famous one was the use of bad quality random generators, and in the case of nip-17, as i just outlined, the *protocol* itself has a vulnerability that IS NOT HANDLED.
two, in fact. one, to protect against metadata leaks you need these two conditions:
1. relay uses auth, so that a snoop can't just subscribe to catch everyone's messages
2. clients enforce sending each half of the message to separate relays (that have auth) so that the signal would have to be intercepted to catch the ip address timing and that would be the final boss, and for which somethiing like Tor might help a little.
the protocol is weak on these two points and the first point i just don't know how long it's going to be until you all understand that you are sidestepping the real main vulnerability, with this superstitious distrust of relay operators who you... don't demand they use auth, sitting there everyone smiling happily while strfry still doesn't have any kind of system of nip-42 auth usage and half the clients still don't implement it.