4 ms·

Wishy washy, hand wavy, security mumble jumble: > This operation is repeated some number of times until enough work has been done, and then output is extracte

Wishy washy, hand wavy, security mumble jumble: > This operation is repeated some number of times until enough work has been done, and then output is extracted. It’s reasonable to set the number of rounds to be be double the number of blocks stored in bulk memory. It might be okay to go far lower, but that feels sketchy. In particular, going lower might result in custom hardware being able to effectively pipeline the next block being uninitialized (which might be able to produce a small speedup on a general CPU anyway, further research needed). "Some number of times", "reasonable", "feels sketchy", "further research needed"... > There’s also an encryption function used, probably AES128... "Probably AES128"... If there's one thing that you shouldn't tolerate in security, is relying on your feelings about mathematics. You can DO the math, your feelings on what the result might or might not be are not very interesting. The scrypt paper does all the research and math that this article doesn't do. It even includes dollar cost estimates for breaking passwords hashed with various algorithms. Yes, the scrypt algorithm itself already does what you need. The paper is highly recommended for developers who ever touch passwords. http://www.tarsnap.com/scrypt.html http://www.tarsnap.com/scrypt.html I also consider PBKDF2 acceptable for general password hashing.

sarciszewski 12y ago
PBKDF2, bcrypt, and scrypt are the three that most people find acceptable. This blog post isn't meant to be an in-depth research paper, its tone is more, "hey, I have a neat idea, what does the community think?"
- dragontamer 12y ago
  PBKDF2, BCrypt, and SCrypt were also "Hey, I have a neat idea. What does the community think?" Just some people are more precise at writing, and offer better mathematics than other people.
  - sarciszewski 12y ago
    Scrypt also came with an academic paper in PDF format. Maybe one will follow when the ideas are more solid.
    - dragontamer 12y ago
      I don't have time to even follow well thought academic ideas. Why should I be bothered trying to develop ideas of other people who don't put forward even a little bit of effort? The concept is similar to SCrypt. He wants to utilize a memory-hard problem to make the difficulty of creating ASICs more difficult. However, this blog post has no ideas on how VLSI circuits work, nor any crypto calculations, nor any math or proofs that describe his thoughts. He has a supposition: that using maybe AES (or any block cipher) as a random-number-generator, he can randomly traverse memory to increase the difficulty of hashing. (I'm assuming he's just using any ol' block cipher for this process). He leaves a component of the calculation in one memory block to keep it "inside the cache", presumably to keep it working quickly on modern CPUs. Maybe. I dunno. He has no example code, which makes this sort of thing _very_ hard to discuss. I don't even know if I'm reading his post correctly. But assuming this is how he's doing it (and mind you, I really don't know what he's talking about because he's so imprecise), my $0.02 of "serious" criticism is that its not obvious that these calculations cannot be pipelined and simplified in an ASIC or FPGA... at least any more than SCrypt (or BCrypt) was. And remember, SCrypt has ASICs coming out of the pipeline, and also ended up being much much faster on R9 290x GPUs than your standard CPUs. Honestly, the X11 proposals from the alt-coin community are better researched and more precise than what this blog-post proposes. This proposal here is so obscure and wishy-washy that I can't even discuss its merits.
      - sarciszewski 12y ago
        > I don't have time to even follow well thought academic ideas. Why should I be bothered trying to develop ideas of other people who don't put forward even a little bit of effort? You shouldn't and I'm not saying you should. I'm suggesting everyone is taking this more seriously than it needs to be. "Might be a novel idea, here's some things to consider, needs work," is appropriate. But this idea is clearly stuck in rough draft hell and needs some serious fleshing out before everyone pulls out their magnifying glasses. Going balls-to-the-wall with scrutiny and criticism before it's warranted does nothing constructive and only discourages people from tinkering. Bad for the community, etc.
  - mikeash 12y ago
    "Offer better mathematics" is the whole point, don't you think? This is ultimately math. If the math is lacking in a proposed mathematical construct then what makes it worthwhile?

sarciszewski 12y ago

PBKDF2, bcrypt, and scrypt are the three that most people find acceptable. This blog post isn't meant to be an in-depth research paper, its tone is more, "hey, I have a neat idea, what does the community think?"

dragontamer 12y ago
PBKDF2, BCrypt, and SCrypt were also "Hey, I have a neat idea. What does the community think?" Just some people are more precise at writing, and offer better mathematics than other people.
- sarciszewski 12y ago
  Scrypt also came with an academic paper in PDF format. Maybe one will follow when the ideas are more solid.
  - dragontamer 12y ago
    I don't have time to even follow well thought academic ideas. Why should I be bothered trying to develop ideas of other people who don't put forward even a little bit of effort? The concept is similar to SCrypt. He wants to utilize a memory-hard problem to make the difficulty of creating ASICs more difficult. However, this blog post has no ideas on how VLSI circuits work, nor any crypto calculations, nor any math or proofs that describe his thoughts. He has a supposition: that using maybe AES (or any block cipher) as a random-number-generator, he can randomly traverse memory to increase the difficulty of hashing. (I'm assuming he's just using any ol' block cipher for this process). He leaves a component of the calculation in one memory block to keep it "inside the cache", presumably to keep it working quickly on modern CPUs. Maybe. I dunno. He has no example code, which makes this sort of thing _very_ hard to discuss. I don't even know if I'm reading his post correctly. But assuming this is how he's doing it (and mind you, I really don't know what he's talking about because he's so imprecise), my $0.02 of "serious" criticism is that its not obvious that these calculations cannot be pipelined and simplified in an ASIC or FPGA... at least any more than SCrypt (or BCrypt) was. And remember, SCrypt has ASICs coming out of the pipeline, and also ended up being much much faster on R9 290x GPUs than your standard CPUs. Honestly, the X11 proposals from the alt-coin community are better researched and more precise than what this blog-post proposes. This proposal here is so obscure and wishy-washy that I can't even discuss its merits.
    - sarciszewski 12y ago
      > I don't have time to even follow well thought academic ideas. Why should I be bothered trying to develop ideas of other people who don't put forward even a little bit of effort? You shouldn't and I'm not saying you should. I'm suggesting everyone is taking this more seriously than it needs to be. "Might be a novel idea, here's some things to consider, needs work," is appropriate. But this idea is clearly stuck in rough draft hell and needs some serious fleshing out before everyone pulls out their magnifying glasses. Going balls-to-the-wall with scrutiny and criticism before it's warranted does nothing constructive and only discourages people from tinkering. Bad for the community, etc.
- mikeash 12y ago
  "Offer better mathematics" is the whole point, don't you think? This is ultimately math. If the math is lacking in a proposed mathematical construct then what makes it worthwhile?