[flagged]
Signing data structures the wrong way
41–50 of 59 posts
Re: Signing data structures the wrong way
#42DSSE is great for this, if you need more schema use in-toto
Re: Signing data structures the wrong way
#43[flagged]
Re: Signing data structures the wrong way
#44Earlier quoted context omitted.
I would say two problems with the asn.1 approach are: (1) it seems like too much cognitive overload for the OIDs to have semantic meaning, and it invites accidental reuse; I think it matters way more that the OIDs are unique, which randomness gets you without much effort; and (2) the OIDs aren't always serialized first, they are allowed to be inside the message, and there are failures that have resulted ( https://nvd…
Those CVEs seem a little more subtle than OID serialization issues. In the first example there are actually two distinct problems in concert that lead to the vulnerability, one of which is when a "low public exponent" is used. https://github.com/digitalbazaar/forge/commit/3f0b49a0573ef1...
This is Bleichenbacher's rump-session e=3 RSA attack. It's pretty straightforward, and is in Cryptopals if anyone wants to try it. If you don't check all the RSA padding, and you use e=3, you can just take an integer cube root.
Re: Signing data structures the wrong way
#45The crypto dev community has a strange idea that working with binary is superior. For many algorithms, it's not. It just obfuscates what's happening and the performance advantage is negligible... Especially in the context of all the other logic in the system which uses far more resources.
I didn't know that Protobuf wasn't canonical but even without this knowledge, there are many other factors which make it an inferior format to JSON.
Also, on a related topic; it seems unwise that essentially all the cryptographic primitives that everyone is using are often distributed as compiled binaries. I cannot think of anything more antithetical to security than that.
I implemented my own stateful signature algorithm for my blockchain project from scratch using utf8 as the base format and HMAC-SHA256 for key derivation. It makes it so much easier to understand and implement correctly. It uses Lamport OTS with Merkel MSS. The whole thing including all dependencies is like 4000 lines of easy-to-read JavaScript code. About 300 lines of code for MSS and 300 lines for Lamport OTS... The rest are just generic utility functions. You don't need to trust anyone else to "do it right" when the logic is simple and you can read it and verify it yourself! Simplicity of implementation and verification of the code is a critical feature IMO.
If your perfect crypto library is so complex that only 10 people in the world can understand it, that's not very secure! There is massive centralization and supply chain risk. You're hoping that some of these 10 people will regularly review the code and dependencies... Will they? Can you even trust them?
Choosing to use a popular cryptographic library which distributes binaries is basically trading off the risk of implementation mistake for the risk of supply chain attack... Which seems like a greater risk.
Anyway it's kind of wild to now be reading this and seeing people finally coming round to this approach. I've been saying this for years. You can check out https://www.npmjs.com/package/lite-merkle feedback welcome.
Re: Signing data structures the wrong way
#46Why not digest the type as part of the hash? This avoids the problem in the article and keeps the transmission size small.
They use a magic number, rather than a digest derived from the schema[1], but otherwise they do as you suggest. The magic number is given to the signing function (sender side) and the validation function (receiver side) but does not increase the size of the transmitted message. [1] I think that's what you mean by digest, but maybe you just mean `type` = `magic number`
The problem here is that a digest derived from the schema would just reintroduce the possibility of confusion of identically encoded but semantically distinct types.
Re: Signing data structures the wrong way
#47Since the example was given in proto, I'll suggest a solution in proto: add a message option. extend google.protobuf.MessageOptions { optional uint64 domain_separator = 1234; } message TreeRoot { option (domain_separator) = 4567; ... }
[flagged]
Re: Signing data structures the wrong way
#48Am I missing something or would this be solved by adding a 1 byte `msg` field to the payload?
Re: Signing data structures the wrong way
#49Putting domain separators in the IDL is interesting but you can also avoid the problem by putting the domain separators in-band (e.g. in some kind of "type" field that is always present). Tangentially, depending on what your input and data model look like, canonicalisation takes O(nlogn) time (i.e. the cost of sorting your fields). Here I describe an alternative approach that produces deterministic hashes without a d…
I think a lot of people assume that the "name" of the type, for protos, will be preserved somewhere in the output such that a TreeRoot couldn't be re-used as a KeyRevoke. It makes sense that it isn't - you generally don't want to send that name every time - but it's non-obvious to people with a object-oriented-language background who just think "ah, different types are obviously different types." The serialization co…
I think it's nice to be able to do things like rename nested structs and keep wire compatibility when upgrading two parts of the system at different schedules. Protos are neat. Think like a proto.
(Not saying the signing problem in OP is invalid of course. Just a different problem.)
Re: Signing data structures the wrong way
#50Putting domain separators in the IDL is interesting but you can also avoid the problem by putting the domain separators in-band (e.g. in some kind of "type" field that is always present). Tangentially, depending on what your input and data model look like, canonicalisation takes O(nlogn) time (i.e. the cost of sorting your fields). Here I describe an alternative approach that produces deterministic hashes without a d…
Thats a fun read and a topic I've specifically looked into before and its one of those black holes of terms than cannot be searched. You get so much noise.