benlaurie

objecthash

Ruby2016–2019

benlaurie / objecthash

objecthash

A way to cryptographically hash objects (in the JSON-ish sense) that works cross-language. And, therefore, cross-encoding.

Security & Privacy Data & Databases

Explore on GitHub Read Hacker News discussions

4Distinct people

6Mentions

0Explicit recommenders

147GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

A way to cryptographically hash objects (in the JSON-ish sense) that works cross-language. And, therefore, cross-encoding.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year6 dated mentions

Observed mentions: 2016-11-02 19:20:50 UTC to 2019-07-24 16:40:19 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	3	1	2
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	1	0	1
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	1	0	1
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	0	1

What Hacker News says

6 sources

lvh·Jul 24, 2019

A super-awesome related project I didn't get a chance to work into this post (because it's entirely deserving of its own): https://github.com/benlaurie/objecthash To be clear: I think that's a niche use case and while I think ObjectHash does a great job of exploring it, I don't expect the median startup to need an ObjectHash implementation. (Disclaimer: I'm the author.)

In How not to sign a JSON object

aeijdenberg·Nov 5, 2018

Not quite as simple as a cryptographic hash alone - remember that if the set of possible inputs can be easily enumerated, then it's trivial to find the input data by brute force. There are ways to work around this, for example objecthash[0] describes a small modification that prepends the input data with 32 bytes of random data before hashing in order to prevent this. [0] https://github.com/benlaurie/objecthash#redactability

In Show HN: Interactive implementation of the NIST Blockchain use case flow chart

aeijdenberg·Mar 14, 2017

If you're looking to be able to consistently hash JSON objects you might want to look at Ben Laurie's objecthash: https://github.com/benlaurie/objecthash It describes a consistent way to hash an object without defining a new format.

In Son – A minimal subset of JSON for machine-to-machine communication

bascule·Nov 2, 2016

JSON is not defined in terms of UTF-8. That would be patently ridiculous, since UTF-8 is a serialization. TJSON is defined as a serialization format on top of a JSON-like data model. The TJSON spec originally used the terminology "Unicode String", but moved to using "UTF-8 String", the rationale for which is given here: https://github.com/tjson/tjson-spec/issues/27 If your intent is to actually effect a change in the specification, that is the proper place to do it, but specific criticisms of the exact wording of the specification, preferably in the form of pull-requests, would be the best way to affect such changes. If your intent is not to effect a change in the specification, you're entitled to your opinion, but I'm done discussing the matter as the discussion has ceased to be meaningful to me. Generic criticisms like "You used 'UTF-8'

Read the rest

instead of 'Unicode'" outside the context of specific sections of the specification aren't particularly helpful. Furthermore, what does the author intend for escaped characters? Are they allowed? Presumably not, since that would provide for non-canonical representations. You are continuing to miss the point: TJSON intends to provide a foundation to use content-aware content hashing in lieu of a canonicalization scheme as an alternative solution which works across multiple encodings of the same data, sidesteps the exact problems you're talking about, and also allows arbitrary subsets of an object graph to be authenticated without requiring rehashing/resigning. Please see this closed issue on canonicalization ("won't do"): https://github.com/tjson/tjson-spec/issues/24 From what I can gather, TJSON is offering a degree of abstraction you have not yet fully gleaned. The core idea is: many serializations, one underlying data structure/object graph. TJSON is a mere serialization layer, and indeed many TJSON documents may refer to the same underlying data structure, but all will have the same "objecthash": https://github.com/benlaurie/objecthash

In Introducing TJSON, a stricter, typed form of JSON

juancampa·Nov 2, 2016Submission

Object Hash

1 points · Open discussion

bascule·Nov 2, 2016

Floating points already have a distinct type. Many JSON parsers already convert number literals to floats in all cases. For ones that emit a mixture of integers and floats, converting to a float consistently is a simple transform. Floats are not typically used in the intended contexts for TJSON (cryptographically authenticated data), and normalizing them is rather difficult: https://github.com/benlaurie/objecthash/blob/master/objectha...

In Introducing TJSON, a stricter, typed form of JSON