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

21–30 of 32 posts

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

#21

Post by exabrial »

nullc wrote: post #11
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…

Argh. The more I ask the less I know

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

#22

Post by LeonM »

Ed25519 curves are currently being adopted for DKIM in RFC8463 [0]. I I wrote an article about this [1], where I concluded that Ed25519 is an improvement for DKIM over RSA (smaller keys, deprecation of SHA1).

However, this finding may have big impact on the adoption rate of Ed25519 for DKIM. Specifically for DKIM validators (MTAs).

MTAs are already amongst the worst offenders when it comes to not adhering to the standards. The DKIM canonicalisation scheme [2] is already hard enough to implement on it's own, now with this finding we might get even more false positives and negatives in DKIM validation.

Let's hope that the finding will encourage library maintainers to come to a consensus on how to validate Ed25519. And also hope that MTA developers will not try to roll their own...

[0] https://tools.ietf.org/html/rfc8463 [1] https://www.mailhardener.com/kb/how-to-use-dkim-with-ed25519 [2] https://tools.ietf.org/html/rfc6376#section-3.4

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

#23

Post by GoblinSlayer »

LeonM wrote: post #22

Ed25519 curves are currently being adopted for DKIM in RFC8463 [0]. I I wrote an article about this [1], where I concluded that Ed25519 is an improvement for DKIM over RSA (smaller keys, deprecation of SHA1). However, this finding may have big impact on the adoption rate of Ed25519 for DKIM. Specifically for DKIM validators (MTAs). MTAs are already amongst the worst offenders when it comes to not adhering to the stan…

The author's concern is an attack on decentralized consensus process, which isn't a problem for DKIM.

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

#24

Post by fanf2 »

LeonM wrote: post #22

Ed25519 curves are currently being adopted for DKIM in RFC8463 [0]. I I wrote an article about this [1], where I concluded that Ed25519 is an improvement for DKIM over RSA (smaller keys, deprecation of SHA1). However, this finding may have big impact on the adoption rate of Ed25519 for DKIM. Specifically for DKIM validators (MTAs). MTAs are already amongst the worst offenders when it comes to not adhering to the stan…

If I understand the article correctly this isn't a problem for uses of Ed25519 in systems like DKIM or DNSSEC.

These Ed25519 interop problems only arise with maliciously crafted keys and nonces. This is a problem for consensus systems (like Zcash in the article) because the signature is recorded and needs to be verified by many parties, and if a malicious signature it tickles an interop bug it can maybe (handwave) force third parties to treat the blockchain as invalid, or something like that. But in the context of DKIM if a sender generates a signature that a recipient can't validate, by using buggy key generation code that produces small cofactors or noncanonical encodings, only the sender suffers pain.

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

#26

Post by formerly_proven »

Joker_vD wrote: post #6
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…

> it was never a design goal of Ed25519 to begin with to strictly define the set of valid (and invalid) signatures For a popular enough protocol, if there is an underspecified thing then there will be two implementations that implement that thing differently, and if possible, incompatibly. And I am talking about correctly programmed and compliant implementations, never mind the buggy and/or deliberately non-compliant…

> That's why the designer should not leave the implementers any rope whatsoever to strangle themselves, especially in cryptography.

5 bits of choice is a lot of rope to auto-asphyxiate oneself in cryptography.

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

#27

Post by hdevalence »

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.

In this case, simply fixing the problem would have taken the same or less work than writing the quoted paragraph.

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

#28

Post by tptacek »

LeonM wrote: post #22

Ed25519 curves are currently being adopted for DKIM in RFC8463 [0]. I I wrote an article about this [1], where I concluded that Ed25519 is an improvement for DKIM over RSA (smaller keys, deprecation of SHA1). However, this finding may have big impact on the adoption rate of Ed25519 for DKIM. Specifically for DKIM validators (MTAs). MTAs are already amongst the worst offenders when it comes to not adhering to the stan…

For what it's worth, Ed25519 DNSSEC has negligible deployment. The overwhelming majority of the DNSSEC installed base is RSA, and "elliptic curve" in DNSSEC generally means ECDSA.

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

#29

Post by [deleted] »

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

[deleted]

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

#30

Post by laksdjfkasljdf »

kelnage wrote: post #17
srfilipek wrote: post #13

Earlier quoted context omitted.

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

Which attack(s) would that be?
Post reply on HN