On Fri, Mar 16, 2018 at 11:38 AM, C. Scott Ananian <[email protected]> wrote:
> Canonical JSON is often used to imply a security property: two JSON blobs > with identical contents are expected to have identical canonical JSON forms > (and thus identical hashed values). > What does "identical contents" mean in the context of numbers? JSON intentionally avoids specifying any precision for numbers. JSON.stringify(1/3) === '0.3333333333333333' What would happen with JSON from systems that allow higher precision? I.e., what would (JSON.canonicalize(JSON.stringify(1/3) + '3')) produce? > However, unicode normalization allows multiple representations of "the > same" string, which defeats this security property. Depending on your > implementation language > We shouldn't normalize unicode in strings that contain packed binary data. JSON strings are strings of UTF-16 code-units, not Unicode scalar values and any system that assumes the latter will break often. > and use, a string with precomposed accepts could compare equal to a string > with separated accents, even though the canonical JSON or hash differed. > In an extreme case (with a weak hash function, say MD5), this can be used > to break security by re-encoding all strings in multiple variants until a > collision is found. This is just a slight variant on the fact that JSON > allows multiple ways to encode a character using escape sequences. You've > already taken the trouble to disambiguate this case; security-conscious > applications should take care to perform unicode normalization as well, for > the same reason. > > Similarly, if you don't offer a verifier to ensure that the input is in > "canonical JSON" format, then an attacker can try to create collisions by > violating the rules of canonical JSON format, whether by using different > escape sequences, adding whitespace, etc. This can be used to make JSON > which is "the same" appear "different", violating the intent of the > canonicalization. Any security application of canonical JSON will require > a strict mode for JSON.parse() as well as a strict mode for > JSON.stringify(). > Given the dodginess of "identical" w.r.t. non-integral numbers, shouldn't endpoints be re-canonicalizing before hashing anyway? Why would one want to ship the canonical form over the wire if it loses precision? > --scott > > On Fri, Mar 16, 2018 at 4:48 AM, Anders Rundgren < > [email protected]> wrote: > >> On 2018-03-16 08:52, C. Scott Ananian wrote: >> >>> See http://wiki.laptop.org/go/Canonical_JSON -- you should probably at >>> least >>> mention unicode normalization of strings. >>> >> >> Yes, I could add that unicode normalization of strings is out of scope >> for this specification. >> >> >> You probably should also specify a validator: it doesn't matter if you >>> emit canonical JSON if you can tweak the hash of the value by feeding >>> non-canonical JSON as an input. >>> >> >> Pardon me, but I don't understand what you are writing here. >> >> Hash functions only "raison d'être" are providing collision safe >> checksums. >> >> thanx, >> Anders >> >> >> --scott >>> >>> On Fri, Mar 16, 2018 at 3:16 AM, Anders Rundgren < >>> [email protected] <mailto:[email protected]>> >>> wrote: >>> >>> Dear List, >>> >>> Here is a proposal that I would be very happy getting feedback on >>> since it builds on ES but is not (at all) limited to ES. >>> >>> The request is for a complement to the ES "JSON" object called >>> canonicalize() which would have identical parameters to the existing >>> stringify() method. >>> >> Why should canonicalize take a replacer? Hasn't replacement already happened? > The JSON canonicalization scheme (including ES code for emulating it), >>> is described in: >>> https://cyberphone.github.io/doc/security/draft-rundgren-jso >>> n-canonicalization-scheme.html <https://cyberphone.github.io/ >>> doc/security/draft-rundgren-json-canonicalization-scheme.html> >>> >>> Current workspace: https://github.com/cyberphone/ >>> json-canonicalization <https://github.com/cyberphone >>> /json-canonicalization> >>> >>> Thanx, >>> Anders Rundgren >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] <mailto:[email protected]> >>> https://mail.mozilla.org/listinfo/es-discuss < >>> https://mail.mozilla.org/listinfo/es-discuss> >>> >>> >>> >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
