On Wed, Aug 25, 2004 at 06:02:22AM +0200, Almut Behrens wrote:
Somewhat more seriously: are there generally any defining criteria for
something one would call a 'hash function', saying that it always must
map some larger input space to some smaller output space?
Yes. A hash function is any
* Quoting Matthew Palmer ([EMAIL PROTECTED]):
On Tue, Aug 24, 2004 at 09:11:34PM -0400, Michael Stone wrote:
On Wed, Aug 25, 2004 at 12:39:57AM +0200, Rolf Kutz wrote:
This depends on how the attack really works. If
you just need to flip a few bits in a document it
might just look like
On Wed, Aug 25, 2004 at 11:24:00AM +1000, Matthew Palmer wrote:
I imagine that the garbage would be to bring the md5sum back to the original
to hide the trojan, rather than hey, look, I can stick garbage on the end
of the .deb and still keep the same md5sum! whee!.
Well, that's the part nobody's
On Tue, 24 Aug 2004 at 06:18:50PM -0400, Matthew Palmer wrote:
If I understand your postulate correctly:
If I, the user, encrypt a message with algorithm X and the cipher text
is intercepted by the attacker. The attacker can make his chances of
brute forcing the text BETTER by
On Wed, Aug 25, 2004 at 10:01:25AM +0100, Dale Amon wrote:
Hashing (think of cornbeef hash with things all chopped up into bits)
is a technique to generate fast lookup keys. The discussion here is
about cryptographic hash functions.
...and I think somewhere in between lie hashing functions
On Wed, Aug 25, 2004 at 01:15:13AM -0400, Hubert Chan wrote:
Ah, but then using that definition of oneway, every hash is oneway,
since there must always be some hash value corresponding to two
different input strings (assuming the input space is larger than the
output space, which is
On Thu, 26 Aug 2004, Almut Behrens wrote:
On Wed, Aug 25, 2004 at 01:15:13AM -0400, Hubert Chan wrote:
... So the only useful notion of oneway is that the hash is not easily
invertible (i.e. you can't easily find some string that produces a
given hash value).
So, if you can somehow come up with
On Wed, Aug 25, 2004 at 09:24:01AM -0400, Phillip Hofmeister wrote:
On Tue, 24 Aug 2004 at 06:18:50PM -0400, Matthew Palmer wrote:
In the case of hashing algorithms, there's one 'key' involved -- the
plaintext -- and for password security, you don't need to retrieve the key
necessarily,
On Wed, Aug 25, 2004 at 10:01:25AM +0100, Dale Amon wrote:
On Wed, Aug 25, 2004 at 06:02:22AM +0200, Almut Behrens wrote:
Somewhat more seriously: are there generally any defining criteria for
something one would call a 'hash function', saying that it always must
map some larger input space
On Thu, Aug 26, 2004 at 01:04:21AM +0200, Almut Behrens wrote:
...and I think somewhere in between lie hashing functions like crc32,
as used for detecting transmission errors, for example. Those are
not cryptographic, but possess a sufficiently large output space, so we
can expect few random
Hi,
Maybe you have already noticed - collisions have been found in MD5
hashing algorithm:
http://eprint.iacr.org/2004/199.pdf
http://www.freedom-to-tinker.com/archives/000664.html
http://www.unixwiz.net/techtips/iguide-crypto-hashes.html
My question is: Is there an easy way to make my debian sid
hi,
it is true that collisions have been found in md5 (and a lot of other hash
functions of that `family', cfr. the links you mention).
this means that the hash functions should certainly no longer be used in
applications relying on the collision-resistance of the hash function,
e.g.,
On Tue, Aug 24, 2004 at 01:13:43PM +0300, Robert Trebula wrote:
Maybe you have already noticed - collisions have been found in MD5
hashing algorithm:
That is expected--a hashing algorithm will always have collisions if the
number of inputs is greater than the output space. As for your question,
On Tue, Aug 24, 2004 at 07:36:36AM -0400, Michael Stone wrote:
That is expected--a hashing algorithm will always have collisions if the
number of inputs is greater than the output space. As for your question,
This seems to be different.
Look at the URLs from the OP.
pgpDz6ryj9TpL.pgp
On Tue, Aug 24, 2004 at 12:44:53PM +0200, Danny De Cock wrote:
it is true that collisions have been found in md5 (and a lot of other hash
functions of that `family', cfr. the links you mention).
Collisions have been found? Collisions were always.
Every hashing algorithm makes collisions...
On Tue, Aug 24, 2004 at 01:51:57PM +0200, Jan Minar wrote:
Look at the URLs from the OP.
I'd seen them before he posted. It doesn't change what I said. The
possibility of md5 collisions has always been present. What we have now
is a confirmed collision. Ok. There's no indication of how the
Robert Trebula wrote:
Maybe you have already noticed - collisions have been found in MD5
hashing algorithm:
http://eprint.iacr.org/2004/199.pdf
http://www.freedom-to-tinker.com/archives/000664.html
http://www.unixwiz.net/techtips/iguide-crypto-hashes.html
My question is: Is there an easy way to
Bartosz Fenski aka fEnIo wrote:
Collisions have been found? Collisions were always.
Every hashing algorithm makes collisions... that's just natural.
They found way to generate two input values that makes the same hash.
That's still long way before they can generate input having hash of another
On 24 Aug 2004, Robert Trebula wrote:
Maybe you have already noticed - collisions have been found in MD5
hashing algorithm:
http://eprint.iacr.org/2004/199.pdf
http://www.freedom-to-tinker.com/archives/000664.html
http://www.unixwiz.net/techtips/iguide-crypto-hashes.html
My question is:
On 24 Aug 2004, Sam Vilain wrote:
Robert Trebula wrote:
Maybe you have already noticed - collisions have been found in MD5
hashing algorithm:
[...]
I think cryptanalysts have 'cracked' pretty much all of them, though
with practically prohibitive costs of cracking them (eg, 2^50 for
On Tue, 24 Aug 2004 at 10:50:38AM -0400, Daniel Pittman wrote:
Be aware that this sort of technique multi-encryption technique can
lead to significant exposures when applied to traditional crypto; it can
produce results that allow a vastly simpler attack on the protected
information.
I
On Tue, Aug 24, 2004 at 12:44:53PM +0200, Danny De Cock wrote:
(...) but the verification
of password hashes, such as used in pam, rely on the hash function's
oneway-feature rather than on its collision-resistance...
not sure I understand -- so, if someone would like to explain this
aspect to
On Tue, Aug 24, 2004 at 08:22:54PM +0200, Almut Behrens wrote:
I always thought that the oneway-feature is not particularly relevant
when verifying passwords... In other words, if you can find (within a
reasonable amount of time) any input string that produces the same
given digest, then any
On Tue, 24 Aug 2004, Almut Behrens wrote:
On Tue, Aug 24, 2004 at 12:44:53PM +0200, Danny De Cock wrote:
(...) but the verification of password hashes, such as used in pam,
rely on the hash function's oneway-feature rather than on its
collision-resistance...
not sure I understand -- so, if
On Tue, Aug 24, 2004 at 09:18:46PM +0200, Danny De Cock wrote:
On Tue, 24 Aug 2004, Almut Behrens wrote:
On Tue, Aug 24, 2004 at 12:44:53PM +0200, Danny De Cock wrote:
(...) but the verification of password hashes, such as used in pam,
rely on the hash function's oneway-feature rather
On Tue, 24 Aug 2004, Almut Behrens wrote:
On Tue, Aug 24, 2004 at 09:18:46PM +0200, Danny De Cock wrote:
On Tue, 24 Aug 2004, Almut Behrens wrote:
On Tue, Aug 24, 2004 at 12:44:53PM +0200, Danny De Cock wrote:
(...) but the verification of password hashes, such as used in pam,
rely on the hash
On Tue, Aug 24, 2004 at 12:20:24PM -0400, Phillip Hofmeister wrote:
On Tue, 24 Aug 2004 at 10:50:38AM -0400, Daniel Pittman wrote:
Be aware that this sort of technique multi-encryption technique can
lead to significant exposures when applied to traditional crypto; it can
produce results
On Wed, Aug 25, 2004 at 12:44:43AM +1000, Daniel Pittman wrote:
Also, while there are issues with those hash algorithms, I don't think
they are quite bad enough that there is a significant *immediate* risk
to my systems; the cost of breaking in through the detected collisions
is lower than the
* Quoting Almut Behrens ([EMAIL PROTECTED]):
On Tue, Aug 24, 2004 at 09:18:46PM +0200, Danny De Cock wrote:
a cryptographic hash function, such as md5, sha1, ripemd-160, to name the
most commonly used cryptographic hash functions are constructed to have at
least the following
On Wed, Aug 25, 2004 at 12:39:57AM +0200, Rolf Kutz wrote:
This depends on how the attack really works. If
you just need to flip a few bits in a document it
might just look like typos (think crc32). If your
document is a tarball or a .deb you might be able
to insert a lot of garbage to it without
On Tue, Aug 24, 2004 at 09:11:34PM -0400, Michael Stone wrote:
On Wed, Aug 25, 2004 at 12:39:57AM +0200, Rolf Kutz wrote:
This depends on how the attack really works. If
you just need to flip a few bits in a document it
might just look like typos (think crc32). If your
document is a tarball
On 25 Aug 2004, Matthew Palmer wrote:
On Tue, Aug 24, 2004 at 12:20:24PM -0400, Phillip Hofmeister wrote:
On Tue, 24 Aug 2004 at 10:50:38AM -0400, Daniel Pittman wrote:
Be aware that this sort of technique multi-encryption technique can
lead to significant exposures when applied to traditional
On Tue, Aug 24, 2004 at 11:09:39PM +0200, Danny De Cock wrote:
for password schemes, it is important that the hash function used is
one-way: if one knows the password, it must be very simple/easy to
compute the hash of that password, but if someone obtained the hash of
a password, it must
On Wed, Aug 25, 2004 at 12:39:57AM +0200, Rolf Kutz wrote:
If you can calculate a collision from the hash and
the known password, that would be a lack off
collision resistance.
Is knowing the password really a prerequisite? I'd have said that if
you can find a collision at all, or calculate
On Tue, Aug 24, 2004 at 11:01:58PM +0200, Moritz Schulte wrote:
(...) But if your hash function is pretty good in respect to
collision-resistance but is not one-way (being similar to a 1:1
mapping between hash input and hash output), you could simply apply
the inverse function to your hash
Almut == Almut Behrens [EMAIL PROTECTED] writes:
Almut On Tue, Aug 24, 2004 at 11:09:39PM +0200, Danny De Cock wrote:
[...]
Danny being able to invert a hash function clearly means that the
Danny function is not collision-resistant,
Almut does it? (presuming that retrieving that x from
36 matches
Mail list logo
