Cryptography-Digest Digest #408, Volume #14 Tue, 22 May 01 13:13:00 EDT
Contents:
Re: "computationally impossible" and cryptographic hashs (SCOTT19U.ZIP_GUY)
Re: free/open source cryptography vs closed source FAQ (Tom St Denis)
Re: "computationally impossible" and cryptographic hashs (Tom St Denis)
Re: truth+integrity=sore losers (SCOTT19U.ZIP_GUY)
Re: truth+integrity=sore losers (SCOTT19U.ZIP_GUY)
Re: "computationally impossible" and cryptographic hashs ("Paul Pires")
Re: "computationally impossible" and cryptographic hashs (Mark Wooding)
Re: free/open source cryptography vs closed source FAQ (SCOTT19U.ZIP_GUY)
Re: "computationally impossible" and cryptographic hashs ("Paul Pires")
Re: "computationally impossible" and cryptographic hashs (Mark Wooding)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: "computationally impossible" and cryptographic hashs
Date: 22 May 2001 16:00:04 GMT
[EMAIL PROTECTED] (Daniel Graf) wrote in <[EMAIL PROTECTED]>:
> I have a basic question about cryptographic hashes. A friend
>and I were talking about how the hash algorithm used some UNIX
>machines uses only 64 (or so) bits of the password.
> Now, I don't know much of anything about cryptography, but I
>have used hash algorithms for use with hash-tables. Are
>cryptographic hashes mostly dissimilar, or am I wrong in guessing that
>more than one input at a Unix login prompt may match the string found
>in the passwd file? (particularly for passwords greater than 8
>characters).
> Looking at the sci.crypt faq I found in section 7.1 something
>which says:
>
> For some one-way hash functions it's also computationally
> impossible to determine two messages which produce the
> same hash.
>
> Does "computationally impossible" mean literally that such a
>thing cannot happen?
>
> Sorry if this is such a stupid question.
>
Its not a stupid question but many things are written to confuse
new commers. But just look at the counting argument. If you have
a 64 bit hash. It can only take on 2**64 vlaues. IF you allowe
passwords to be long then in theroy you could have more than
2**64 passwords. That means some different passwords will hash
to the same value. What people are counting on is that for
the number of passwords actaully used. There will be only a small
chance of picking two that hash the same. THe point is no matter
how small its not ZERO
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (Tom St Denis)
Subject: Re: free/open source cryptography vs closed source FAQ
Date: 22 May 2001 09:14:33 -0700
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote in message
news:<[EMAIL PROTECTED]>...
> [EMAIL PROTECTED] (Titan) wrote in
> <OCaO6.269755$[EMAIL PROTECTED]>:
>
> >I was under the impression that for things needing the best
> >encryption possible it was better to go with some sort of open
> >source implementation than a closed source one as the open
> >source one is less likely to have any implementation bugs that
> >could compromise it.
> >
> >Is this true or just a rumor?
> >
> >
> >
>
> Its true its best to go with open source. But I think the
> average person will be tricked into using a poor unsafe version.
> However there are things one can do to minimize the chance of
> getting a unsecrue encryption. One way would be to use 2 encryptions
> methods in series that add no information during the encryption.
What are you alluding to here? Why are "most people tricked into
using unsafe open source crypto"?
> There are very few open source encryption methods that don't
> add information during encryption. If you belive the hype about
> Rijndael being safe. Then about the only version of it that does
> not add infomation is BICOM by matt Timmermans.
Why is BICOM safer than a theoretical CTR mode version of AES?
(Theoretical in assuming all the keys are random,etc.. no
implementation flaws).
> You can test the feature that no information is added by
> seeing if the method is fully bijective. That is if the
> method can treat anyfile as an encrypted file or not.
> You can take any file and decrypted it with and key in BICOM
> and then take that resultant file and encyrpted back to same
> start file. Try that with any other program. IF you do
> find such another program than it my be worth do it in series
> with BICOM
Again why is that a "security feature"? It is unique and neat but why
do I NEED it to be secure? How do you break a CTR or CBC encoded
message assuming the key is totally random?
> Of couse you can use scott16u or scoutt19u but as they stand
> they don't handle short files. But can easily be in a batch
> stream where impedance matching code allow for full bijectiveity.
Why is scottxxu any safer than AES? What analysis do you have?
Tom
------------------------------
From: [EMAIL PROTECTED] (Tom St Denis)
Subject: Re: "computationally impossible" and cryptographic hashs
Date: 22 May 2001 09:20:14 -0700
[EMAIL PROTECTED] (Daniel Graf) wrote in message
news:<[EMAIL PROTECTED]>...
> I have a basic question about cryptographic hashes. A friend
> and I were talking about how the hash algorithm used some UNIX
> machines uses only 64 (or so) bits of the password.
Typically a 64-bit password will keep most people at bay for at least
a year. I would personally rather use a 128-bit password (i.e a
magstrip on a card that holds my password).
> Now, I don't know much of anything about cryptography, but I
> have used hash algorithms for use with hash-tables. Are
> cryptographic hashes mostly dissimilar, or am I wrong in guessing that
> more than one input at a Unix login prompt may match the string found
> in the passwd file? (particularly for passwords greater than 8
> characters).
Well often cryptographic hashes produce outputs between 160 and 256
bits (some larger and smaller). Typically 160 bits is considered the
minimum for security (birthday paradox attacks). Most ciphers are
based around what are known as Unbalanced Feistel Networks (there is
an official name that was posted a few days ago... DM or something
like that...). The idea is that you break the digest into say five
words and you modify one word with a function of the other four. I.e
A += F(B,C,D,E)
B += F(A,C,D,E)
etc..
SHA, MD5 and Haval are designed like this. I think Tiger/192 is
similar but not exactly the same.
As for unix I think they moved to MD5 based passwds a long time ago.
That's afaik (I don't use linux/unix much). Originally they used a 25
round DES variant with a 16-bit salt.
> Looking at the sci.crypt faq I found in section 7.1 something
> which says:
>
> For some one-way hash functions it's also computationally
> impossible to determine two messages which produce the
> same hash.
>
> Does "computationally impossible" mean literally that such a
> thing cannot happen?
It means there should be no shortcut attack way of doing so. I.e the
best way is brute force. In the case of SHA-1 for example it is
expected that you pick 2^80 random pairs before you see the first
match.
> Sorry if this is such a stupid question.
Not a stupid question. It's on topic and interesting.
Tom
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: truth+integrity=sore losers
Date: 22 May 2001 16:17:57 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in
<[EMAIL PROTECTED]>:
>[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote in message
>news:<[EMAIL PROTECTED]>...
>> [EMAIL PROTECTED] (Tom St Denis) wrote in
>> <s5bN6.126038$[EMAIL PROTECTED]>:
>>
>> >Well folks you were right, what a way to learn a lesson. I got
>> >canned from Cloakware today.
>>
>> Don't sweat if you don't get canned or piss people off
>> now and then youd be nothing but a wimp.
>
>Now I am a non-wimp who is unemployed. Somehow my values seem less
>important...
>
>> >
>> >They had no official reason for firing me except to say "if you don't
>> >know what you did wrong you shouldn't be here".
>> >
>> >So from what I gather "truth+integrity=sore losers_is congruent
>> >to_can the employee".
>> >
>>
>> Yes even the government thinks one a fool for telling the truth.
>> To keep most jobs you have to learn the unwritten rules. Bosses
>> seldom like to really hear the truth.
>
>This I know first hand.
>
>>
>> >What exactly did I do wrong? I didn't lie, I didn't violate my
>> >NDA.... --
>>
>> I don't know what you did wrong but if your lack of learning
>> how bijective compression and encryption is any indication, You
>> may have had a minor disagreement and when you failed to understand
>> the comcept boss saying he gave up on you I would have given you
>> more chances though.
>
>It's not that I don't want to accept your ideas its just that you
>haven't presented them properly yet. Handwaving is not enough.
>
Actaully your the one who has made false statements about
what BICOM can and cannot do. When I have asked you in the past
to at least check before your rant. You state you would never
look at it. So whats with this crap about present them properly.
You mind is already made up. You flatly refuse to belive or even
do simple checks. You like many seem to be to stupid to belive
that BICOM for example can work with any byte size file for
input or output. I have explained more than once that even for
a simple one byte file of your choice. That it could have been
encrypted from any one of a pool of 2**256 files. But you not
only fail to belive it. When I suggest just trying 300 different
key to show you that they map to 300 different files. Its to
much for you to belive. So cut the crap. If you can't even
grasp the simple basics what chance is there for your mind
to accept anything that is true. Yes if Wagner states it you
might belive it even if its a lie since you really don't want
to think.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: truth+integrity=sore losers
Date: 22 May 2001 16:23:59 GMT
[EMAIL PROTECTED] (Douglas A. Gwyn) wrote in <[EMAIL PROTECTED]>:
>"SCOTT19U.ZIP_GUY" wrote:
>> ... If you piss one then the enemy of that group likes you.
>
>Except they probably don't trust you at that point.
But at least they have an estimate of where they can
trust you. Since when does complete trust have to do with
anything. Example they may trust me to help design weapons
that kill becasue of my interest in science. But they
wont trust me to shoot mothers holding babys. It takes
a specail person to do that. In the FBI the one who shoot
the mother holding the baby at Rubyridge was so rare they
needed him at Waco since agian you have many mothers with
babys. But would you trust him to baby sit your kids.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: "computationally impossible" and cryptographic hashs
Date: Tue, 22 May 2001 09:32:56 -0700
Daniel Graf <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> I have a basic question about cryptographic hashes. A friend
> and I were talking about how the hash algorithm used some UNIX
> machines uses only 64 (or so) bits of the password.
> Now, I don't know much of anything about cryptography, but I
> have used hash algorithms for use with hash-tables. Are
> cryptographic hashes mostly dissimilar, or am I wrong in guessing that
> more than one input at a Unix login prompt may match the string found
> in the passwd file? (particularly for passwords greater than 8
> characters).
> Looking at the sci.crypt faq I found in section 7.1 something
> which says:
>
> For some one-way hash functions it's also computationally
> impossible to determine two messages which produce the
> same hash.
Here's a chance for me to stick my neck out and maybe
get corrected and thereby learn. I believe that what is referred
to here is the use of processes that are inherently "one-way"
Practically, there is no gaurd at the door that say's you can't
run it backwards, it's just that the processes are of a nature that
running them backwards is indeterminant e.g Forwards = one solution
and backwards from a solution = many equiprobable beginnings
where the chance of finding a different desired beginning becomes
trial and error selection from a really big pool.
>
> Does "computationally impossible" mean literally that such a
> thing cannot happen?
I believe it could happen by chance but not by any constructed
process taking less time than chance.
Paul
>
> Sorry if this is such a stupid question.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: "computationally impossible" and cryptographic hashs
Date: 22 May 2001 16:37:18 GMT
Daniel Graf <[EMAIL PROTECTED]> wrote:
> Now, I don't know much of anything about cryptography, but I
> have used hash algorithms for use with hash-tables. Are
> cryptographic hashes mostly dissimilar, or am I wrong in guessing that
> more than one input at a Unix login prompt may match the string found
> in the passwd file? (particularly for passwords greater than 8
> characters).
Your intuition is fairly good. A hash function reduces an input (which
crypto types call the `preimage') to a fixed-sized output. We usually
intend that collisions -- two preimages which have the same output --
don't happen very often. In a standard hashtable, a collision means
that there are more items to search through once we've found the right
hash bucket (or we hash again, or whatever). Decent hash functions tend
to have the property that they behave a bit `randomly'.
Cryptographic hash functions are the same only much more so. We require
that it's very hard for someone evil to construct a collision, because
we tend to use hashes as short identifiers for things (e.g.,
cryptographic keys, or messages to be signed), and bad things can happen
if we can be tricked into thinking that a hash corresponds to the wrong
preimage.
More strongly, we like cryptographic hash functions to behave like
randomly-chosen functions, although this isn't actually possible for any
particular publically-specified function.
You're also not wrong in guessing that it's possible for two Unix
passwords to have the same hash. However, I don't think anyone's
actually found such a pair yet. ;-)
> Does "computationally impossible" mean literally that such a
> thing cannot happen?
No. It means that doing the computation takes far too long; i.e., it's
`impossible' for a `computationally'-bounded adversary.
It's not a very good choice of words, really. We tend to use words like
`intractible' or `infeasible', or just `difficult' or `hard'.
`Impossible', like `perfect', is a word we tend to reserve for special
occasions.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: free/open source cryptography vs closed source FAQ
Date: 22 May 2001 16:34:06 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in
<[EMAIL PROTECTED]>:
>>
>> Its true its best to go with open source. But I think the
>> average person will be tricked into using a poor unsafe version.
>> However there are things one can do to minimize the chance of
>> getting a unsecrue encryption. One way would be to use 2 encryptions
>> methods in series that add no information during the encryption.
>
>What are you alluding to here? Why are "most people tricked into
>using unsafe open source crypto"?
>
Maybe you could anwser this for your self your one of these
who seems a sucker for weak encryption mehtods as long as there
are blessed by the crypto gods or that you think are so blessed.
>> There are very few open source encryption methods that don't
>> add information during encryption. If you belive the hype about
>> Rijndael being safe. Then about the only version of it that does
>> not add infomation is BICOM by matt Timmermans.
>
>Why is BICOM safer than a theoretical CTR mode version of AES?
>(Theoretical in assuming all the keys are random,etc.. no
>implementation flaws).
Ok Tom be an ass. I have answered this over and over. But you
really don't give a shit. So lets start a thread and if you pay
attension I will show you why BICOM is more secure than some
crapy implimention of CTR mode with RIJNDEAL. So let start.
First lets look at what your claiming for the theortical
implementaion of CTR is. Suppose I used you model (whatever
the hell that) suppose I have recieved a one byte file.
How do I decrypt it. I only have the code and the Key
explain your model since its so hot.
Again if not to difficlut exaplin first how do I decrypt
this one byte file I have recieved that was encrypted with
your PROPER implimentation. OR do you wish to just rant on
and make an ass out of yourself as usual.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: "computationally impossible" and cryptographic hashs
Date: Tue, 22 May 2001 09:44:07 -0700
Mark Wooding <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Daniel Graf <[EMAIL PROTECTED]> wrote:
>
> > Now, I don't know much of anything about cryptography, but I
> > have used hash algorithms for use with hash-tables. Are
> > cryptographic hashes mostly dissimilar, or am I wrong in guessing that
> > more than one input at a Unix login prompt may match the string found
> > in the passwd file? (particularly for passwords greater than 8
> > characters).
>
> Your intuition is fairly good. A hash function reduces an input (which
> crypto types call the `preimage') to a fixed-sized output. We usually
> intend that collisions -- two preimages which have the same output --
> don't happen very often. In a standard hashtable, a collision means
> that there are more items to search through once we've found the right
> hash bucket (or we hash again, or whatever). Decent hash functions tend
> to have the property that they behave a bit `randomly'.
>
> Cryptographic hash functions are the same only much more so. We require
> that it's very hard for someone evil to construct a collision, because
> we tend to use hashes as short identifiers for things (e.g.,
> cryptographic keys, or messages to be signed), and bad things can happen
> if we can be tricked into thinking that a hash corresponds to the wrong
> preimage.
>
> More strongly, we like cryptographic hash functions to behave like
> randomly-chosen functions, although this isn't actually possible for any
> particular publically-specified function.
I notice you said "behave like randomly-chosen functions" and
not "behave like a function that produces random output" Could
you expand on this a bit? Why is this a desirable property and
what does it get you?
Thanks,
Paul
>
> You're also not wrong in guessing that it's possible for two Unix
> passwords to have the same hash. However, I don't think anyone's
> actually found such a pair yet. ;-)
>
> > Does "computationally impossible" mean literally that such a
> > thing cannot happen?
>
> No. It means that doing the computation takes far too long; i.e., it's
> `impossible' for a `computationally'-bounded adversary.
>
> It's not a very good choice of words, really. We tend to use words like
> `intractible' or `infeasible', or just `difficult' or `hard'.
> `Impossible', like `perfect', is a word we tend to reserve for special
> occasions.
>
> -- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: "computationally impossible" and cryptographic hashs
Date: 22 May 2001 17:03:56 GMT
Paul Pires <[EMAIL PROTECTED]> wrote:
> I notice you said "behave like randomly-chosen functions" and not
> "behave like a function that produces random output" Could you expand
> on this a bit? Why is this a desirable property and what does it get
> you?
To my mind, a `function that produces random output' isn't a real
function -- it doesn't behave deterministically, but instead returns
random values. However, a randomly-selected function most definitely
is deterministic.
>From another point-of-view, however, I think they mean the same thing.
It depends on how your mental model works. If you think of functions as
being tables telling you what the result is for each input, then a
randomly-chosen function is just one where you filled in the table at
random. I suppose you could argue that `a function which produces
random output' really means a function which, given an input, sees
whether it already has an entry in the table: if so, it returns the
value there; otherwise it makes one up at random, puts it in the table
and returns it. These are different ways of thinking about the same
thing.
-- [mdw]
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
