Cryptography-Digest Digest #5, Volume #13 Thu, 26 Oct 00 10:13:01 EDT
Contents:
Re: Hardware RNGs (Tom St Denis)
Re: Is OPT the only encryption system that can be proved secure? ("Peter
Thorsteinson")
Re: How do I detect invalid passwords? (Jeffrey Williams)
Re: Is OPT the only encryption system that can be proved secure? ("Peter
Thorsteinson")
Re: Visual Basic (those who know me have no need of my name)
Re: Is OPT the only encryption system that can be proved secure? (John Savard)
Re: DATA PADDING FOR ENCRYPTION (John Savard)
Whitening necessary? ([EMAIL PROTECTED])
Re: Factoring Polynomials (Simon Johnson)
Re: Is OPT the only encryption system that can be proved secure? (Simon Johnson)
Re: How do I detect invalid passwords? (SCOTT19U.ZIP_GUY)
Re: How do I detect invalid passwords? (SCOTT19U.ZIP_GUY)
Re: Save RSA bandwidth (John Savard)
Re: Is OPT the only encryption system that can be proved secure? (SCOTT19U.ZIP_GUY)
rc4 proprieties ("dexMilano")
Collision domain in crypt()? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: Thu, 26 Oct 2000 11:59:05 GMT
In article <[EMAIL PROTECTED]>,
Volker Hetzer <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > Cameron <[EMAIL PROTECTED]> wrote:
> > > Why don't you just use soundcard input?
> > > pipe it into a file. It should be pretty darned random.
> >
> > Um not really.
> Then use it (and the previous hash) as input to sha to get
> 160 bit of random data. Repead as needed.
The problem is that virtually of the lsb's on my comp are zeroes, with
a few ones... In fact last time I counted the ratio was about 7 to 1.
This means you need to gather about 100,000 bits before you can safely
have about 160 bits (using SHA-1). However, the problem gets
worse...you must sample very slowly, otherwise the samples are
correlated... Thus sample at about 8khz. At 8khz it will take 12.5
seconds to gather enough inputs....
Your best bet is to use a free-running timer and/or some other sources
(keyboard input+timing)...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Peter Thorsteinson" <[EMAIL PROTECTED]>
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Thu, 26 Oct 2000 12:12:58 GMT
> Define homologous ciphers.
Sorry, I am not using the word homologous in any technically precise way. I
am using the English word "homologous" in a descriptive way. What I mean by
homologous is the set of all ciphers that fall within the same class or
category in some sense. Vague, I agree, but the problem is that I do not
have a clue what I really want to mean by "fall within the same class in
some sense". This is actually my question! But an example that might help
clarify this would be the set of all ciphers that are equivalent in an
entropy sense.
------------------------------
From: Jeffrey Williams <[EMAIL PROTECTED]>
Subject: Re: How do I detect invalid passwords?
Date: Thu, 26 Oct 2000 07:17:42 -0500
"SCOTT19U.ZIP_GUY" wrote:
> <snip>
> >B. How do I detect an incorrect password? I don't want to decrypt the
>
> If you really want to do this I would encrypt the password
> the user entered the first time. When the user enters a password
> to get his data decypt the file that has his encrypted password
> if they match then his in. But I would make this a very slow
> operation if he guesses wrong so that he can't sit there and guess
> quickly. That is if you do it at all I think not doing anything
> and giving him garbage may be best.
>
<snip>
I respectfully disagree. You want to know whether the password was invalid.
Then you have the option, for example, of saying "Hey bozo, you've given me
three consecutive invalid passwords - go away for a while". If you don't
know
that the password is invalid, I can sit there for hours and try different
passwords
until, maybe, one succeeds.
I do like the idea of storing the initial password in the encrypted data.
Possibly it
might be safer to store the userid rather than the password as, presumably,
that is
public data (and if I have to have copies of data items, I'd rather use
public data
items rather than private).
Jeff
------------------------------
From: "Peter Thorsteinson" <[EMAIL PROTECTED]>
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Thu, 26 Oct 2000 12:18:37 GMT
> There are an infinity of systems which meet this criterion - not just an
> XOR-based OTP.
Thanks. That's more of what I am looking for. I suspected that there are an
infinity of systems which meet this criterion. Perhaps they are all
equivalent in an entropy sense? I guess no commercially used ciphers are
equivalent in an entropy sense, except those that compose them wit an OTP
equivalent.
> OTPs don't generally have good security properties, due to poor key
> distribution properties - which helps explain their relative neglect.
Key distribution properties... ya, that reality thing always interferes,
doesn't it...
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: Visual Basic
Date: Thu, 26 Oct 2000 12:22:01 -0000
<8t0o9h$[EMAIL PROTECTED]> divulged:
>different languages shine in different
>situations. C make a lousy Perl, for example.
actually ...
nah, never mind, this is already way too far from sci.crypt.
--
okay, have a sig then
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Thu, 26 Oct 2000 12:18:07 GMT
On Wed, 25 Oct 2000 23:27:56 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>The mathematically-proven OTP depends upon various assumptions which
>cannot be provably achieved in practice. And proof based on
>unprovable assumptions is ultimately no proof at all.
Although it is important to note that the OTP is subject to the
bit-flipping attack, beyond this, I've tended to find this statement
about the OTP as unhelpful, perhaps even annoying.
But now I've finally figured out _why_ it bothers me.
If we say that the OTP isn't "really" proven secure, because you can't
prove that an eavesdropper hasn't somehow gotten hold of your key...
then we _must_ say the same about all other cryptosystems.
The proof:
A cryptographic system is a method of transforming a plaintext P into
a ciphertext C.
There must also exist a transformation by which the ciphertext C can
be transformed into the corresponding plaintext P in the posession of
the legitimate recipient of the message.
Hence, for any cryptographic system, there exists a method of decoding
messages, and it is known to the legitimate recipient fo the message.
Hence, any cryptographic system has a "key", even if the algorithm is
the key in defiance of Kerckhoffs. If the existence of a key means
that it cannot be proven that the key cannot be lost or stolen, then
_all_ cryptosystems have the same problem as you identify for the OTP.
Of course, if they ever come up with a provably-secure public-key
system _the private key of which can be memorized_ and _the
computations for which can be carried out in one's head_, then subject
to the assumption that reading minds is impossible (which is a
reasonable assumption, since if it is false, it is impossible to keep
secrets anyways) then there would be a system to which my proof does
not apply.
I am _not_ holding my breath; even secure symmetric-key algorithms
with memorizable keys that can be carried out mentally are highly
unlikely to be forthcoming.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: DATA PADDING FOR ENCRYPTION
Date: Thu, 26 Oct 2000 12:08:09 GMT
On 25 Oct 2000 20:50:33 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote, in part:
> I did a search of the internet for IEEE encryption padding
>I could not find much but below is a cutout of what was
>typically found
>http://www.google.com/search?q=cache:www.security.ece.orst.edu/documents/P1
>363/12S_9403.txt+IEEE+padding+during+encryption+01+0202+030303&hl=en
If one goes straight to
http://www.security.ece.orst.edu/documents/P1363/12S_9403.txt
there is still a document there, one doesn't have to resort to the
Google cache.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Whitening necessary?
Date: Thu, 26 Oct 2000 12:40:32 GMT
I use Rijndael in CBC mode with unique IV's. Would pre- /or
postwhitening (through simple xor for example) make the encryption
stronger? And if yes, against what kind of attack would it make it
stronger than if I just used the implementation described above.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Factoring Polynomials
Date: Thu, 26 Oct 2000 12:36:17 GMT
In article <8t83m9$fii$[EMAIL PROTECTED]>,
Bob Silverman <[EMAIL PROTECTED]> wrote:
> In article <8t7nr1$65g$[EMAIL PROTECTED]>,
> Simon Johnson <[EMAIL PROTECTED]> wrote:
> > Is factoring polynomials also an NP problem for large order
> > polynomials just as factoring an integer is?
>
> You seem to have a bit of confusion. Both problems are trivially
> in NP.
>
> You can not mean NP-Complete in place of NP, because factoring
integers
> is not known to be NP-Complete. Nor is it known to be in P.
>
> OTOH factoring polynimials is known to be in P (polynomial in the
> degree; not in the size of the coefficients)
>
> What do you really mean here????
>
> --
> Bob Silverman
> "You can lead a horse's ass to knowledge, but you can't make him
think"
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Once again, my english is non-sensical. What i'm trying to establish is
that wether or not factoring a polynomial is NP or not.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Thu, 26 Oct 2000 12:47:28 GMT
In article <SHJJ5.39299$[EMAIL PROTECTED]>,
"Peter Thorsteinson" <[EMAIL PROTECTED]>
wrote:
> This much I know:
> Currently, it is commonly accepted that the xor-based one time pad
(OTP) is
> the only perfectly secure cipher encryption system that has been
> mathematically proven impregnable by way of cryptanalysis.
It doesn't have to be XOR, it can be any operator that doesn't bias
either operand and operates in a finite field.(XOR IS ADDITION OF BITS
MOD 2)
>No other
> encryption systems currently in the public knowledge have been proven
> secure.
This is untrue, most secret sharing schemes are unbreakable. In fact
the OTP is a special case of a secret sharing scheme.
> Now, my question is:
> Has there been any mathematical proof developed that shows that the
OTP is
> the only encryption system that can be provably secure. If anyone
knows of
> any references, I would much appreciate it.
Its not hard, Every key is equally likely to occur. Since the cipher-
text is the XOR of the key and the plain-text, this makes every cipher-
text equally as likely. Therefore, if we treat the plain-text as an XOR
of the cipher-text and the key. If all keys and all cipher-texts are
equally probable, then so is the plain-text. This makes the OTP
unbreakable because one cannot decide which plain-text is correct
because every possible plain-text is equally likely.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: How do I detect invalid passwords?
Date: 26 Oct 2000 13:40:17 GMT
[EMAIL PROTECTED] (Jeffrey Williams) wrote in
<[EMAIL PROTECTED]>:
>
>"SCOTT19U.ZIP_GUY" wrote:
>
>> <snip>
>> >B. How do I detect an incorrect password? I don't want to decrypt the
>>
>> If you really want to do this I would encrypt the password
>> the user entered the first time. When the user enters a password
>> to get his data decypt the file that has his encrypted password
>> if they match then his in. But I would make this a very slow
>> operation if he guesses wrong so that he can't sit there and guess
>> quickly. That is if you do it at all I think not doing anything
>> and giving him garbage may be best.
>>
>
><snip>
>
>I respectfully disagree. You want to know whether the password was
>invalid.
I am not exactly sure what you mean by the above. He knows the
password is invalid.
>
>Then you have the option, for example, of saying "Hey bozo, you've given
>me three consecutive invalid passwords - go away for a while". If you
>don't know
>that the password is invalid, I can sit there for hours and try
>different passwords
>until, maybe, one succeeds.
I did say to "make this a very slow operation" I think your
suggestion of allowing 3 guess then igrnoring him fits in that
range of possiblities
>
>I do like the idea of storing the initial password in the encrypted
>data. Possibly it
>might be safer to store the userid rather than the password as,
>presumably, that is
>public data (and if I have to have copies of data items, I'd rather use
>public data
>items rather than private).
I think public data is weaker since a userID may have certain
structure so that if a hacker gets a list of the encoded data
it may be easier to hack if they are all in the same format where
as that would not be the case if a encrypted password was used.
But I suppose two people could use the same password. So if someone
get a list of these files they may notice two people have the same
password. THese are tradeoffs the original programer will have to
make and yes there are many ways to do it.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: How do I detect invalid passwords?
Date: 26 Oct 2000 13:29:52 GMT
[EMAIL PROTECTED] wrote in <8t8ens$nta$[EMAIL PROTECTED]>:
>
>>A. Is there a better (i.e. safer) way to do this?
>>
>> Yes if password is shorter than the key
>> why bother to hash it at all. I assume you
>> are saving neither the hash or the password.
>> Also why use something fishy like blowfish
>> use the approved AES cipher would impress
>> your boss and customers more.
>
>You are right, I am saving neither the hash or the password. The reason
>I am planning on hashing the password is because most users will NOT
>enter a 16 byte password (i.e. 128-bit). Let say that the average
>person uses an 8-byte password. I don't want to pad the other 8-bytes
>with 0s or something else that is fixed. This would reduce the number
>of possible password combinations to 64-bits. I assume the hashing will
>help fix this. Is this right?
>
>> >B. How do I detect an incorrect password? I don't want to decrypt the
>>
>> If you really want to do this I would encrypt the password
>> the user entered the first time. When the user enters a password
>> to get his data decypt the file that has his encrypted password
>> if they match then his in. But I would make this a very slow
>> operation if he guesses wrong so that he can't sit there and guess
>> quickly. That is if you do it at all I think not doing anything
>> and giving him garbage may be best.
>
>Let's say I still use the hash, then should I:
>1. Get the password from the user.
>2. Hash the password.
>3. Encrypt the password from step 1 (not the hash) along with the data
>using the hash from step 2 as the key for the symettric cipher.
>4. When the user wants to access the data, he/she will give me a
>password.
>5. Take the password from step 4 and hash it.
>6. Use the hash to decrypt the password that I originally encrypted. If
>it is the same as the password that I got from the user in step 4, I
>will continue to encrypt the rest of the data. Otherwise, the password
>is invalid and quit.
>
I could see someone doing it this way. But Like I said I am not
a fan of hashing much. But I think your approach is sound.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Save RSA bandwidth
Date: Thu, 26 Oct 2000 13:42:31 GMT
Well, I've found a practical application for my scheme.
As I noted, some time back, I thought that PGP was inefficient,
because it enciphered a 128-bit key inside a large RSA block, then
using the 128-bit key to encipher the message. Why not put the first
piece of the message inside the RSA block, too?
Then I thought of a further improvement: divide the message into a
first 160-bit piece and the rest of the message. Hash the rest of the
message, and XOR the result with the first piece.
Use that result to encrypt the rest of the message.
Then put the first piece, and as much of the rest of the message as
will fit, inside the RSA block.
This way, the message provides the random number needed for the
session key, and you don't need to worry about your encryption program
choosing a bad random number!
Then I found out that an essentially similar scheme, but using DES
rather than a hash function, was already invented by Mihir Bellare,
and patented by IBM.
Well, the scheme I've outlined in my previous post, if used with _two_
public/private key pairs, can obtain the same result by a different
principle.
First bit of message: encrypt once with RSA. Produce from that result,
by a hash, the session key to encrypt the rest of the message
conventionally. Then, encrypt the result again with RSA, but using
one's slightly larger modulus.
Except for the slight increase in the length of the RSA block because
the two RSA moduli are different and neither one is a power of two -
one could keep that increase down to a single bit - one has managed to
send one's message without increasing its length to make room for a
session key.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: 26 Oct 2000 13:55:13 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>On Thu, 26 Oct 2000 00:14:31 GMT, "Peter Thorsteinson"
><[EMAIL PROTECTED]> wrote, in part:
>
>>What I would love to know is whether or not (theoretically)
>>there is no possible perfect cypher other than the OTP, and a
>>mathematical proof would be nice, but even just a citation rom a
>>recognized cryptography expert would do fine.
>
>Well, Claude Shannon did note that the theoretical OTP - or its
>equivalents, because one can devise a cipher which is not exactly the
>OTP, but which is the OTP in disguise - is the only cipher which can
>be proven to have _information-theoretic_ security.
>
>The proof no non-OTP cipher has this security is simple enough:
>
>If you have a ciphertext of N bits, enciphered by a system with fewer
>than 2^N possible keys, then by trying every single key, you have
>obtained fewer than 2^N plaintexts, which are the only possible
>plaintexts. Hence, you were able to gain information about the
>plaintext.
But Claude does talk about information theory and the fact
is most crypto systems including PGP are so poorly put together
that you really don't have more than "one" key that leads to a
possible solution. You do have some degree of proveable security
if more that one key can lead to a possible soultion to the
problem. Scott19u combined with my bijective compress is provably
secure in this sense because more than one key can lead to a
plausable soultion for a given cipher test where the key is used
only once. THis cannot be said for most cipher systems since
public open crypto no longer seems to care about Claude Shannon
information concerns and instead bases all hopes of security
on non provable mathematic hardness instead of provable information
concerns. I feel the rason this is true is becanse of the large
infulence on the open cyrpto community by such groups as the
NSA which do not want people to have secure crypto.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: "dexMilano" <[EMAIL PROTECTED]>
Subject: rc4 proprieties
Date: Thu, 26 Oct 2000 15:57:27 +0200
As a lot of you knows, is available on the web a source code for an rc4
compatible cipher.
I've worked on it making some modification.
I want to verify if, with these changes, the algoritm can be deployed to
public.
I know that rc4 is RSA's properties, but with changes? also the compatible
version?
Any suggestion will be appreciated.
dex
------------------------------
From: [EMAIL PROTECTED]
Subject: Collision domain in crypt()?
Date: Thu, 26 Oct 2000 14:08:10 GMT
What's the collision domain in a standard (Solaris) crypt() function?
I'm in need of a simple hash function for ~4 million items, with a digest of
approx 10-14 chars; MD5 et al at 32 characters is simply overkill. Am I
in the right ballpark?
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
