On Mon, Aug 23, 2004 at 01:03:54AM +0200, martin f krafft wrote:
So if I wanted to attack 80% of all Debian machines all over the
world, I would try to compromise one of the 1000 keys, thereby
getting write access to the incoming queue. Then, I could NMU
a package and upload a trojaned
also sprach Thomas Bushnell BSG [EMAIL PROTECTED] [2004.08.24.0312 +0200]:
But how does this false sense cause a problem? For example, if
users regularly scanned all the source code on their system, and
this would cause them to stop doing so, then the false sense would
be a problem!
I see
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
Abwesenheit
Sehr geehrte Damen und Herren,
ich bin in der Zeit vom 21. August bis zum 9. September im Urlaub. In dieser Zeit
können Sie sich an Herrn Zander wenden.
Telefon
0391 544 56 70
Mit freundlichen Grüßen
Sebastian Hennebrüder
Leitung eCommerce - Internet
---
Grass GmbH, eCommerce -
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
martin f krafft [EMAIL PROTECTED] writes:
The logical conclusion from your arguments is that we should
actually remove the ssh package from Debian!
How so?
If we shouldn't sign and check signatures because there are still ways
of subverting one's ssh binary, then we shouldn't even
On Fri, 20 Aug 2004 02:26:17 -0600, Will Aoki wrote:
Set LogLevel VERBOSE in /etc/ssh/sshd_config
LogLevel is already set to VERBOSE. But even with LogLevel DEBUG the
invalid usernames are not logged. :-(
I tested that on three different machines running Debian/woody.
It works for me on
On Thu, 19 Aug 2004 11:52:51 +0300 (EEST), Martin Fluch wrote:
Do you really want to log those illegal user names? If you do so, you
would run into danger to log passwords in plain text as well, when you
accidently enter the password when ssh asks you for the user name...
I'm aware of that,
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
also sprach Thomas Bushnell BSG [EMAIL PROTECTED] [2004.08.24.1840 +0200]:
If we shouldn't sign and check signatures because there are still ways
of subverting one's ssh binary, then we shouldn't even distribute ssh
binaries. Doesn't such distribution cause a false sense of security?
Yeah
Am Monday, 23. August 2004 19:38 schrieb PaulNM:
Just a note:
I have 149 emails in my deb-sec-announce folder. The earliest is dated
12/30/2003, and the latest is 8/18/2004. Security announce is NOT a
high volume list, if that's your concern.
PaulNM
High volume is not my concern and of
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
It is not always enough or required to find something that has the right
hash value. With windows a modified client can authentication just by
knowing the hash value (and there is no salt). [Windows does not use
MD5, but that is beside the point.]
What I have implemented on the web requires
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
Timo == Timo Veith [EMAIL PROTECTED] writes:
[...]
Timo High volume is not my concern and of course I am subscribed to
Timo debian-security-announce. I came across this issue because I
Timo patched a package, recompiled it and installed it via dpkg. After
Timo that apt-get upgrade wanted to
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
