[metalrain]

Visualized like this it feels like security through obscurity, but there must be reason for this.

I did wonder why initialization is like:

1. Initialize hash value h0 to h7: first 32 bits of the fractional parts of the square roots of the first 8 primes 2..19).

2. Initialize array of K constants: first 32 bits of the fractional parts of the cube roots of the first 64 primes 2..311

[manceraio]

https://news.ycombinator.com/item?id=23166713

It seems like a "nothing up my sleeve" way to initialize the variables.

[orangepenguin]

It's not security through obscurity. In fact, it's the very opposite. You can see the process exactly. The reason this is secure is because the process itself doesn't work backwards. You can create a hash using this algorithm, but you'll never reverse that hash back into the original text.

[picture]

I'm also wondering, how does this prevent preimaging attacks (or whatever they're called)? That is to say, what's stopping people from reliably producing output based on input?

[skinkestek]

> I'm also wondering, how does this prevent preimaging attacks (or whatever they're called)?

First, see the Wikipedia entry about preimage attacks.

Second, I am not a cryptographer but I think in practice there is a couple of things to be aware of:

- make sure slightly different inputs have wildly different outputs

- make sure no parts of the input survives

- practically speaking there are an unlimited number of inputs that map to most (all? I'm not sure how uniform the distribution of sha256 is) output (since input is unlimited and output is a short string.

- the classic preimage attack, rainbow tables, works because 1.) inputs, i.e. passwords, are often short and predictable

- in ancient times password systems didn't use salts

> That is to say, what's stopping people from reliably producing output based on input?

I assume this should be the other way around, which is what I have tried to explain above.

Again, read the Wikipedia page.

[bsedlm]

from what I've seen, there's a lot of "obscurity" to this; there are many seemingly arbitrary choices all over the place.

In the end most encryption algorithms boil down to doing 'random' (arbitrary, hard to justify why) things to data and then undoing them exactly in order to decrypt.

the math is all incredibly abstract but not all that complex, the high level of abstraction does make it quite difficult to grasp.

What's worse is that I fear there are incentives (mostly political/security interests) to keep the field small and to keep many people far away from this very practical use for all these beautiful, elegant, simple (but extremely abstract) mathematics (refering to the entire cryptography field).

[dragontamer]

> What's worse is that I fear there are incentives (mostly political/security interests) to keep the field small and to keep many people far away from this very practical use for all these beautiful, elegant, simple (but extremely abstract) mathematics (refering to the entire cryptography field).

I mean, everything you want to learn about crypto is available online, in libraries, in textbooks. Including differential cryptoanalysis, the theory behind these mathematical forms (Galois Field makes things _EASIER_, not harder actually. That's why CRC-checks and Reed-Solomon codes were based off of Galois Fields, and AES being based on GF(2^8) is to take advantage of those same properties).

--------

What has happened is that the "old generation" of programmers is dying out / retiring. And they aren't passing on their knowledge to the new generation. The "old generation" of programmers were high-math, abstract algebra and more, while "new generation" programmers just never bothered to learn this stuff.

[ltfey]

What has happened is that the "old generation" of programmers is dying out / retiring. And they aren't passing on their knowledge to the new generation. The "old generation" of programmers were high-math, abstract algebra and more, while "new generation" programmers just never bothered to learn this stuff.

There may be some survivorship bias here. Even in the 1990s, business-grade programmers (the ones who, quite frankly, aren't inclined to learn difficult subjects) either went into management or did something else, although the timeframe and ageism are more aggressive these days due to the infantilization and humiliation (e.g., Agile Scrum) that engineers face today.

Research-grade programmers were the minority, even then, although this problem is a lot worse today due to the near nonexistence of R&D jobs.

[aaronmdjones]

Not all decryption is doing exactly the same things in reverse. For example, with CTR mode (and thus GCM mode, which is CTR plus GMAC), you call the /encryption/ routine regardless of whether you're encrypting or decrypting data. This means in an embedded environment you can save die space because your program doesn't need the e.g. AES decryption routines too.

https://upload.wikimedia.org/wikipedia/commons/4/4d/CTR_encr...

https://upload.wikimedia.org/wikipedia/commons/3/3c/CTR_decr...

(Note the bold text)

[bsedlm]

I mean it in the sense that they undo the 'noise' added to (or reverse the scrambling of) the initial input .

even if they do it in a different way.

[jjeaff]

I doubt there is any concerted effort to keep the field small. That would be like saying tech companies don't want people learning how to code so that they can maintain an advantage.

If anything, governments and companies are encouraging people to study cryptography so that they are able to hire more experts in the future.

Now, once you get gatekeeper organizations and special licensing organizations like contractors licensing or beauticians licensing, those are examples of groups trying to keep the pool of experts small.

[smaudet]

> What's worse is that I fear there are incentives (mostly political/security interests)

Nah its mostly just a mix of laziness, rigor, and salesfolk.

Most people don't want nor can properly design a hash algorithm (which works well). Public ones like SHA have received so much scrutiny, they are extremely well vetted...and then there's the mostly valid attitude of "never roll your own crypto" - Don't, not in production or anything that could become production. Unless you are a group of highly skilled cross domain career cryptographers/mathematicians...

Which leads to the last bit, people build whole business out of selling "security products" out of publically available crypto, then make the argument you shouldn't do it yourself, buy theirs. Which sometimes makes sense - often it is a shill/marketing ploy. Rarely do these products provide much on top of the core freely available code...and they probably shouldn't, or else there is probably untrustworthy nonsense inside.

So yeah, don't assume malice where first incompetence is possible.

[tptacek]

This seems pretty silly, as there is extensive (one might say tedious) detail on why the decisions in a hash function or block cipher were made; your challenge is that you have to do a literature search to collect all the reasons --- but that's science for you.

[Terry_Roll]

> from what I've seen, there's a lot of "obscurity" to this; there are many seemingly arbitrary choices all over the place.

When is a (7-/pk/win)zip compression algo not an encryption algorithm?

Do the use of certain mathematical functions make it an encryption algo?

I've always found the use of prime numbers in some encryption algo's to be a red herring, namely because in theory there are an infinite number of primes, but in practice your computing device can only use 1 from a finite number of primes otherwise it would take too long to encrypt something.

With this in mind, do primes actually make it easier to decrypt encrypted data?

>What's worse is that I fear there are incentives (mostly political/security interests) to keep the field small

Discussions like this ie communication poke light into those dark crevices of intellectuality.

[holoduke]

Isn't all the math involved in the end based on the modulo operator and prime numbers?

[dragontamer]

Yes in "Galois Field" arithmetic. But GF(2^8) (or whatever) arithmetic is only in AES and a few other ciphers/hash functions. SHA-256 looks like an XOR / Add / Rotate kinda cipher.