6 ms·

I‘m wondering if they could avoid yet another breaking protocol change if SHA256 proves to be insecure (at some point in the future) if they made use of Multifo

I‘m wondering if they could avoid yet another breaking protocol change if SHA256 proves to be insecure (at some point in the future) if they made use of Multiformats [0]. At least IPFS went this way (Multiformats grew out of the IPFS development). [0] https://multiformats.io/ https://multiformats.io/

alex_duf 5y ago
>if SHA256 proves to be insecure slight pedantism here, but "when" not "if"
- marcan_42 5y ago
  That's not a given. As far as I know, there is no proof of the security or lack thereof of this kind of function. Increases in computing power alone can't render SHA256 insecure; that can be proven by thermodynamic/size-of-the-universe arguments. You need an actual cryptographic weakness.
  - newby 5y ago
    > Increases in computing power alone can't render SHA256 insecure; that can be proven by thermodynamic/size-of-the-universe arguments. Fascinating. Could you please recommend a source where a curious layman could learn more about this?
    - marcan_42 5y ago
      I posted a link and some further analysis in this comment: https://news.ycombinator.com/item?id=29883965 https://news.ycombinator.com/item?id=29883965
- hannob 5y ago
  There's no indication whatsoever of this happening. In the time since SHA1 came under attack, a lot more research has happened on hash function security. If this has shown anything, it's that SHA256 is more secure than people used to think. People seem to have this widely believed idea that "all crypto will be broken eventually". But in pretty much all cases you can trace back that broken crypto was known to be weak for a long time. SHA256 is not known to be weak (with the slight caveat that it doesn't protect against length extension attacks, but this is a known property that matters only in very rare circumstances).
hannob 5y ago
You're proposing to add extra complexity for some hypothetical scenario that is unlikely to happen. That's a bad tradeoff.
- elcomet 5y ago
  unlikely ? all methods are broken eventualy when compute becomes faster
  - hsbauauvhabzb 5y ago
    All current methods. Isn’t sha256 an order of magnitude more complex than sha1? It’s not like cryptographers can’t learn from their mistakes.
    - deleted 5y ago
      [deleted]
  - hannob 5y ago
    Computers can only become faster within the limits of what humans are able to build and what physics allows. You're not gonna break SHA256 with faster computers.
    - seanw444 5y ago
      I swear there was a pertinent article link that goes through how it's physically impossible to construct a computing device fast enough to break SHA-256, even at the most fundamental scale.
  - marcan_42 5y ago
    This is not true. Modern cryptography is not breakable via brute force any more, nor will it ever be. You can prove that the amount of energy required assuming a thermodynamically ideal computer is more than will ever be available in our galaxy, with classical computing. Breaks of symmetric crypto or hashes that are practical require an actual cryptographic weakness, whose existence is not a given. Then there's quantum computing, but that also doesn't break symmetric crypto outright, it just makes it weaker. I'm not sure if anyone has run the math, but we'd probably still be talking galaxy sized quantum computers to get anywhere.
noodlesUK 5y ago
Generally speaking this is called “cryptographic agility” and the security community has decided that it’s an antipattern. The alternative is to have a specified suite of security mechanisms pinned to each version. You can still have backwards compatibility, but it helps avoid downgrade attacks.
- cyphar 5y ago
  Multiformats is not really cryptographic agility, it's just adding a small tag that indicates what type of data something is (what kind of encoding, what kind of hash, what kind of binary payload, etc). The benefit is that the tags are standardised rather than being tied to a protocol version or some other out-of-band information. Whether or not you start making negotiation decisions based on that header is what determines whether you have cryptographic agility. I'm also not sure I'd say the security community as a whole feels that cryptographic agility is an anti-pattern, there are plenty of vocal voices on all sides of that argument. I personally agree that you gain very little from cryptographic agility but have to pay a fair amount, but I don't think it's as settled as you make it out to be.
  - noodlesUK 5y ago
    > I'm also not sure I'd say the security community as a whole feels that cryptographic agility is an anti-pattern, there are plenty of vocal voices on all sides of that argument. I personally agree that you gain very little from cryptographic agility but have to pay a fair amount, but I don't think it's as settled as you make it out to be. I totally agree with this assessment, and rereading my comment, I say that as though it’s a lot more settled than it is. I think it’s probably harmless to tag those sorts of bits of data, but also JWT has shown us that having that metadata in band does lead to people using it for those kinds of decisions whether they’re supposed to or not.
Stevvo 5y ago
SHA1 collision was never much of a reason to change it in the first place; there is no practical attack that arises from it.
- EVa5I7bHFq9mnYK 5y ago
  1) Take a popular game torrent 2) add crypto mining code 3) pad it so the SHA1 stays the same 4) seed it, the magnet links will pick up your version 5) profit!
  - daniel-cussen 5y ago
    Between 1 and 2, remove the crypto mining code that came with it.
  - ttybird2 5y ago
    Except that this is not how collision attacks work.
  - GoblinSlayer 5y ago
    That's a preimage attack. For example, the entire bitcoin network today needs something on the order of a trillion years for a preimage attack on MD5, multiply by another trillion for a SHA1 preimage attack.
twic 5y ago
The magnet URL format is at least using multihash: > Like the urn:btih: prefix for v1 SHA-1 info-hashes, there’s a new prefix, urn:btmh: for full v2 SHA0256 info hashes. For example, a magnet link thus looks like this: > magnet:?xt=urn:btmh:<tagged-info-hash>&dn=<name>&tr=<tracker-url> > The info-hash with the btmh prefix is the v2 info-hash in multi-hash format encoded in hexadecimal.

alex_duf 5y ago

>if SHA256 proves to be insecure slight pedantism here, but "when" not "if"

marcan_42 5y ago
That's not a given. As far as I know, there is no proof of the security or lack thereof of this kind of function. Increases in computing power alone can't render SHA256 insecure; that can be proven by thermodynamic/size-of-the-universe arguments. You need an actual cryptographic weakness.
- newby 5y ago
  > Increases in computing power alone can't render SHA256 insecure; that can be proven by thermodynamic/size-of-the-universe arguments. Fascinating. Could you please recommend a source where a curious layman could learn more about this?
  - marcan_42 5y ago
    I posted a link and some further analysis in this comment: https://news.ycombinator.com/item?id=29883965 https://news.ycombinator.com/item?id=29883965
hannob 5y ago
There's no indication whatsoever of this happening. In the time since SHA1 came under attack, a lot more research has happened on hash function security. If this has shown anything, it's that SHA256 is more secure than people used to think. People seem to have this widely believed idea that "all crypto will be broken eventually". But in pretty much all cases you can trace back that broken crypto was known to be weak for a long time. SHA256 is not known to be weak (with the slight caveat that it doesn't protect against length extension attacks, but this is a known property that matters only in very rare circumstances).

hannob 5y ago

You're proposing to add extra complexity for some hypothetical scenario that is unlikely to happen. That's a bad tradeoff.

elcomet 5y ago
unlikely ? all methods are broken eventualy when compute becomes faster
- hsbauauvhabzb 5y ago
  All current methods. Isn’t sha256 an order of magnitude more complex than sha1? It’s not like cryptographers can’t learn from their mistakes.
  - deleted 5y ago
    [deleted]
- hannob 5y ago
  Computers can only become faster within the limits of what humans are able to build and what physics allows. You're not gonna break SHA256 with faster computers.
  - seanw444 5y ago
    I swear there was a pertinent article link that goes through how it's physically impossible to construct a computing device fast enough to break SHA-256, even at the most fundamental scale.
- marcan_42 5y ago
  This is not true. Modern cryptography is not breakable via brute force any more, nor will it ever be. You can prove that the amount of energy required assuming a thermodynamically ideal computer is more than will ever be available in our galaxy, with classical computing. Breaks of symmetric crypto or hashes that are practical require an actual cryptographic weakness, whose existence is not a given. Then there's quantum computing, but that also doesn't break symmetric crypto outright, it just makes it weaker. I'm not sure if anyone has run the math, but we'd probably still be talking galaxy sized quantum computers to get anywhere.

noodlesUK 5y ago

Generally speaking this is called “cryptographic agility” and the security community has decided that it’s an antipattern. The alternative is to have a specified suite of security mechanisms pinned to each version. You can still have backwards compatibility, but it helps avoid downgrade attacks.

cyphar 5y ago
Multiformats is not really cryptographic agility, it's just adding a small tag that indicates what type of data something is (what kind of encoding, what kind of hash, what kind of binary payload, etc). The benefit is that the tags are standardised rather than being tied to a protocol version or some other out-of-band information. Whether or not you start making negotiation decisions based on that header is what determines whether you have cryptographic agility. I'm also not sure I'd say the security community as a whole feels that cryptographic agility is an anti-pattern, there are plenty of vocal voices on all sides of that argument. I personally agree that you gain very little from cryptographic agility but have to pay a fair amount, but I don't think it's as settled as you make it out to be.
- noodlesUK 5y ago
  > I'm also not sure I'd say the security community as a whole feels that cryptographic agility is an anti-pattern, there are plenty of vocal voices on all sides of that argument. I personally agree that you gain very little from cryptographic agility but have to pay a fair amount, but I don't think it's as settled as you make it out to be. I totally agree with this assessment, and rereading my comment, I say that as though it’s a lot more settled than it is. I think it’s probably harmless to tag those sorts of bits of data, but also JWT has shown us that having that metadata in band does lead to people using it for those kinds of decisions whether they’re supposed to or not.

Stevvo 5y ago

SHA1 collision was never much of a reason to change it in the first place; there is no practical attack that arises from it.

EVa5I7bHFq9mnYK 5y ago
1) Take a popular game torrent 2) add crypto mining code 3) pad it so the SHA1 stays the same 4) seed it, the magnet links will pick up your version 5) profit!
- daniel-cussen 5y ago
  Between 1 and 2, remove the crypto mining code that came with it.
- ttybird2 5y ago
  Except that this is not how collision attacks work.
- GoblinSlayer 5y ago
  That's a preimage attack. For example, the entire bitcoin network today needs something on the order of a trillion years for a preimage attack on MD5, multiply by another trillion for a SHA1 preimage attack.

twic 5y ago

The magnet URL format is at least using multihash: > Like the urn:btih: prefix for v1 SHA-1 info-hashes, there’s a new prefix, urn:btmh: for full v2 SHA0256 info hashes. For example, a magnet link thus looks like this: > magnet:?xt=urn:btmh:<tagged-info-hash>&dn=<name>&tr=<tracker-url> > The info-hash with the btmh prefix is the v2 info-hash in multi-hash format encoded in hexadecimal.