Mats Jerratsch [ARCHIVE] on Nostr: š
Original date posted:2015-10-27 š Original message: >> 3) All packets from ...
š
Original date posted:2015-10-27
š Original message:
>> 3) All packets from then on are encrypted of form:
>> /* HMAC, covering totlen and data */
>> struct sha256 hmac;
>> /* Total data transmitted (including this). */
>> le64 totlen;
>> /* Encrypted contents, rounded up to 16 byte boundary. */
>> u8 data[];
> Looking at your code it seems totlen is actually the size of the
> unencrypted serialized protobuf message, not the total data
> transmitted right ? If so, the comment is a bit misleading, and why
> make totlen include the length of itself since it doesn't define the
> encrypted message boundaries anyway ?
> Also, why encode the length on 64 bits rather than 32 bits ?
Actually I think we do not need this field. Initially, the idea was to
provide replay protection. You keep track of totlen locally, and
compare it with the value the other party sends to you.
However, as we are using AES-CTR, we do not need to do that. We have a
dedicated counter in the IV that does keep track of all messages in
each direction respectively. If some attacker tries to replay the same
message towards us, we are unable to decrypt it, as the IV is not
correct (as it is assuming a different counter)
Published at
2023-06-09 12:44:57Event JSON
{
"id": "2f5f38c61d4ef7829e773bd85c28cf6cf39fe9c7e8612786ff5c72836bf65cff",
"pubkey": "b8a27d18150405cdfcd44c0dd8db860f5270312300248389bf57ce555c784528",
"created_at": 1686314697,
"kind": 1,
"tags": [
[
"e",
"8f7f2db21682c914495fbd222b86e1fdad7235916c75551e48ed09d538570897",
"",
"root"
],
[
"e",
"3f72ce47c3aa7eda2b4a4062ba901d9c1b19c48d87753437e00b7af4929f26f9",
"",
"reply"
],
[
"p",
"208e7a4699791a0264a0298ffa60456c51ac8d8992096a1b67389965eccc82ff"
]
],
"content": "š
Original date posted:2015-10-27\nš Original message:\n\u003e\u003e 3) All packets from then on are encrypted of form:\n\u003e\u003e /* HMAC, covering totlen and data */\n\u003e\u003e struct sha256 hmac;\n\u003e\u003e /* Total data transmitted (including this). */\n\u003e\u003e le64 totlen;\n\u003e\u003e /* Encrypted contents, rounded up to 16 byte boundary. */\n\u003e\u003e u8 data[];\n\u003e Looking at your code it seems totlen is actually the size of the\n\u003e unencrypted serialized protobuf message, not the total data\n\u003e transmitted right ? If so, the comment is a bit misleading, and why\n\u003e make totlen include the length of itself since it doesn't define the\n\u003e encrypted message boundaries anyway ?\n\u003e Also, why encode the length on 64 bits rather than 32 bits ?\n\nActually I think we do not need this field. Initially, the idea was to\nprovide replay protection. You keep track of totlen locally, and\ncompare it with the value the other party sends to you.\n\nHowever, as we are using AES-CTR, we do not need to do that. We have a\ndedicated counter in the IV that does keep track of all messages in\neach direction respectively. If some attacker tries to replay the same\nmessage towards us, we are unable to decrypt it, as the IV is not\ncorrect (as it is assuming a different counter)",
"sig": "8893ad23b38cdca1774b91e04f2d1ecf6bc9524097313bffdd29e15790cbf502c7dc9f90c4defeecafb71060505165fb2cb404ffc7791d7ad64ea1930883f652"
}