So another lesson had been relearned from asn.1. I'm proud of working in this industry again! Next we will figure out to always put versions into the data too
Signing data structures the wrong way
11–20 of 59 posts
Re: Signing data structures the wrong way
#12along the same lines, did you know that you can get an authenticated email that the listed sender never sent to you? If the third party can get a server to send it to themselves (for example Google forms will send them an email with the contents that they want) they can then forward it to you while spoofing the from: field as Google.com in this example, and it will appear in your inbox from the "sender" (Google.com) and appear as fully authenticated - even though Google never actually sent you that.
This is another example where you would think that "who it's for" is something the sender would sign but nope!
Re: Signing data structures the wrong way
#13So another lesson had been relearned from asn.1. I'm proud of working in this industry again! Next we will figure out to always put versions into the data too
That was my first thought as well.
Re: Signing data structures the wrong way
#14This article claims that these are somewhat open questions, but they're not and have not been for a long time. #1 You sign a blob and you don't touch it before verifying the signature (aka "The Cryptographic Doom Principle") #2 Signatures are bound to a context which is _not_ transmitted but used for deriving the key or mixed into the MAC or what have you. This is called the Horton principle. It ensures that signer/v…
The article proposes a way to agree on context out of band and enforce it with idl. This seems to be an implementation of the principle you mention
Re: Signing data structures the wrong way
#15[deleted]
Re: Signing data structures the wrong way
#16Putting 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…
Multiset hashing is not related to the domain separation problem, but it is related to the broader "signing data structures" problem.
(I realise my comment reads a bit unclearly, it's basically two separate comments, split after the first paragraph)
Re: Signing data structures the wrong way
#17This is a nice explanation of an obvious idea. Both domain separation, and putting the domain signifier into the IDL are fine, but not novel.
Crypto is hard. Do it right. Get help from your tools. 'Nuff said.
Jeeze, I'm getting too old for this crap.
Re: Signing data structures the wrong way
#18Earlier quoted context omitted.
No, I'm pretty sure they are saying you need to transmit it
No, they propose just concatenating it with the data received from the network > it makes a concatenation of the domain separator (@0x92880d38b74de9fb) and the serialization of the object, and then feeds the byte stream into the signing primitive. Similarly, verification of an object verifies this same reconstructed concatenation against the supplied signature. > Note that the domain separator does not appear in the…
Oh, it's just in the hash input. So if you don't use the right ID when you check the hash, it fails.
Re: Signing data structures the wrong way
#19Earlier quoted context omitted.
Maybe I'm misunderstanding the article but I'm fairly sure the magic number is not transmitted. It's used exactly as you say: a shared context used as input for the signature that is not transmitted.
No, I'm pretty sure they are saying you need to transmit it
It is definitely not transmitted.
Domain separation happens in the input to the hash function, not on the wire. Because what arrives off the wire is UNTRUSTED input.
Re: Signing data structures the wrong way
#20So, isn't this a rather longwinded way to say that a signature only extends to the scope of the message it contains?
It doesn't matter if I sign the word "yes", if you don't know what question is being asked. The signature needs to included the necessary context for the signature to be meaningful.
Lots of ways of doing that, and you definitely need to be thoughtful about redundant data and storage overhead, but the concept isn't tricky.