The part I still don't understand is how this gets turned into encryption. I understand that you can use hashes to certify the state of a file, digesting a large amount of data into a 128-bit string, but I don't understand how this can be applied to a cryptographic system.
SHA1 isn't an ecryption system; it's a secure hash function. The title of tihs posting is misleading, because it's not a "cipher".
However: hash functions like SHA1 are normally used along with ciphers, in contexts where they are important to the security of the overall system. An example would be in SSL-protected Web connections, where if I can generate hash collisions, then I can take the valid signature from a certificate of a server I want to attack, instead attach it to a fake certificate of my own invention that also has the same hash value, and then use the fake certificate to authenticate to you. You think you're establishing a secure connection to Amazon, actually you're establishing a secure connection to me, you type in your credit card number, I capture it. The design of signature schemes sometimes means that I can do this general sort of thing just by creating collisions (two different strings with the same hash value) instead of the more difficult preimages (a string with a chosen hash value the same as the hash value of some other string I don't get to choose).
It is also possible to construct ciphers based on hash functions (the "Luby-Rackoff construction" is one thing to look up for more information on that), so that if you have a hash function you really trust then you can use it to build a cipher that is provably at least as strong, but those constructions tend to be inefficient, aren't used in practice, and aren't really a big concern.
Yes, along with certain other more esoteric cryptographic properties. (Two strings where only one or a few bits differ should generate as different hashes as two strings with many differing bits, for instance. Well, I guess that is true for symmetric ciphers to some extent too.)
I should add that one of the esoteric cryptographic properties is that it should be hard to find two inputs that generate the same output, no matter what the output happens to be. "Hard" means "as hard as with a birthday attack" - those work on any given hash function, and will (probably) find a collision in 2^(n/2) tries, where n is the number of bits in the output from the hash function. In the case of SHA-1, n is 160, so a birthday attack would take 2^80 tries. This break finds a collision in 2^69 tries.
Secure hash functions are one-way; you shouldn't be able to "decrypt" the output of the secure hash to find the input. That's different from a cipher, where you are supposed to be able to reverse it and your adversary isn't. Part of how the one-wayness works is that a secure hash function has a fixed output size, and normally takes a variable-length input; so unambiguous decryption is trivially impossible (there will be many collisions, i.e. different inputs that give the same output, just because there are an infinite number of possible input values and only a finite number of possible output values) but even ambiguous decryption is supposed to be impossible (given an output value, it should be hard to find any input value to give that output, never mind whether it was the "right" one). Ciphers, on the other hand, have an output basically the same size as the input (modulo some additional wrinkles in the case of public-key systems), and decrypt unamibugously (unless they're special ciphers designed not to...).
Also, secure hash functions as such do not have keys, whereas ciphers do. There are reasons you might sometimes want a secure hash that does have a key, but when you want that, you'd normally get it by using a standard unkeyed hash along with a construction like HMAC designed to make an unkeyed hash into a keyed hash.
As I mentioned, it's possible to build a cipher out of a hash function. The reverse is also true - there are ways to build a hash function based on a cipher. That's what Unix crypt(3) does.
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
syntheid
no subject
Date: 2005-02-16 07:35 pm (UTC)no subject
Date: 2005-02-16 07:58 pm (UTC)However: hash functions like SHA1 are normally used along with ciphers, in contexts where they are important to the security of the overall system. An example would be in SSL-protected Web connections, where if I can generate hash collisions, then I can take the valid signature from a certificate of a server I want to attack, instead attach it to a fake certificate of my own invention that also has the same hash value, and then use the fake certificate to authenticate to you. You think you're establishing a secure connection to Amazon, actually you're establishing a secure connection to me, you type in your credit card number, I capture it. The design of signature schemes sometimes means that I can do this general sort of thing just by creating collisions (two different strings with the same hash value) instead of the more difficult preimages (a string with a chosen hash value the same as the hash value of some other string I don't get to choose).
It is also possible to construct ciphers based on hash functions (the "Luby-Rackoff construction" is one thing to look up for more information on that), so that if you have a hash function you really trust then you can use it to build a cipher that is provably at least as strong, but those constructions tend to be inefficient, aren't used in practice, and aren't really a big concern.
no subject
Date: 2005-02-17 08:31 am (UTC)no subject
Date: 2005-02-17 01:07 pm (UTC)http://en.wikipedia.org/wiki/Cryptographic_hash_function
no subject
Date: 2005-02-17 09:48 pm (UTC)no subject
Date: 2005-02-17 02:00 pm (UTC)Also, secure hash functions as such do not have keys, whereas ciphers do. There are reasons you might sometimes want a secure hash that does have a key, but when you want that, you'd normally get it by using a standard unkeyed hash along with a construction like HMAC designed to make an unkeyed hash into a keyed hash.
As I mentioned, it's possible to build a cipher out of a hash function. The reverse is also true - there are ways to build a hash function based on a cipher. That's what Unix crypt(3) does.