JSON is utf-8 ... As far as 16 but coffee points, there are still astral character pairs. Binary data should be enclosed to avoid this, such as with base-64.
On Fri, Mar 16, 2018, 09:23 Mike Samuel <[email protected]> wrote: > > > 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-json-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 > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
