To add to this, I've played around with implementing many more disk based data structures such as BTree, BTree B+Tree, etc and LSM tree is the easiest to work with, optimize, etc. The write speed also is much greater than the b tree and its varients which I like. I will continue to do research on them all as I normally do :P
You can't, that's true, and in particular you can't get over 184 bits out of it. But that's also true of, for example, PBKDF1, which I think is the algorithm the term "KDF" was invented to describe. And bcrypt is often included in lists of KDFs, for example by OWASP and Wikipedia. Arbitrary-length digests are certainly highly desirable for a KDF, but I don't think they are uncontroversially part of the definition of the term.
For those reviewing the changeset: There are two places where they read a value directly from $POST into an $args array. There is no validation applied, which means an attacker can inject whatever value they wish.
I can't speak for WP Engine devs specifically but for Wordpress customization developers, the ones I've worked with were just absolute amateurs. The people doing this are mostly untrained people hacking together stuff layer upon layer until it kind of worked. Don't even ask about using version control. I don't want to say this applies to every Webdev but it attracts a group of people that aren't too much into IT but want to quickly learn programming to have a job.
This is computing CRC-64, not CRC-32, so there's not really a comparison. But perhaps most importantly, ours works with a variety of polynomials (there are a lot! [1])... we're just using the NVME one, but it's trivially adaptable to most (all?) of them. (The Intel instruction you link to only works with two - CRC32 and CRC32C)
Finally, it's based on Intel's paper [2], so they also believe it's extremely fast. :)
1. More hash functions equals more security (hash encapsulation)
2. The attacker wants to know the content of 'm'
H0(H1(m)) has the security of just H0. Hashes are not made to protect the content of m, but instead made to test the integrity of m. As such, a flaw in H0 will break the security guarantee, no matter how secure H1 is.
Practically, H0(H1(m)) is the same as H0(m), as m is just "some data," and the result of H1 can be seen as "some data".
If your construction is H0(m0) + H1(m1) where m0, m1 are both halves of m, then the overall security is reduced to the weakest hash function. For example, a length extension attack in the weakest hash function breaks the overall integrity of the construction.
> H0(H1(m)) has the security of just H0. Hashes are not made to protect the content of m, but instead made to test the integrity of m. As such, a flaw in H0 will break the security guarantee, no matter how secure H1 is.
But this isn't true for all flaws. For example, even with the collision attacks against SHA-1, I don't think they're even remotely close to enabling a collision for SHA-1(some_other_hash(M)).
Similarly, HMAC-SHA-1 is still considered secure, as it's effectively SHA-1-X(SHA-1-Y(M)), where SHA-1-X and SHA-1-Y are just SHA-1 with different starting states.
So there's some value to be found in nesting hashes.
We are saying the same thing. H0 is SHA-1 in your example.
The strength of an HMAC depends on the strength of the hash function; however, since it uses two derived keys, the outer hash protects the inner hash (using the same hash function), which in turn provides protection against length extension attacks.
The case I was making, is that weakhash(stronghash(m)) has the security of weakhash, no matter how strong stronghash is.
> The case I was making, is that weakhash(stronghash(m)) has the security of weakhash, no matter how strong stronghash is.
I'll have to disagree. There are no known collision attacks against SHA-1(SHA-3(M)), so in the applied case, a combination can be more secure for some properties, even if it isn't in the theoretical case.
Once you change the IV the hash becomes entirely insecure and can be broken in seconds. You just need to overwrite the first IV word with 0, and it's broken. It's a very weak and fragile hash function. They demonstrated it with internal constants K1-K4, but the IV is external, and may be abused as random seed.
The properties I am thinking of are strong and weak collision resistance, there are other relevant properties to hash functions (like every bit being about independent of every other bit, but I care less about those).
> If your construction is H0(m0) + H1(m1)
Here if H0 has a weak collision attack and H1 has a strong collision attack and + is xor or addition the i see how H0(m0) + H1(m1) can be vulnerable.
> H0(H1(m)) has the security of just H0
I believe it has the security of just H1, but my construction was very different; it was H0(H1(m) || H2(m)). (I used + as concatenation, I forgot that it is usually written as ||)
Here you would need strong collision attacks on all three hash functions (including an attack on H0 that is limited to very short messages of a fixed size.
I do not mean H0(H1(m0)+H1(m1)) nor H1(m0)+H(m1) but Reinman(x={0,1000})(H0(m(x)))
Where there are 1000 hashes. So H0 must be broken one thousand times, then it does not matter that some attack exists to reduce the security 1000 times because the attack must be performed 1000 times. You could easily nest these so that F(y)=Reinman(x={0,y})(H0(m(y))) and take G(z)=Reinman(y={1,z})(F(y))
So that G(3) e.g. would produce 6 hashes of strength H0. No hash is taking another hash as a function, but the message itself here provides security - you must not just find a duplicate for one hash, but all 6 simultaneously. I wonder if the increased complexity might easily defeat most attacks on H0.
Pretty interesting solution. At least it removes many of the errors stemming from reading keys over the phone, etc., but it also proclaims to remove the risk of distributing BitLocker keys - but that's precisely what they did - just in barcode form.
The obfuscation might prevent the intern from figuring out what is going on, but there are plenty of barcode-scanning apps for phones that show you the data stored in a barcode.
They didn't distribute the bar codes, they had peoples bring their laptops to IT where the IT staff used the scanner to scan the code from the screen of a machine they themselves controlled.
You're right that the article later on describes it like that but then the concerns about distributing the key or dictating it over the phone don't make sense.
Research deals with theory. Not everything in research is immediately practical. Lots of engineering, tweaking, and testing goes into market-ready products. This announcement is an achievement for science, not a consumer-ready product.
reply