⬡-49016 on Nostr: nprofile1q…tvdjy trying to understand scriptjunkies point here, and (even though ...
nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpq0mwq9c623ujjzpql7r4fk090yxrf458sz2egzprw0zn0ca669q9q8tvdjy (nprofile…vdjy) trying to understand scriptjunkies point here, and (even though they make some very questionable claims like a signature automatically proving identity) don't they have a somewhat valid point?
as you mentioned:
In a secure protocol, you first establish the public key for your recipient out-of-band. This is generally what handshake protocols are for, in messaging apps. In TLS contexts, we use certificates for the same reason.
Then, once you have a trusted public key, you use that to validate a signature on the message. Because you have a separate mechanism and process for figuring out which public key is correct, a valid signature is proof that the message is authentic.
so we a) establish OOB that A's public key belongs to A and b) establish that A's message was signed with A's public key to make the conclusion that A signed A's message.
and if it understood scriptjunkie's post correctly and the assumption below holds true, session does this, but just the other way around: it b) establishes that X's message was signed by X's public key (where X is unknown), and a) has already established OOB that A's public key belongs to A, and only if X's public key is A's public key X's message gets authenticated as A's message, which seems like they're doing the same two steps, but just in... reverse order?
like, that bit of code alone is definitely not enough, but this assumes that session does a separate check somewhere that only inserts messages in A's conversation if the OOB-established public key matches the one in the message packet (which has to have been confirmed to have a valid signature from the public key before), but if that assumption holds true, it'd be a very weird but still secure way to do it, or not?
there was zero evidence provided for that claim, so unless that is given this aspect shouldn't be trusted either, but it thinks there is an actually valid point in there
as you mentioned:
In a secure protocol, you first establish the public key for your recipient out-of-band. This is generally what handshake protocols are for, in messaging apps. In TLS contexts, we use certificates for the same reason.
Then, once you have a trusted public key, you use that to validate a signature on the message. Because you have a separate mechanism and process for figuring out which public key is correct, a valid signature is proof that the message is authentic.
so we a) establish OOB that A's public key belongs to A and b) establish that A's message was signed with A's public key to make the conclusion that A signed A's message.
and if it understood scriptjunkie's post correctly and the assumption below holds true, session does this, but just the other way around: it b) establishes that X's message was signed by X's public key (where X is unknown), and a) has already established OOB that A's public key belongs to A, and only if X's public key is A's public key X's message gets authenticated as A's message, which seems like they're doing the same two steps, but just in... reverse order?
like, that bit of code alone is definitely not enough, but this assumes that session does a separate check somewhere that only inserts messages in A's conversation if the OOB-established public key matches the one in the message packet (which has to have been confirmed to have a valid signature from the public key before), but if that assumption holds true, it'd be a very weird but still secure way to do it, or not?
there was zero evidence provided for that claim, so unless that is given this aspect shouldn't be trusted either, but it thinks there is an actually valid point in there