I have cum to know that this is possible to find colliding pairs for this reduced SHA1]]>

set path=c:\fciv;%path%

and then typing

fciv -?

Deciphering the unix-style help would be a tad difficult for your average Windows user, but then "Windows security" is an oxymoron.]]>

An easy compromise is downloading the fciv.exe freebie from Microsoft.com and running it with the "-both" option (i.e. both SHA-1 and MD5) to create a .xml that fciv can use to verify. Even though you don't get the super-dooper advance that Stephanoff proposed by hashing hashes, using MD5 plus SHA-1 probably means we're good for quite a few more years yet. (Could a crypto expert please comment on how robust a combined approach is.)

MS being MS, they haven't provided the source, but, by virtue of allowing an .xml db, perhaps they have just created the next open source de facto standard? It's nowhere near as sexy as Stephanoff's suggestion, but it's available to every DOS-savvy MS user today, and it allows an easy transition from existing MD5 or SHA-1 tables.

]]>This looks really good to me too, using SHA-1 and MD5:

d1= hash1(message);

d2= hash2(message);

d3= hash1((d1+message)+d2);

Did you ever come up with anything you liked more?

Mike

]]>"Attacks always get better".]]>

]]>

For that matter, any software using hashes can be broken by a file-system attack which redirects the check of the hacked file to an unhacked copy.

]]>SHA-0 2**39

Nice what difference the little Shift makes.

Maybe SHA can be make more secure again through

chances at one or more of the logical unit(s) in the

formula.

sha1("the data") . md5("the data")

The data would have to be very special to produce colliding hashes from 2 different hashing functions at the same time.

or sha1 the data and combine it with the sha1 of the data reversed.

sha1("the data") . sha1("atad eht")

Pete

]]>since this hash function is base on extentions of the base key then its breakable in less time complexty by using

hashim algorithm :which is a new generalize search algorithm simalar to likelihoood algorithm but it work in multy points :

see yahoo groups:cryptology]]>

> The 2**80 is a brute-force attack. Less than

> brute force means that it is "broken", for the

> reason cjr gave. ("broken" and defeatable in ---- ?????

> practice are two different things). The only

> exception to this convention I'm aware of is in

> public-key cryptography.

> AFAIK, all known public-key algorithms are

> vulnerable to less than brute-force attack. The

> key sizes are boosted to compensate, for lack

> of any alternative.

]]>> The 2**80 is a brute-force attack. Less than

> brute force means that it is "broken", for the

> reason cjr gave. ("broken" and defeatable in ---- ?????

> practice are two different things). The only

> exception to this convention I'm aware of is in

> public-key cryptography.

> AFAIK, all known public-key algorithms are

> vulnerable to less than brute-force attack. The

> key sizes are boosted to compensate, for lack

> of any alternative.

]]>p^2+q^2-w^2=j

where

p*q=j p,q prime numbers

also

p/q+q/p- c=1 where c=w^2/j

is enouph to break

RSA IN POLYNOMIAL TIME"

if you put x=p/q then q/p=1/x

now HASHIM formula will be:

x+1/x-c=1 wich enable you to breack RSA in real time .

please if you ugnorent not say(nonsense)

regards

HASHIM KAREEM

IRAQ]]>

1. SHA-1 is cracked though it takes some significant effort to find the crack (unless very lucky).

2. If we use HMAC-SHA-1, it is not cracked (yet) so doing so would give us the level of security we wish.

3. Creating SSL certificates [C and C' where H(C) = H(C') ] for installation on servers where C' utilizes a wildcard for the domain name or has other malicious features, represents the most significant danger.

Sound about right?

]]>A fake certificate can be reused much more times than a fake message and the 'return on investment' will be higher for anybody wanting to steal identity...

I can see that this crack poses a theoretical threat to the security of SHA1, but how does it affect a regular user? What good would it do an adversary to find a collision in someone's digital signature? The adversary could change the original message to the collision he/she had found, but odds are that the "collision message" would make absolutely no sense whatsoever. The recipient would get a string of absolute jibberish that was certified as being sent by his/her friend. I'm probably overlooking something here, but what security risk does this really cause? There would be a real danger if someone found a way to reverse the hash and reveal the plaintext message that the sender had signed.

My apologies if I sound like a fool.

]]>in yahoo"

This kind of thing we don't even bother responding to.

]]>p^2+q^2-w^2=j

where

p*q=j p,q prime numbers

also

p/q+q/p- c=1 where c=w^2/j

is enouph to break

RSA IN POLYNOMIAL TIME"

I get this sort of nonsense in e-mail *all the time*. This is the first one you all get to see.

Since the invention of the RSA public-key algorithm, all cryptographers get this sort of nonsense all the time. We either have to read through them all, which is a waste of time, or ignore them all, which has the potential of ignoring an actual breakthrough.

This is why RSA Security invented the RSA Factoring Challenge. Basically, these are a series of increasingly long numbers to factor. Some of them have been factored already, but many have not.

http://www.rsasecurity.com/rsalabs/node.asp?id=2092

Now, every time I get one of these "I can factor numbers faster than everyone else," I send them to the webpage. If they can factor numbers that no one else can, they'll have no problem getting every mathematician to listen to them. If they can't, mathematicians will have no problem ignoring them.

]]>p^2+q^2-w^2=j

where

p*q=j p,q prime numbers

also

p/q+q/p- c=1 where c=w^2/j

is enouph to break

RSA IN POLYNOMIAL TIME]]>

in yahoo]]>

I was missing something, and 128 bit hashes are brute-forceable. See the newer thread for a low-memory technique:

http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html

I still think 256 bit hashes have a comfortable margin.

]]>also look at http://www.texas-holdem-playing-cards.com/

]]>A. A new compression algorithm.

]]>One Way Hash functions takes a large set of data

(source) and produce a relatively short string. Since there is no way (very limited chance) of producing the original source data from the hash. All attacks are basically equivalent to "buffer overflow" attacks. Where the attacker modifies the source to produce an equivalent hash. Since we believe the hash is authentic to start with, why not add a source-size parameter to the hash. Most of these attacks modify and append data to the source data to make the hashes match. Given the additional (trusted) information about the

source's size it would basically limit the usefulness of this type of attack. This will then

basically be a protocol/conformity constraint on the modified source data which would make things

a bit more difficult for any attacker. Other parameters could also be employed, for example a source-symbol frequency, etc.

crack this :)

]]>Unless I'm missing something (and it's not the birthday paradox), 128 bit hashes aren't brute-forceable with today's technology.

The fastest supercomputers in the world are about 2^48 times faster than the electromechanical Mark-I, arguably the first functional computer.

A 256 bit hash takes 2^64 times as long to brute force as a 128 bit hash, if you have unlimited memory.

In short, 256 bits is plenty. ]]>

Best solution for the time being is to migrate to higher range.

It doesn't make sense to migrating to 256bit, from the existing 160 bit and wait till 256bit get cracked (by assuming that today's technology won't grow rapidly, which is a big joke).

I feel better to adopt higher than 256 (something like 512), the probability of cracking hash (in what ever way) will reduce at least 1%

]]>---------------

http://www.ptdd.com

http://www.yiwodisk.com

]]>

Please explain me one thing.

Everyone keep saying: SHA-1 is broken... It takes 2^69 operation to broke it...

I dont understand.

Every hashing algorithm will have collisions. Every. Because we have limited hash space to represent unlimited variants of data. Yes? Yes.

So EVERY algorithm can be broken. They manage to collide in 2^69 tries of 2^80 possibilites. ENORMOUS LUCK. Its not something to remember.

Lets say, after introduction od SHA-256 I broke it in 20 tries. Luck. Then you say SHA-256 is broken??? How could you use word broken... I merly manage to collide.

So concluding. Using your words, every hashing function is broken. Only time and luck is important.

I think that it doesnt matter if someone find colision or not. It wont change nothing. Keys must became longer, as computing power grows greater, to keep teoretical computing time relatively impassible long. And of that time is 2^99999 years, and someone manage to find collision in 5 days? It changes nothing. He got lucky.

But with a collision in hand, it becomes easier to find more collisions.

That, and anyone so astronomically lucky isn't going to a computer scientist, they're going to be living off the lottery.

]]>http://theory.csail.mit.edu/~yiqun/shanote.pdf

The paper on MD5 collision by Wang last year

http://eprint.iacr.org/2004/199.pdf