Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Signing data structures the wrong way

blog.foks.pub

Post reply on HN
Print view View original

51–59 of 59 posts

Re: Signing data structures the wrong way

#51

Post by Someone »

TLDR: the idea is

- to have a convention to, instead of signing “payloads, to always sign “type identifier + payload”, to prevent adversaries from reusing your signature to sign the same payload, interpreted as a different type.

- use 64-bit type identifiers

- put the identifiers in the IDL (may need augmenting IDL to allow that)

#1 makes sense to me; #3 also makes sense, as that’s the place where people will have to look to learn about your types.

#2, I think, is up for discussion. These could be longer, Java-like strings “com.example.Foo”, or whatever.

I think some people also may disagree with the argument that putting type identifiers inside the payload makes messages too large, but I don’t have enough experience on that to make a judgment.

Re: Signing data structures the wrong way

#52

Post by i386 »

socketcluster wrote: post #45

The 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 inferi…

> 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.

If strict typing and versioning are useless to you, sure.

Re: Signing data structures the wrong way

#53

Post by maxtaco »

hrmtst93837 wrote: post #47
tantalor wrote: post #3

Since 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]

Bingo!

Re: Signing data structures the wrong way

#54

Post by i386 »

efitz wrote: post #37

When my data structures are messages to be sent over a network, I always start with msgId and msgLen, both fixed width fields. This solves the message differentiation problem explicitly, makes security and memory management easier, and reduces routing to: switch(msg.msgId): …

switch on version, then messageId…

Re: Signing data structures the wrong way

#55

Post by tantalor »

hrmtst93837 wrote: post #47
tantalor wrote: post #3

Since 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]

Er, it's part of the spec. You're talking about a non-compliant implementation.

Do you know of any impls that don't support message options?

Re: Signing data structures the wrong way

#56

Post by thunderfork »

i386 wrote: post #52
socketcluster wrote: post #45

The 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 inferi…

> 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. If strict typing and versioning are useless to you, sure.

While protobuf comes with the strict parser built in, it's certainly possible to work with JSON in such a way that it is effectively strictly typed and versioned. These factors aren't really a "key difference" between the two formats, so much as an ergonomic one, imo

Re: Signing data structures the wrong way

#57

Post by Muromec »

maxtaco wrote: post #21
Muromec wrote: post #11

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

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…

OIDs have to be unique just enough to not fall into the wrong parsing/validating path in the same system, which isn't that hard.

>Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Prior to version 1.3.0, RSA PKCS#1 v1.5 signature verification code is lenient in checking the digest algorithm structure

That's on brand for the javascript world, yes.

With asn1 being a can of worms, at least it's a can of worms with a reputation, unlike this nice magic trick.

Disclaimer: there exists a PR filled under my name into an asn.1 parser that fixes a bug, which is not merged since October 2022.

Re: Signing data structures the wrong way

#58

Post by tennysont »

HanyouHottie wrote: post #36
tennysont wrote: post #26

Earlier quoted context omitted.

I asked about this on the PGP mailing list at one point, and I think I was told that the best solution is to start emails with "Hi ," which seems like a funny low-tech solution to a (sad) problem.

The solution to this problem without needing to modify your message is to use a protocol that will sign, then encrypt, then sign again. See section 5 here [1] or section 15 here [2]. [1] https://theworld.com/~dtd/sign_encrypt/sign_encrypt7.html [2] https://computerresearch.org/index.php/computer/article/view...

> without needing to modify your message

Careful. I argue this is even worse. In this convention, you need to change the behavior of others. If I send a message to Alice with contents "Hey, I can't meet today" using your sign-encrypt-sign scheme, then Alice can take the inner most layer and use it to impersonate me. Alice can send "Hey, I can't meet today" to Bob at any time. I must rely on Bob demanding proof that he was, in fact, the intended recipient.

From the first link:

> Note though that an effective security standard should require not only that the author must provide one of these five proofs, but also that the recipient must demand some such proof as well.

If your convention was upgraded into a protocol with automatic verification, then that would be different.

Re: Signing data structures the wrong way

#59

Post by socketcluster »

thunderfork wrote: post #56
i386 wrote: post #52

Earlier quoted context omitted.

> 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. If strict typing and versioning are useless to you, sure.

While protobuf comes with the strict parser built in, it's certainly possible to work with JSON in such a way that it is effectively strictly typed and versioned. These factors aren't really a "key difference" between the two formats, so much as an ergonomic one, imo

Yep. I prefer handling the versioning and validation separately of the parsing. You need to define your schema regardless, then untrusted data from clients must be validated against it. I tend to prefer separation of concerns.
Post reply on HN