On 9055 day of my life James Blackwell wrote:
>> Why not put both detached signatures into the checksum file?
>
> What's the point of this anyways?
Flexebility.
> Unless you're unlike most uses, you're using the default hashing,
> which is [drumroll please.] SHA-1.
But those who care, can ch
On Tue, Mar 22, 2005 at 07:18:03PM -0500, Adrian Irving-Beer wrote:
> > (`<' has a higher order of operation than `^', so that's the same as `(y
> > < 2) ^ 32', and that will only ever be 32 or 33 meaning the inner loop
> > never ends.)
>
> Also, ^ is XOR in C, not exponential.
Oh, whoops, you s
* Adrian Irving-Beer (Mar 23, 2005 01:40):
> On Tue, Mar 22, 2005 at 04:55:39PM -0600, Matthew Dempsky wrote:
> > (`<' has a higher order of operation than `^', so that's the same as
> > `(y < 2) ^ 32', and that will only ever be 32 or 33 meaning the
> > inner loop never ends.)
> Also, ^ is XOR i
Adrian Irving-Beer <[EMAIL PROTECTED]> writes:
> Also, ^ is XOR in C, not exponential.
And comparing x with MAXINT + 1 is not the most intelligent thing a
programmer could do ;-)
--
Matthieu
___
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
htt
On Tue, Mar 22, 2005 at 04:55:39PM -0600, Matthew Dempsky wrote:
> (`<' has a higher order of operation than `^', so that's the same as `(y
> < 2) ^ 32', and that will only ever be 32 or 33 meaning the inner loop
> never ends.)
Also, ^ is XOR in C, not exponential.
signature.asc
Description: Di
On Mon, 2005-03-21 at 10:55 -0500, James Blackwell wrote:
> main.c:
> int main() {
> unsigned int x,y;
> for (x = 0; x < 2^32; ++x) for (y = 0; y < 2^32; ++y);
> return printf("Now you can worry\n");
> }
Whew, I guess we'll never have to worry then. :)
(`<' has a higher order of operation
> The security requirements for a revision control system are
> difficult to state in a general way. Different deployments
> are likely to have different user identity and authentication
> realms and mechanisms; different deployments are likely to
> impose different requirements about the struct
Adrian Irving-Beer <[EMAIL PROTECTED]> writes:
[...]
> Let's say I have a particular piece of data that MD5 hashes into a
> paricular hash value (we'll call it MD5-A), and SHA1 hashes into
> another value (SHA1-A).
>
> Let's say I then manage to 'break' MD5, by creating another piece of
> data th
On Wed, Mar 16, 2005 at 11:07:27AM -0800, Tom Lord wrote:
> But logically speaking, the combination of two hash functions is a
> single hash function. It is just as "a priori" likely that the
> combination will be broken.
(n.b. I'm not arguing for a particular strategy here, just
reaffir
I realize that this is a very long essay but the point is: the idea of
adding more hash functions is based on an architectural misconception.
Instead of adding SHA1 in addition to MD5, it would be far better
to make signing not depend on the checksum data at all and just leave
the use of MD5 alo
>
> Why not put both detached signatures into the checksum file?
What's the point of this anyways? Unless you're unlike most uses, you're
using the default hashing, which is [drumroll please.] SHA-1.
Throwing asside repudation, it still takes is 8 bytes to collide an
md5sum, and about 8 and a
On Wed, Mar 16, 2005 at 19:54:53 +, Bruce Stephens wrote:
> Ivan Boldyrev <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > When you sign a patch, you just sign ./checksum file. But this file
> > is list of filenames and md5sums:
>
> Ah. I assumed it was signing a patch, but I guess that wouldn'
On Wed, Mar 16, 2005 at 09:49:24PM +0100, Andreas Rottmann wrote:
> >>> Is this better for you? i.e. there is a possibility to find two
> >>> values which hash to the same hash without using
> >>> brute force attack.
> >>
> >> That is the case for all known hashing algorithms. Uninteresting
> >> di
On Thu, Mar 17, 2005 at 01:42:39 -0500, Adrian Irving-Beer wrote:
> On Wed, Mar 16, 2005 at 10:03:55PM +0100, Karel Gardas wrote:
>
> > "One-way hash functions are supposed to have two properties. One,
> > they're one way. This means that it is easy to take a message and
> > compute the hash val
On Thu, 17 Mar 2005, Andreas Rottmann wrote:
> > Two, they're collision free. This means that it is impossible to
> > find two messages that hash to the same hash value. The
> > cryptographic reasoning behind these two properties is subtle, and I
> > invite curious readers to learn more in my bo
On Wed, Mar 16, 2005 at 10:03:55PM +0100, Karel Gardas wrote:
> "One-way hash functions are supposed to have two properties. One,
> they're one way. This means that it is easy to take a message and
> compute the hash value, but it's impossible to take a hash value and
> recreate the original mes
On 9050 day of my life Aaron Bentley wrote:
> John Arbash Meinel wrote:
>> Why not put both detached signatures into the checksum file?
>
> It's not 'both', it's 'all', and in many cases, 'all' is 4 or more
> files. That's a lot of times to enter your password for signing.
>
> (gpg: --clearsign d
On Wed, 2005-03-16 at 20:03 +0100, Karel Gardas wrote:
> I was in impression that patch signing was created mainly for making
> trusted archive mirrors on untrusted hosts possible.
I've yet to hear a plausible attack against MD5 for use in corrupting a
trustworthy archive by tricking someone into
On Wed, 16 Mar 2005, Andreas Rottmann wrote:
> Karel Gardas <[EMAIL PROTECTED]> writes:
>
> > On Wed, 16 Mar 2005, Andrew Suffield wrote:
> >
> >> On Wed, Mar 16, 2005 at 07:57:15PM +0100, Karel Gardas wrote:
> >> > On Wed, 16 Mar 2005, Andrew Suffield wrote:
> >> >
> >> > > On Wed, Mar 16, 2005 a
Karel Gardas <[EMAIL PROTECTED]> writes:
> On Wed, 16 Mar 2005, Andrew Suffield wrote:
>
>> On Wed, Mar 16, 2005 at 07:57:15PM +0100, Karel Gardas wrote:
>> > On Wed, 16 Mar 2005, Andrew Suffield wrote:
>> >
>> > > On Wed, Mar 16, 2005 at 12:46:28PM +0100, Karel Gardas wrote:
>> > > > Sorry! That'
Ivan Boldyrev <[EMAIL PROTECTED]> writes:
[...]
> When you sign a patch, you just sign ./checksum file. But this file
> is list of filenames and md5sums:
Ah. I assumed it was signing a patch, but I guess that wouldn't be as
useful as signing the actual contents of what you end up with after
ap
You make too many unjustified assumptions about the nature of
successful attackers. I agree that a lot of pragmatic planning
relies on such assumptions but, hey, this is the *core of arch*
we're talking about :-)
-t
___
Gnu-arch-users mailing
From: Karel Gardas <[EMAIL PROTECTED]>
I was in impression that patch signing was created mainly for making
trusted archive mirrors on untrusted hosts possible.
In some sense it was, certainly. From one perspective, the mirroring
process is just an arch transport layer even though it'
On Wed, 16 Mar 2005, Andrew Suffield wrote:
> On Wed, Mar 16, 2005 at 07:57:15PM +0100, Karel Gardas wrote:
> > On Wed, 16 Mar 2005, Andrew Suffield wrote:
> >
> > > On Wed, Mar 16, 2005 at 12:46:28PM +0100, Karel Gardas wrote:
> > > > Sorry! That's just my short-cut of the whole problem. As I've
On Wed, Mar 16, 2005 at 11:07:27AM -0800, Tom Lord wrote:
> You argue that while one function will certainly be broken,
> it is unlikely that two functions will be broken at the same
> time.
>
> But logically speaking, the combination of two hash functions
> is a single hash function. It is just
On Wed, Mar 16, 2005 at 07:57:15PM +0100, Karel Gardas wrote:
> On Wed, 16 Mar 2005, Andrew Suffield wrote:
>
> > On Wed, Mar 16, 2005 at 12:46:28PM +0100, Karel Gardas wrote:
> > > Sorry! That's just my short-cut of the whole problem. As I've already
> > > written I don't agree fully with Ivan's
On Wed, 16 Mar 2005, Tom Lord wrote:
>
>
> It makes more sense to beef up security in a multi-modal fashion.
>
> For example, arch's security model already presumes that client
> machines are secure. Therefore, the use of md5 in core arch is
> ultimately just a redundant (except on NFS :-) layer
You argue that while one function will certainly be broken,
it is unlikely that two functions will be broken at the same
time.
But logically speaking, the combination of two hash functions
is a single hash function. It is just as "a priori" likely
that the combination will be broken.
Really, a
Tom Lord wrote:
The "combination" of two hash functions is itself a single hash function.
So, arguments of the form "two are better than one", if mathematically
based, aim for the conclusion that nothing short of an infinite amount
of hashing code in core arch will be enough.
It's not mathmatically
On Wed, 16 Mar 2005, Andrew Suffield wrote:
> On Wed, Mar 16, 2005 at 12:46:28PM +0100, Karel Gardas wrote:
> > Sorry! That's just my short-cut of the whole problem. As I've already
> > written I don't agree fully with Ivan's statements, but this does not
> > change anything on the fact that MD5 i
On Wed, Mar 16, 2005 at 10:30:08AM -0800, Tom Lord wrote:
>
> The "combination" of two hash functions is itself a single hash function.
>
> So, arguments of the form "two are better than one", if mathematically
> based, aim for the conclusion that nothing short of an infinite amount
> of hashing
On Wed, 16 Mar 2005, Andrew Suffield wrote:
> On Wed, Mar 16, 2005 at 10:02:35AM +0100, Karel Gardas wrote:
> > On Wed, 16 Mar 2005, Andrew Suffield wrote:
> >
> > > On Wed, Mar 16, 2005 at 12:26:30PM +0600, Ivan Boldyrev wrote:
> > > > > If someone finds a second pre-image attack against md5, the
It makes more sense to beef up security in a multi-modal fashion.
For example, arch's security model already presumes that client
machines are secure. Therefore, the use of md5 in core arch is
ultimately just a redundant (except on NFS :-) layer of verification
of the transports and storage l
The "combination" of two hash functions is itself a single hash function.
So, arguments of the form "two are better than one", if mathematically
based, aim for the conclusion that nothing short of an infinite amount
of hashing code in core arch will be enough.
-t
__
On Wed, Mar 16, 2005 at 12:46:28PM +0100, Karel Gardas wrote:
> Sorry! That's just my short-cut of the whole problem. As I've already
> written I don't agree fully with Ivan's statements, but this does not
> change anything on the fact that MD5 is broken.
MD5 is not broken. That's a myth. Stop spr
On Wed, Mar 16, 2005 at 10:02:35AM +0100, Karel Gardas wrote:
> On Wed, 16 Mar 2005, Andrew Suffield wrote:
>
> > On Wed, Mar 16, 2005 at 12:26:30PM +0600, Ivan Boldyrev wrote:
> > > > If someone finds a second pre-image attack against md5, then arch
> > > > will be in trouble (but so will just ab
Aaron Bentley wrote:
...
Again, my feeling was to make it expandable, so that if someone wants to
turn on gpg signing, they know in advance that they should probably set
up a gpg-agent of some sort. Actually, since baz now requests 2
signatures on a commit, it motivated me to set up gpg-agent.
We'
John Arbash Meinel wrote:
Aaron Bentley wrote:
John Arbash Meinel wrote:
Why not put both detached signatures into the checksum file?
It's not 'both', it's 'all', and in many cases, 'all' is 4 or more
files. That's a lot of times to enter your password for signing.
(gpg: --clearsign does not yet w
John Arbash Meinel wrote:
Why not put both detached signatures into the checksum file?
It's not 'both', it's 'all', and in many cases, 'all' is 4 or more
files. That's a lot of times to enter your password for signing.
(gpg: --clearsign does not yet work with --multifile)
Aaron
--
Aaron Bentley
On 9050 day of my life Bruce Stephens wrote:
> Anyway, hashes in Arch are about detecting unexpected modifications
> due to random breakage. If you really care about patches you'd sign
> them, wouldn't you?
When you sign a patch, you just sign ./checksum file. But this file
is list of filenames
On Wed, 2005-03-16 at 12:39 +0100, Peter Conrad wrote:
> I understood Ivan's scenario like this:
>
> 1. attacker creates Patch-A (harmless) and Patch-B (evil) with identical
>checksums
> 2. attacker submits Patch-A to maintainer
> 3. maintainer integrates Patch-A into software, signing it
Thi
Adrian Irving-Beer wrote:
On Wed, Mar 16, 2005 at 09:16:08AM -0600, John Arbash Meinel wrote:
Presumably since it also wants to sign the log file, but avoid a
detached signature for every file (ugly).
Why not put both detached signatures into the checksum file?
How would it know which file gets
On 9050 day of my life Jason McCarty wrote:
> Maybe, but what alternative do we have today? AIUI, gpg-signing in
> general just encrypts a hash (of a hash, in our case), so you need a
> good choice for both the hash tla uses and the one gpg uses. So which
> hash(es)?
I have an idea: create detache
Aaron Bentley wrote:
John Arbash Meinel wrote:
Why not put both detached signatures into the checksum file?
It's not 'both', it's 'all', and in many cases, 'all' is 4 or more
files. That's a lot of times to enter your password for signing.
(gpg: --clearsign does not yet work with --multifile)
Aar
On Wed, Mar 16, 2005 at 09:16:08AM -0600, John Arbash Meinel wrote:
> >Presumably since it also wants to sign the log file, but avoid a
> >detached signature for every file (ugly).
>
> Why not put both detached signatures into the checksum file?
How would it know which file gets which signature?
Adrian Irving-Beer wrote:
On Wed, Mar 16, 2005 at 02:49:37PM +0100, Matthieu Moy wrote:
By the way, why doesn't arch just sign the .tar.gz instead of signing
a hash of this .tar.gz ?
Presumably since it also wants to sign the log file, but avoid a
detached signature for every file (ugly).
Why no
On Wed, Mar 16, 2005 at 02:49:37PM +0100, Matthieu Moy wrote:
> By the way, why doesn't arch just sign the .tar.gz instead of signing
> a hash of this .tar.gz ?
Presumably since it also wants to sign the log file, but avoid a
detached signature for every file (ugly).
signature.asc
Description:
On Wed, 16 Mar 2005, Aaron Bentley wrote:
> Karel Gardas wrote:
> > Yes, I agree, but combining two hashes from which one is considered broken
> > and one is considered weak these days is IMHO less secure than using one
> > hash which is considered secure.
[...]
> So while it's definitely time t
On Wed, Mar 16, 2005 at 10:54:52AM +, Bruce Stephens wrote:
> Ivan Boldyrev <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > Attackers creates some sexy patch for TLA (for example, support of
> > multiple hashes from libgcrypt). Then I create another patch that
> > stoles gpg passwords that peopl
Jason McCarty <[EMAIL PROTECTED]> writes:
> Maybe, but what alternative do we have today? AIUI, gpg-signing in
> general just encrypts a hash (of a hash, in our case), so you need a
> good choice for both the hash tla uses and the one gpg uses. So which
> hash(es)?
By the way, why doesn't arch ju
Karel Gardas wrote:
Yes, I agree, but combining two hashes from which one is considered broken
and one is considered weak these days is IMHO less secure than using one
hash which is considered secure.
Even the reduced-rounds attacks on SHA-1 still require more rounds than
MD5 ever required.
Combi
Karel Gardas wrote:
> On Wed, 16 Mar 2005, Peter Conrad wrote:
> > Combining different hashes in the signature should make attacks a lot
> > more difficult, because an attacker would have to produce collisions
> > for all hashes at the same time. Of course, *all* hashes must be
> > validated when
On Wed, 16 Mar 2005, Peter Conrad wrote:
> Am Mittwoch, 16. März 2005 11:51 schrieb Karel Gardas:
> > On Wed, 16 Mar 2005, Peter Conrad wrote:
> > > Hi,
> > >
> > > On Wed, Mar 16, 2005 at 12:26:30PM +0600, Ivan Boldyrev wrote:
> > > > Tom Lord merges sexy patch. Even if he will re-sign patch,
>
Hi,
Am Mittwoch, 16. März 2005 11:51 schrieb Karel Gardas:
> On Wed, 16 Mar 2005, Peter Conrad wrote:
> > Hi,
> >
> > On Wed, Mar 16, 2005 at 12:26:30PM +0600, Ivan Boldyrev wrote:
> > > Tom Lord merges sexy patch. Even if he will re-sign patch,
> > > MD5 sum in ./checksum will be same because *.
Ivan Boldyrev <[EMAIL PROTECTED]> writes:
[...]
> Attackers creates some sexy patch for TLA (for example, support of
> multiple hashes from libgcrypt). Then I create another patch that
> stoles gpg passwords that people type when using signed archives.
>
> Two patches with same MD5 signature. Q
On Wed, 16 Mar 2005, Peter Conrad wrote:
> Hi,
>
> On Wed, Mar 16, 2005 at 12:26:30PM +0600, Ivan Boldyrev wrote:
> >
> > Tom Lord merges sexy patch. Even if he will re-sign patch,
> > MD5 sum in ./checksum will be same because *.patches.tar.gz is same.
>
> this is wrong. If Tom merges your patch
On Wed, Mar 16, 2005 at 10:02:35AM +0100, Karel Gardas wrote:
> On Wed, 16 Mar 2005, Andrew Suffield wrote:
>
> > On Wed, Mar 16, 2005 at 12:26:30PM +0600, Ivan Boldyrev wrote:
> > > > If someone finds a second pre-image attack against md5, then arch
> > > > will be in trouble (but so will just ab
Hi,
On Wed, Mar 16, 2005 at 12:26:30PM +0600, Ivan Boldyrev wrote:
>
> Tom Lord merges sexy patch. Even if he will re-sign patch,
> MD5 sum in ./checksum will be same because *.patches.tar.gz is same.
this is wrong. If Tom merges your patch, he will automatically create
additional log entries i
On Wed, 16 Mar 2005, Andrew Suffield wrote:
> On Wed, Mar 16, 2005 at 12:26:30PM +0600, Ivan Boldyrev wrote:
> > > If someone finds a second pre-image attack against md5, then arch
> > > will be in trouble (but so will just about anything else).
> >
> > MD5 is considered insecure for many years.
On Wed, Mar 16, 2005 at 12:26:30PM +0600, Ivan Boldyrev wrote:
> > If someone finds a second pre-image attack against md5, then arch
> > will be in trouble (but so will just about anything else).
>
> MD5 is considered insecure for many years. Arch is already in trouble
> because Arch developers d
On 9050 day of my life Matthew Dempsky wrote:
> On Tue, 2005-03-15 at 20:03 +0600, Ivan Boldyrev wrote:
>> Arch uses MD5 internally. But MD5 is not weak hash function, it was
>> attacked many times, and recently first practical attack was created:
>
> That attack you cite is just at finding two do
61 matches
Mail list logo
