- From: Chris Boscolo <chris@boscolo.net>
- Date: Mon, 29 Oct 2018 15:20:49 -0700
- To: msporny@digitalbazaar.com
- Cc: public-credentials@w3.org
- Message-ID: <CAByYRhY_XrvU_uFXGu639t5jAm+tbaPxxc7Pv2Gr+wdbuLxk4g@mail.gmail.com>
Manu, To be clear, I'm not calling into question yours or any other member of this group's experience with cryptography. (Tho, it's worth pointing out that the number of downloads has little bearing on whether the implementation has no critical vulns. Heartbleed has proven this.) I mention my own experience only because I am newer to this group, and I don't want you to assume that I don't have this same experience. My concern is the following: I have a JSON-LD doc, call it VC1, that after canonicalization hashes to XYZ. If there are any vulnerabilities in the parser, perhaps a strange buffer overflow, I *may* be able to modify VC1, call it VC2, so that it also canonicalizes and hashes to XYZ, but when queried returns different values than expected due to the buffer overflow. IMO, it just seems unsafe to allow data that has been signed to be modified in any way and still produce the same signature. -chrisb On Mon, Oct 29, 2018 at 2:22 PM Manu Sporny <msporny@digitalbazaar.com> wrote: > > BTW, as one who has developed protocol-level encryption software, the > > comment "ability to add non-signature-destroying whitespace" makes me > > cringe. It seems like it is just needlessly opening the door to a > > new attack vector. > > Note that we have experience writing cryptography / digital signature / > encryption software that is broadly deployed as well (several million+ > installs per week)... so, I'm asking this question from that perspective: > > What's the specific attack? The details matter. > >
Received on Monday, 29 October 2018 22:21:24 UTC