@lvh Here
yay, this channel now exists for a reason
hi
It's nice to meet another person doing crypto with Clojure/ClojureScript
so much crypto
and macros named ✨
So it's been a massive effort to do ECC in ClojureScript
uhuh
do you care about running in browsers or something?
(also, how did you acquire that code? emscripten?)
Yeah, I want my app to be somewhat decentralized. Users should be able to sign their state and pass it to a third party for processing without necessarily going through my server.
But you still need to trust your server, right
Eh, not really.
You have to trust content delivery
I'd do content delivery via IPFS if I could, but maybe in 2019 or something
But I'd love it if someone else wanted to use the library I've been working on.
Sure; that’s what I meant by “trust my server” 🙂
or trust your server rather
anyway; so I do https://github.com/lvh/caesium
I’d like to make that work with libsodium.js in pure JavaScript at some point
but no guarantees when that happens
also potentially JS-but-ffi
for node
I wonder if you could reasonably test the property you care about (determinism) with test.check
It would seem that you could generate nilpotent sequences of operations
I dunno: see an array, copy it; see a map; split it in two and then merge the result
stuff like that
This is cool. Yeah, another reason to go with secp256k1 is that BitCoin already has a proper JNI interface to their library for that curve, which uses GMP to avoid timing attacks...
that might be easier than manual verification because your test stays
But it's not safe for other reasons.
makes sense
apropos: my “ECC for programmers” talk that I do (mostly internally) ends with breaking a secp256k1 impl that doesn’t check if points are on the curve correctly 🙂
I'm pretty crazy about enforcing that everywhere, actually
Anyway, so what do you do if you want to sign {:foo "bar", 123 {:baz 'symbol}}
?
yeah; sorry; for clarity; that wasn’t a criticism of any software you wrote, just why I don’t like secp256k1
Ah, I don't like it because it's not a safe curve - https://safecurves.cr.yp.to/
that is one of the reasons it’s not a safe curve 🙂
(The attack I mentioned is on https://safecurves.cr.yp.to/twist.html)
ok
OK, so signing some data
first off; why do you care about canonicalization?
(I’m not saying that canonicalization is bad; just interested)
I want the client to be able to sign updates to their data when they make a delta, like
{:old-hash [245 0 10 ...], :delta <...>, :new-hash [123 23 0 ...]}
Without them necessarily remembering the hashes; so they can remember what they incidentally sent, rather than what they must have sent?
Well, it's so a third party can reconstruct their transaction history
aha
in my case, txns are signed; so I can just go use the actual signature as a reference; I don’t necessarily care about it being reconstitutable from just the data
i.e. I validate txns before using them for anything anyway
(I dunno if it helps, but I’m using https://github.com/ptaoussanis/nippy)
I will file a ticket to see if peter has thought about this problem at all
test.check might already have something in its ecosystem to produce equal-but-different data structure
s
Yeah, it's worth digging in test.check
...
I guess you probably care about hash-map vs array-map?
Not really, because I have to deal with stuff being in either Clojure or ClojureScript.
I don’t understand the implication
Oh, wait, maybe I do; just poor choice of words on my part
Well, does clojurescript even have array-maps?
You want (= a b)
to imply (= (freeze a) (freeze b))
I’m trying to find a way to define that property cross-runtimely
I guess nippy is not relevant to you then because it’s Clojure-only 🙂
Yeah, I probably just need to do the silly canonical transformation thing. I probably could have something that doesn't load the stack up too high with clojure.walk
Does transit let you pick compressors?
Not in ClojureScript, no...
@lvh Since I'm hashing and flinging deltas around, compression isn't such a big deal...
@lvh One thing that sucks is that ClojureScript falls back on goog.math.Integer
s when deserializing java.math.BigInteger
s, but they aren't actually usable because mulitiplication is broken for them - https://github.com/google/closure-library/pull/741
Gary is the man for trying to fix this mess