News for hackers. Stuff that matters.
Re:Scuttlebutt Protocol Guide by Rygian on Friday December 24, 2021 @08:10AM (#29673272)
On the contrary, lack of canonical format means plenty of room for implementations to fiddle with the format and introduce bugs and incompatibilities. The same bag of bytes ends up parsed as two different things on two different systems, which leads to SSRF-like vulnerabilities.

Throw away anything at the first byte that breaks canonical representation, don't bother verifying its signature.

Re:Scuttlebutt Protocol Guide by mlyle on Friday December 24, 2021 @01:05PM (#29675983)
> Throw away anything at the first byte that breaks canonical representation, don't bother verifying its signature.

IMO, the opposite order is better because it means you verify that the message is sent by someone you minimally trust before exposing parsers, etc, to attack, and someone attempting attacks must sign the messages. Here, getting an identity is so easy that it doesn't make much of a difference.

As far as attack surface, the cryptographic implementation is hopefully smaller than a higher level parser. The performance implications are unclear (both parsing and signature verification can be expensive).

Re:Scuttlebutt Protocol Guide by yencabulator on Friday December 24, 2021 @05:35PM (#29678434)
If you do that, then there's no point in using JSON -- you won't be able to use preexisting JSON parsers or writers anyway.

Meanwhile, the sign-the-bytes crowd can use any preexisting format.