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

It’s 255:19AM. Do you know what your validation criteria are?

hdevalence.ca

Post reply on HN
Print view View original

11–20 of 32 posts

Re: It’s 255:19AM. Do you know what your validation criteria are?

#11

Post by nullc »

exabrial wrote: post #9

I'm curious, does ECDSA provide this? Not a crypto expert.

Your question is a bit underspecified... ECDSA by itself isn't an implementable protocol: you also need to specify a curve and an encoding for the values at a minimum and ideally a hash function too.

The common DER encoding used for ECDSA signatures introduces several behaviours similar to the ones being discussed here which differ between implementations. (Or, rather, DER itself doesn't but BER does and what things that implement DER usually implement is some subset of BER and some superset of DER).

For curves with a cofactor similar issues also probably arise there-- I haven't thought much about that since I just try to avoid cofactor generally, because it's a pretty big footgun. :)

ECDSA implemented as Bitcoin does today (post BIP66) with a perfectly strict and completely specified DER encoding-- a near-power-of-2-size cofactorless curve-- and an additional requirement on S being in the lower half of the range doesn't have these issues. ... except to the extent that someone could try to make an implementation copying some off-the-shelf-ecdsa and miss those specific requirements and only be partially compatible.

Re: It’s 255:19AM. Do you know what your validation criteria are?

#12

Post by nullc »

matthewdgreen wrote: post #10
bjornedstrom wrote: post #5

Relevant quote from the Ed25519 paper [1] under the heading "Signature System": "This section specifies the signature system used in this paper, and a generalized signature system EdDSA that can be used with other choices of elliptic curves": > Malleability. We also see no relevance of “malleability” to the standard definition of signature security. For example, if we slightly modified the system then replacing S by…

A general rule is that cryptographers never know what applications’ requirements are, unless we’re also developing those applications. The Ed paper took a very opinionated view on what the requirements should be: out in the real world, it turned out that they were often stronger. This doesn’t mean anyone is “wrong” per se, but it should perhaps be a lesson in humility for people who develop primitives.

At least the paper was extremely clear in that particular respect, often this isn't the case.

Re: It’s 255:19AM. Do you know what your validation criteria are?

#13

Post by srfilipek »

kelnage wrote: post #8

This is very nice work. For those who are interested in academic work about detecting/preventing such attacks, there have been some recent papers that looked at the formal verifying protocol models [1, 2] to (dis)prove the absence of such vulnerabilities. 1. https://eprint.iacr.org/2019/779 2. https://eprint.iacr.org/2020/823

The article discusses interoperability issues; it isn't an attack or vulnerability.

The issue is that implementations will reject valid signatures.

Re: It’s 255:19AM. Do you know what your validation criteria are?

#14

Post by chrisseaton »

3pt14159 wrote: post #3
classified wrote: post #2

I would recommend using a 24-hours clock, not AM/PM 256-hourglasses. There is also the outrageously absurd idea of putting units next to your entry fields so users know to enter metric values instead of furlongs.

Are you being sarcastic? The title is clearly chosen so that it makes the number 25519 in reference to the algorithm.

But what has anything got to do with time here?

Re: It’s 255:19AM. Do you know what your validation criteria are?

#15

Post by V99 »

chrisseaton wrote: post #14
3pt14159 wrote: post #3

Earlier quoted context omitted.

Are you being sarcastic? The title is clearly chosen so that it makes the number 25519 in reference to the algorithm.

But what has anything got to do with time here?

The title is a reference to public service commercials that ran decades ago: https://en.wikipedia.org/wiki/Do_you_know_where_your_childre...

Re: It’s 255:19AM. Do you know what your validation criteria are?

#17

Post by kelnage »

srfilipek wrote: post #13
kelnage wrote: post #8

This is very nice work. For those who are interested in academic work about detecting/preventing such attacks, there have been some recent papers that looked at the formal verifying protocol models [1, 2] to (dis)prove the absence of such vulnerabilities. 1. https://eprint.iacr.org/2019/779 2. https://eprint.iacr.org/2020/823

The article discusses interoperability issues; it isn't an attack or vulnerability. The issue is that implementations will reject valid signatures.

Yeah, sorry, my wording wasn’t clear. I meant that attacks exist based on not utilising appropriate validation criteria (and, for example, libsodium’s more strict criteria do indeed prevent them).

Re: It’s 255:19AM. Do you know what your validation criteria are?

#18

Post by im3w1l »

nullc wrote: post #7
classified wrote: post #2

I would recommend using a 24-hours clock, not AM/PM 256-hourglasses. There is also the outrageously absurd idea of putting units next to your entry fields so users know to enter metric values instead of furlongs.

It's also relevant to the topic because some of the issues its discussing relate to how over full inputs are validated. Do you reduce the 255 mod 24 to decide if the time is acceptable, or do you just reject anything over 23 as unreasonable... or maybe you only reject larger than 99 (because two digits is enough) but from 23 and 99 you reduce mod 24. In many kinds of programs it isn't too critical exactly how you han…

> In consensus systems, however, any difference in behaviour can be a fatal vulnerability.

Another issue can come if you have code like this, and different validations are used.

    if (signature_valid()) {
      // Safe because we already verified signature.
      use_signed_message_or_die();
    }
In practice the check and usage could be very far apart in the code (maybe using the type system to keep track of verified signatures), or even in different programs.

Re: It’s 255:19AM. Do you know what your validation criteria are?

#20

Post by tialaramex »

bjornedstrom wrote: post #5

Relevant quote from the Ed25519 paper [1] under the heading "Signature System": "This section specifies the signature system used in this paper, and a generalized signature system EdDSA that can be used with other choices of elliptic curves": > Malleability. We also see no relevance of “malleability” to the standard definition of signature security. For example, if we slightly modified the system then replacing S by…

Over the past decades it's been clear that we should provide the consumers of a cryptographic system with everything they might reasonable expect, rather than define narrowly what we'll set out to do and then surprise the consumer when they actually needed more than was delivered.

AEAD is a big example of that, delivering integrity protection for symmetric encryption that too many engineers never even realised their application required. Moving from the Merkle–Damgård construction to Sponge construction for hashes is one way to deliver another unspecified requirement - preventing length extension attacks.

Way too often in cryptography when somebody is sure that they don't need a big complicated system with a bunch of features it turns out actually they just didn't understand their full requirements, and as those become clear all the baggage they were pleased to be rid of turns out to have been necessary all along.

Post reply on HN