sha256 kind of sfv.

JackFoo · Post by *JackFoo » 2003-03-23, 22:10 UTC

Hi, I've started working on a sha256 file digest (a kind of csv, much like md5 except the digest length is 256bits and its more secure). If anyone is interested please drop a line here with your suggestion.

Cheers.

JackFoo · Post by *JackFoo » 2003-03-25, 10:42 UTC

Sorry, this is of course an error, I meant sfv (as in crc32) instead of csv.

Cheers.

Post by *ghisler(Author) » 2003-03-26, 21:32 UTC

Sounds interesting - is there a standard format for this, like sfv for CRC32?

JackFoo · Post by *JackFoo » 2003-03-26, 23:58 UTC

Well sha256 is a "crypto strong" hash function (since there were some weaknesses detected in MD5), it's mainly used for signing. But not much used in CRC kind of work. It's an extension of the original sha function which returned 160bits, this one returns 256 and was created to be used with strong ciphers (128bit strong +)(*), a kind of key generator for AES. It's defined in FIPS 180-2 as a part of sha2 (**). But no standard as such... maybe I'll define a standard ;-) I'll call it [cfv] as in cryptographic file verification... heh.

(*) Hash function provides roughly the security equaling half of the number of bits it returns, so 160bits -> up to 80bit keys (DES) and sha256-> up to 128bit keys.

(**) sha256 is only a part of sha2 which defines sha256/384/512.
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf

Post by *ghisler(Author) » 2003-03-28, 08:50 UTC

Well sha256 is a "crypto strong" hash function (since there were some weaknesses detected in MD5), it's mainly used for signing.

I think that MD5 is good enough to check whether a file was damaged/modified or not. MD5 may have weaknesses, but these are for the case that someone tries to create a bogus file with the same MD5. This is only relevant when the file is being signed, but not for simple MD5 checks where the forger could change the MD5 itself much more easily than creating a file with the same MD5...

soreno · Post by *soreno » 2003-03-28, 12:05 UTC

"since there were some weaknesses detected in MD5"

Do you have any links discussing this ?
From what i've read about md5 (not much..) there has been no collisions - yet.

JackFoo · Post by *JackFoo » 2003-03-28, 17:09 UTC

Whoa collisions, not as far as I know (md4 IS completely broken and collisions can be found within seconds on a modern PC)... but in crypto community a theoretic weakness or attack is quite enough. I don't know about the current status but the original paper was published by Dr. Hans Dobbertin:
http://www.cs.ucsd.edu/users/bsy/dobbertin.ps
I think the whole issue of MD5 just dropped out of sight since sha1 was introduced and although md5 is faster sha1/2 are used when security is an issue (paranoic perception), for example RSA still uses md5 BUT not by itself, it's either used with sha1 or as a part of HMAC...
All things said md5 is more than enough for normal file verification.

Cheers.

JackFoo · Post by *JackFoo » 2003-03-30, 23:21 UTC

Ok, just finished the program, this is the readme. If anyone is interested or have a suggestion drop a line here.

Cheers.

Code: Select all

sha256 v1.00b
---------------------------------
[31.03.03] Version 1.00b

History:
  Pre release v1.00b [31.03.03]

USAGE:
Creates/checks sha256 digest from given files.

  sha256 [-h] [-c [cfv file]] [-s string] [-f [file1] [file2] ... [fileN]]
         [-l [list file]] [-o [out file]] [-e]
    -h               Prints this screen.
    cfv file         Checks the cfv file.
    string           Creates sha256 hash from the given string and outputs it
                     to screen.
    file1...fileN    Creates sha256 digest from the files [1-N].
    list file        Opens the list file and creates sha256 digest from files
                     found within.
    out file         Puts the output in the specified file, default is screen.
    -e               If this switch is specified with -c the output will
                     contain only errors, default is verbose.


1. Please note that -l and -f cannot be specified together.
2. -s takes precedence, if it's specified no other option will be parsed.
3. If -c is specified -l or -f will not be parsed.
4. In -f you can also use wildcards eg. *.txt (this is platform specific).

soreno · Post by *soreno » 2003-03-31, 06:47 UTC

JackFoo:
Can you provide a download link ?

JackFoo · Post by *JackFoo » 2003-03-31, 08:14 UTC

It's still in testing, plus I'm not sure I'll put it for download, I have some things to consider first... But if you would like to help test it I'll mail it to you.

Cheers.