what security dialogs? and what race conditions? do you know what that means, or are you just throwing around words?
if you mean the “verify your new device” dialog, yeah, it has a problem. it won’t appear most of the time on clients that were not open when you sent the verification request from the new device. I don’t know why, and this is not comfortable, but then I can start verification from a device I already have, and it will work. or I can also just fill in the password from my password manager, which you surely have too.
but I haven’t seen other problems with it recently.
XMPP at least functions reliably, if you ignore all of the protocol extensions and use it like IRC with images of course.
which does not even have a bolted on security that way.
Though the main and only good Android client got archived.
calling element classic good is a bit of a stretch. it was very slow.
That series of dialogs and pretty much everything else, including “verified devices” menu. Also, apart from race conditions it’s often just desync. Like, right now for me, nheko and Element say everything is unverified but fluffychat says everything including itself is verified.
Not Element Classic, I meant aTox (Tox for Android). It still functions, though.
Like, right now for me, nheko and Element say everything is unverified but fluffychat says everything including itself is verified.
its not desynced, it is just not presented well. I think when it shows whether another device was verified, it actually does not show if you have completed verification of that device on your account, but instead whether that device is trusted by the current one (for purposes of sharing keys and whatever). in short, it’s not “the user account trusts the device”, but “this device trusts that device”.
when you verify device A with device B, they will mutually trust each other. if device B already trusted devices C and D, device A will immediately start trusting them too.
if you then log in on device E and you don’t verify it with any of the others, it will basically form a distinct “trust group”.
in your case it seems there are also cases when device A says it trusts B, but B says it does not trust A. how long ago did you verify your nheko, element and fluffychat devices? it looks like their verification could not complete, maybe one of them had a bug at the time or crashed before properly saving its database.
both issues won’t solve themselves automatically, you will have to verify the unverified device again. or if it does not work, report the problem with logs with the function in the app, on both sides.
Not Element Classic, I meant aTox (Tox for Android). It still functicryptosystem
I see. tox seems to be faring worse in security. in matrix, encryption is optional in the protocol, but it’s built on well studied cryptosystem. so far when it fails, it’s people not being able to read messages they should, not unexpected people being able to read messages. and that’s because of flaws in key distribution.
in tox, it seems encryption is mandatory, but they roll their own cryptosystem. and their cryptosystem has flaws that nonexperts commonly run into
Jason Donenfeld, wireguard creator to expert:
I think when your homebrewed crypto protocol falls to basic crypto 101 vulnerabilities that modern AKEs are explicitly designed to prevent, it’s time to pin up the red banners telling people not to use your stuff.
Well, it was like 2 years ago? I had a different Element session than now (new one now for testing), nheko and fluffychat, and I pressed every possible button and nothing happened. When I open nheko, a dialog box says “Activate encryption”; “to make this device trusted {blah blah blah}” with a big “Verify” button. Pressing it does the same as closing the dialog, so a whole lot of nothing. Same right now. I did try logging out and back in on different devices, back then only though.
in tox, it seems encryption is mandatory
Because that’s how it’s routed, yes. Peer to peer with fewer points of centralization (still there for node discovery and TCP<>UDP tunnels and shit). The message encryption and the transport encryption are the same.
I stopped reading there. I mean, good thing to know that it’s possible (especially for potential punks using it and whatnot), but I feel like opsec is fucked regardless in this case.
what security dialogs? and what race conditions? do you know what that means, or are you just throwing around words?
if you mean the “verify your new device” dialog, yeah, it has a problem. it won’t appear most of the time on clients that were not open when you sent the verification request from the new device. I don’t know why, and this is not comfortable, but then I can start verification from a device I already have, and it will work. or I can also just fill in the password from my password manager, which you surely have too.
but I haven’t seen other problems with it recently.
which does not even have a bolted on security that way.
calling element classic good is a bit of a stretch. it was very slow.
That series of dialogs and pretty much everything else, including “verified devices” menu. Also, apart from race conditions it’s often just desync. Like, right now for me, nheko and Element say everything is unverified but fluffychat says everything including itself is verified.
Not Element Classic, I meant aTox (Tox for Android). It still functions, though.
its not desynced, it is just not presented well. I think when it shows whether another device was verified, it actually does not show if you have completed verification of that device on your account, but instead whether that device is trusted by the current one (for purposes of sharing keys and whatever). in short, it’s not “the user account trusts the device”, but “this device trusts that device”.
when you verify device A with device B, they will mutually trust each other. if device B already trusted devices C and D, device A will immediately start trusting them too.
if you then log in on device E and you don’t verify it with any of the others, it will basically form a distinct “trust group”.
in your case it seems there are also cases when device A says it trusts B, but B says it does not trust A. how long ago did you verify your nheko, element and fluffychat devices? it looks like their verification could not complete, maybe one of them had a bug at the time or crashed before properly saving its database.
both issues won’t solve themselves automatically, you will have to verify the unverified device again. or if it does not work, report the problem with logs with the function in the app, on both sides.
I see. tox seems to be faring worse in security. in matrix, encryption is optional in the protocol, but it’s built on well studied cryptosystem. so far when it fails, it’s people not being able to read messages they should, not unexpected people being able to read messages. and that’s because of flaws in key distribution.
in tox, it seems encryption is mandatory, but they roll their own cryptosystem. and their cryptosystem has flaws that nonexperts commonly run into
Jason Donenfeld, wireguard creator to expert:
https://github.com/TokTok/c-toxcore/issues/426
downvote was not me.
Ah, verification and trust are separate. Cool.
Well, it was like 2 years ago? I had a different Element session than now (new one now for testing), nheko and fluffychat, and I pressed every possible button and nothing happened. When I open nheko, a dialog box says “Activate encryption”; “to make this device trusted {blah blah blah}” with a big “Verify” button. Pressing it does the same as closing the dialog, so a whole lot of nothing. Same right now. I did try logging out and back in on different devices, back then only though.
Because that’s how it’s routed, yes. Peer to peer with fewer points of centralization (still there for node discovery and TCP<>UDP tunnels and shit). The message encryption and the transport encryption are the same.
I stopped reading there. I mean, good thing to know that it’s possible (especially for potential punks using it and whatnot), but I feel like opsec is fucked regardless in this case.