This.... from a bank.... I'm.... WTF?!

morbiuswilters

We thought MD5 was secure until some people broke it and then did a live demonstration at 25C3 to spoof SSL certificates.

It's just a matter of time.

What the fuck are you talking about? MD5 hasn't been considered secure for nearly two decades.

Now, the SHA-2 algos may one day be broken (in fact, I'd bet on it) but that's very different than what we're talking about.

Mole

@morbiuswilters said:

@Mole said:
We thought MD5 was secure until some people broke it and then did a live demonstration at 25C3 to spoof SSL certificates.

It's just a matter of time.

What the fuck are you talking about? MD5 hasn't been considered secure for nearly two decades.

That was just an example. It was broken first by being able to calculate hash collisions, but it took so long it was decided not a security problem. Then it was broken in real time and everyone panicked.

Now, I wonder what would happen if you took two SHA2 hashes of a file, one forwards and one backwards and then XOR'd the results. Would that create more or less entropy in the system? More or less secure?

morbiuswilters

@Mole said:

It was broken first by being able to calculate hash collisions, but it took so long it was decided not a security problem. Then it was broken in real time and everyone panicked.

Hwah? It's been considered insecure for years. The real-time breaking was neat in a "Wow, look how far we've made it" kind of way, but anybody who panicked should not be involved in security decisions.

dhromed

@morbiuswilters said:

Finally, $GAME will run at 60 FPS!

Unless it's minecraft.

God's own Machine cannot run minecraft at 60+fps constantly.

bstorer

@dhromed said:

@morbiuswilters said:
Finally, $GAME will run at 60 FPS!

Unless it's minecraft.

God's own Machine cannot run minecraft at 60+fps constantly.

And high fps is absolutely critical for Minecraft. How would you appreciate the attention to detail without it?

mott555

@dhromed said:

@morbiuswilters said:
Finally, $GAME will run at 60 FPS!

Unless it's minecraft.
God's own Machine cannot run minecraft at 60+fps constantly.

I get a good 300 - 400 fps pretty consistently, and I have a mega texture pack installed.@bstorer said:

And high fps is absolutely critical for Minecraft. How would you appreciate the attention to detail without it?

I find it hard to fight back against creepers without blowing up when I'm getting under 30 fps.

Lorne Kates

@flabdablet said:

In other words, given a sufficiently good hash function with a sufficiently wide output, collisions are absolutely not "to be expected".
Hash collisions are something you worry about if your hash value is going to be used as an array index, not if it's a nice wide crypto-grade fingerprint.

Okay, see, follow me on this. Hashing is bad because:

1) All hashes produce collisions, even a small amount of them.

2) So the number of unique values as a result of hashing (call is H) is always < the number of unique inputs (call it I)

3) Security "experts" reccomend multiple hashings

4) This will just encourage people to use MANY multiple hasings

5) Since, as per #2, H < I, after each hash, there will be fewer and fewer unique hashes, meaning it will be easier and easier to come up with a plaintext value that matches a hash.

6) Eventually, someone will hash so much that H = 1, and any plaintext input will work, and the system will be broken.

Don't fucking use hashes.

dhromed

@mott555 said:

I get a good 300 - 400 fps pretty consistently, and I have a mega texture pack installed.

Hmyes.

I have that blue tweak tool which name eludes me right now, and a 32x texpack. It runs very well, and then BAM 20fps and then BAM back up to "something smooth that I can't estmate so it's probably over 50". No consistency when looking at certain parts of the world.

Also, the in-game fps counter is weirdly inaccurate. Says I got oodles of fps when I'm clearly looking at a stop-motion animation.

sudden thought

Could be the CPU power saver. I've had troube with this before; where minecraft doesn't strain the cpu constantly enough to warrant full multiplier, and the fast switching between high and low power states hurts performance.

error

@Lorne Kates said:

5) Since, as per #2, H < I, after each hash, there will be fewer and fewer unique hashes, meaning it will be easier and easier to come up with a plaintext value that matches a hash.

No, if you're using the same hash algorithm or one of the same length, I = H. Since the input is now a hash from the previous iteration, its length is bounded.

mott555

@dhromed said:

Also, the in-game fps counter is weirdly inaccurate. Says I got oodles of fps when I'm clearly looking at a stop-motion animation.

I've noticed this quite a bit on my laptop which is barely one step up from a good hearty potato. 30 - 40 fps most of the time, but random dips down to single-digits though the in-game fps counter claims a solid 55 - 60 at all times. I know the difference between 30 and 60. I'm not sure the game does.

Now that I think about it, my laptop is one of those NVIDIA Optimus setups with both an NVIDIA GPU and Intel HD Graphics. I wonder if the fps counter is reading from the wrong GPU and showing me my desktop redraw rate instead...I know the game normally uses the NVIDIA one because I forced it to use the Intel once and I only got 2 fps.

flabdablet

@Lorne Kates said:

Okay, see, follow me on this. Hashing is bad because:
1) All hashes produce collisions, even a small amount of them.

No they don't. Some do. Not all.

@Lorne Kates said:

2) So the number of unique values as a result of hashing (call is H) is always < the number of unique inputs (call it I)

No they aren't. I has at least two constraints on it: (1) the number of possible bit patterns acceptable as input and (2) the number of unique inputs it's actually feasible to generate. Arguments based on ignoring constraint (2) lead to erroneous conclusions, which is why software engineering > software philosophy.

It's easy to pick a hash function output width that makes H a completely ridiculous number of orders of magnitude greater than I.

128 bits is about where that truth starts to kick in; 512 bits makes it a copper-bottomed fur-lined ocean-going certainty. The only way you will ever see a collision in a 512 bit hash is if somebody finds a way to engineer one deliberately by discovering and exploiting a weakness in the hash function.

@Lorne Kates said:

3) Security "experts" reccomend multiple hashings
4) This will just encourage people to use MANY multiple hasings

Never seen anybody with respectable crypto credentials recommend multiple successive hashings. At most two, maybe, for key stretching. Multiple parallel hashings is equivalent to generating a single hash with a wider output, and may end up stronger or weaker than using a single hash function to do the same thing depending on the details of the functions involved.

@Lorne Kates said:

5) Since, as per #2, H < I, after each hash, there will be fewer and fewer unique hashes, meaning it will be easier and easier to come up with a plaintext value that matches a hash.

Since your first two points are invalid, so is this conclusion.

@Lorne Kates said:

6) Eventually, someone will hash so much that H = 1, and any plaintext input will work, and the system will be broken.

Yeah, and eventually someone will invent a compression algorithm so good that the Treaty of Westphalia will fit on a DIP switch.

char *lorne_kates_ultimate_hash(char *s) {
    return "";
}

flabdablet

@Mole said:

If you can't turn the hash back into the original data then it's safe to say that collisions will always occur at some moment in time. You might say now that it'll take 10 billion years, but tomorrow, Intel might introduce the 1024-core 3Ghz processor that can do it inside a weekend.

I think you need to sit down in a quiet place for a while and contemplate what a number like 2¹²⁸ actually means.

Mole

Maybe when the "security experts" mean multiple hashes, they mean 4096 bit of hashing for each 1KB of data?

Mole

@flabdablet said:

@Mole said:
If you can't turn the hash back into the original data then it's safe to say that collisions will always occur at some moment in time. You might say now that it'll take 10 billion years, but tomorrow, Intel might introduce the 1024-core 3Ghz processor that can do it inside a weekend.
I think you need to sit down in a quiet place for a while and contemplate what a number like 2¹²⁸ actually means.

It means somewhere between a unquardragintillion and a duoquardragintillion. I don't think there's one for 2¹²⁸ specifically.

flabdablet

@Mole said:

@flabdablet said:
@Mole said:
If you can't turn the hash back into the original data then it's safe to say that collisions will always occur at some moment in time. You might say now that it'll take 10 billion years, but tomorrow, Intel might introduce the 1024-core 3Ghz processor that can do it inside a weekend.
I think you need to sit down in a quiet place for a while and contemplate what a number like 2¹²⁸ actually means.

It means somewhere between a unquardragintillion and a duoquardragintillion. I don't think there's one for 2¹²⁸ specifically.

The place you're sitting in is obviously not quiet enough. Either that or you haven't seen this enough times. If you keep messing about with merely naming things instead of contemplating their nature, you're just not going to get it.

error

@flabdablet said:

It's easy to pick a hash function output width that makes H a completely ridiculous number of orders of magnitude greater than I.

You assume I is finite.

flabdablet

@joe.edwards said:

@flabdablet said:
It's easy to pick a hash function output width that makes H a completely ridiculous number of orders of magnitude greater than I.

You assume I is finite.

Which it clearly is, per constraint (2). Constraint (1), which is the only one that people who continue to believe in the reality of collisions in large strong hash functions seem to think about, is indeed no constraint at all.

Mole

@flabdablet said:

The place you're sitting in is obviously not quiet enough. Either that or you haven't seen this enough times. If you keep messing about with merely naming things instead of contemplating their nature, you're just not going to get it.

OK, a 2 followed by 128 zeroes is a large number and all, but I'm sure there's a way of optimising all those zeroes.

error

@Mole said:

@flabdablet said:
The place you're sitting in is obviously not quiet enough. Either that or you haven't seen this enough times. If you keep messing about with merely naming things instead of contemplating their nature, you're just not going to get it.

OK, a 2 followed by 128 zeroes is a large number and all, but I'm sure there's a way of optimising all those zeroes.

2¹²⁸ ≠ 2(10¹²⁸)

bstorer

@joe.edwards said:

@Mole said:
@flabdablet said:
The place you're sitting in is obviously not quiet enough. Either that or you haven't seen this enough times. If you keep messing about with merely naming things instead of contemplating their nature, you're just not going to get it.

OK, a 2 followed by 128 zeroes is a large number and all, but I'm sure there's a way of optimising all those zeroes.

2¹²⁸ ≠ 2(10¹²⁸)

Obviously not. Clearly 2(10¹²⁸) = 20¹²⁸.

Mole

On another note, how many bits would you need to store a value such as 2¹²⁸

mott555

@Mole said:

On another note, how many bits would you need to store a value such as 2¹²⁸

Um, 128?

PJH

@mott555 said:

@Mole said:
On another note, how many bits would you need to store a value such as 2¹²⁸
Um, 128?

Close. 2² is 4 - needs 3 bits. 2³ is 8 - requires 4 bits. So it follows that you'd need 129 bits.

dhromed

@flabdablet said:

Westphalia

he he he

Ben L.

@mott555 said:

@Mole said:
On another note, how many bits would you need to store a value such as 2¹²⁸
Um, 128?

You'd need at least 129.

dhromed

@mott555 said:

Um, 128?

128 will give you 2^128 - 1, just like 6 digits on your odometer give you 999999 = 10^6 - 1

bstorer

@PJH said:

@mott555 said:
@Mole said:
On another note, how many bits would you need to store a value such as 2¹²⁸
Um, 128?
Close. 2² is 4 - needs 3 bits. 2³ is 8 - requires 4 bits. So it follows that you'd need 129 bits.

I can store it in one. I just set the Value-Is-2¹²⁸ bit to 1, and I'm all set. One of the benefits of using an ECISC (Extremely Complex Instruction Set Computing) chip.

HardwareGeek

@PJH said:

@mott555 said:
@Mole said:
On another note, how many bits would you need to store a value such as 2¹²⁸
Um, 128?
Close. 2² is 4 - needs 3 bits. 2³ is 8 - requires 4 bits. So it follows that you'd need 129 bits.

Assuming an unsigned representation; add one more if you want signed. (I was wondering if this was a troll for off-by-one errors. If so, it succeeded.)

(ETA: It also succeeded in getting many pedantic explanations of the off-by-one error.)

If you only care about storing this number, and don't care about how precisely other numbers are stored, it can be stored much more compactly as a real number. Since it is a power of 2, it can be represented exactly with an arbitrarily small mantissa. If we assume the MSB of the mantissa is always one, we don't even need to store that. So dispense with the mantissa entirely, and only store the exponent. The exponent can be represented in 8 bits (assuming only unsigned exponents). Therefore, we only need 8 bits to store the value of 2¹²⁸, if we interpret the meaning of those 8 bits appropriately.

Ben L.

@HardwareGeek said:

@PJH said:
@mott555 said:
@Mole said:
On another note, how many bits would you need to store a value such as 2¹²⁸
Um, 128?
Close. 2² is 4 - needs 3 bits. 2³ is 8 - requires 4 bits. So it follows that you'd need 129 bits.
Assuming an unsigned representation; add one more if you want signed. (I was wondering if this was a troll for off-by-one errors. If so, it succeeded.)
(ETA: It also succeeded in getting many pedantic explanations of the off-by-one error.)
If you only care about storing this number, and don't care about how precisely other numbers are stored, it can be stored much more compactly as a real number. Since it is a power of 2, it can be represented exactly with an arbitrarily small mantissa. If we assume the MSB of the mantissa is always one, we don't even need to store that. So dispense with the mantissa entirely, and only store the exponent. The exponent can be represented in 8 bits (assuming only unsigned exponents). Therefore, we only need 8 bits to store the value of 2¹²⁸, if we interpret the meaning of those 8 bits appropriately.

I can store 2¹²⁸ in zero bits! Of course, it's the only value my computer can store.

dhromed

@HardwareGeek said:

The exponent can be represented in 8 bits (assuming only unsigned exponents). Therefore, we only need 8 bits to store the value of 2¹²⁸, if we interpret the meaning of those 8 bits appropriately.

That's what bstorer said.

morbiuswilters

@bstorer said:

I can store it in one. I just set the Value-Is-2¹²⁸ bit to 1, and I'm all set. One of the benefits of using an ECISC (Extremely Complex Instruction Set Computing) chip.

I can store it in zero bits by using an OSISC (Overly-Simplified Instruction Set Computing) chip. Every integer defaults to 2^128 unless otherwise stated.

morbiuswilters

@Ben L. said:

I can store 2¹²⁸ in zero bits! Of course, it's the only value my computer can store.

You bastard.

error

@morbiuswilters said:

@bstorer said:
I can store it in one. I just set the Value-Is-2¹²⁸ bit to 1, and I'm all set. One of the benefits of using an ECISC (Extremely Complex Instruction Set Computing) chip.

I can store it in zero bits by using an OSISC (Overly-Simplified Instruction Set Computing) chip. Every integer defaults to 2^128 unless otherwise stated.

Ah, yes. So, for example, 5 can be represented as (2¹²⁸÷2¹²⁸+2¹²⁸÷2¹²⁸)²+2¹²⁸÷2¹²⁸