Cryptography-Digest Digest #168, Volume #14 Tue, 17 Apr 01 14:13:01 EDT
Contents:
Re: Reusing A One Time Pad (SCOTT19U.ZIP_GUY)
Re: Reusing A One Time Pad ("Tom St Denis")
Re: Reusing A One Time Pad (SCOTT19U.ZIP_GUY)
Re: Note on combining PRNGs with the method of Wichmann and Hill ("Brian Gladman")
Re: Reusing A One Time Pad ("Tom St Denis")
Re: Reusing A One Time Pad (SCOTT19U.ZIP_GUY)
Re: Reusing A One Time Pad ("Tom St Denis")
Re: Choosing a Smartcard/Crypto Chip for PKI on Win2K ("Ryan Phillips")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Reusing A One Time Pad
Date: 17 Apr 2001 17:04:59 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in
<4u_C6.31062$[EMAIL PROTECTED]>:
>
>"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> [EMAIL PROTECTED] (Joseph Ashwood) wrote in
>> <ePD6covxAHA.328@cpmsnbbsa07>:
>>
>> >The moment you reuse *any* portion of the pad, the security
>> >immediately falls to precisely 0. That's a simple fact of life
>> >(assuming you are using a standard XOR based pad). There is no
>> >getting around that, no amount of postulating will get around the
>> >mathematic problems involved, your idea is plain and simply insecure.
>> > Joe
>>
>> Actually the security is not ZERO. You may have reduced the
>> ppssible set of the messages but as long as there is more than
>> one plausble decryption it is not zero. But I agree the more
>> you use the less secure and its not to had to reach ZERO.
>> Especailly if the plain text file was known to be compressed
>> as part of the encryption package as in PGP.
>
>Um to disprove anything you have said for the past 8 years or so.. an
>OTP is secure even if the message was compressed with deflate..... so
>tell me again how the compression hurts?
>
I don't wish to get in a long argument with you since you really
don't want to learn. But I will clarify what I think your
misunderstanding is. First of all we both know that a OTP is secure.
Joe was commenting that if you repeat one bit its not secure at all.
We all know or should know that if you use it over and over again its
not secure. IF a "one time Pad" is used correctly. Meaning "one time"
then the encryption is secure regardless of what compression was used.
As to weakness of using nonbijecetive file compression in encryption
systems I think you know where I stand on that after years of trying
to get you to understand it.
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: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Tue, 17 Apr 2001 17:19:22 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Tom St Denis) wrote in
> <4u_C6.31062$[EMAIL PROTECTED]>:
>
> >
> >"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
> >> [EMAIL PROTECTED] (Joseph Ashwood) wrote in
> >> <ePD6covxAHA.328@cpmsnbbsa07>:
> >>
> >> >The moment you reuse *any* portion of the pad, the security
> >> >immediately falls to precisely 0. That's a simple fact of life
> >> >(assuming you are using a standard XOR based pad). There is no
> >> >getting around that, no amount of postulating will get around the
> >> >mathematic problems involved, your idea is plain and simply insecure.
> >> > Joe
> >>
> >> Actually the security is not ZERO. You may have reduced the
> >> ppssible set of the messages but as long as there is more than
> >> one plausble decryption it is not zero. But I agree the more
> >> you use the less secure and its not to had to reach ZERO.
> >> Especailly if the plain text file was known to be compressed
> >> as part of the encryption package as in PGP.
> >
> >Um to disprove anything you have said for the past 8 years or so.. an
> >OTP is secure even if the message was compressed with deflate..... so
> >tell me again how the compression hurts?
> >
>
> I don't wish to get in a long argument with you since you really
> don't want to learn. But I will clarify what I think your
> misunderstanding is. First of all we both know that a OTP is secure.
> Joe was commenting that if you repeat one bit its not secure at all.
> We all know or should know that if you use it over and over again its
> not secure. IF a "one time Pad" is used correctly. Meaning "one time"
> then the encryption is secure regardless of what compression was used.
>
> As to weakness of using nonbijecetive file compression in encryption
> systems I think you know where I stand on that after years of trying
> to get you to understand it.
Um even if I use the super evil deflate (which compresses more effectively
then bijective huffman) and a true OTP then it's provably secure. You can't
argue that!
Tom
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Reusing A One Time Pad
Date: 17 Apr 2001 17:17:19 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in
<Qu_C6.31064$[EMAIL PROTECTED]>:
>
>"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote in
>> <[EMAIL PROTECTED]>:
>>
>> >[EMAIL PROTECTED] (Joseph Ashwood) wrote in
>> ><ePD6covxAHA.328@cpmsnbbsa07>:
>> >
>> >>The moment you reuse *any* portion of the pad, the security
>> >>immediately falls to precisely 0. That's a simple fact of life
>> >>(assuming you are using a standard XOR based pad). There is no
>> >>getting around that, no amount of postulating will get around the
>> >>mathematic problems involved, your idea is plain and simply
>> >>insecure.
>> >> Joe
>> >
>> > Actually the security is not ZERO. You may have reduced the
>> >ppssible set of the messages but as long as there is more than
>> >one plausble decryption it is not zero. But I agree the more
>> >you use the less secure and its not to had to reach ZERO.
>> >Especailly if the plain text file was known to be compressed
>> >as part of the encryption package as in PGP.
>> >
>>
>> Sorry for poor wording but by compressed I meant if one
>> is using a poor nonbijective compression as what is commonly
>> used in products such as PGP.
>
>Again, why are you targetting PGP? Just because Nai can write a program
>that you can't (who knows why) doesn't mean you should belittle everyone
>else.
>
Again. I know you like long threads that go no where. But for those
that don't yet know my views. I will explain and let you rant on with
replying since you really don't want to know why.
I like the concept of PGP. But there are many things in it that
to me make it less secure. I can see having a validity check if
one wants one. But the encryptor should have the option of putting
it in or not and weather or not to use a second password for it.
Also if there is a check it should involve the whole
encrypted data set and not the first few bytes of encrypted data
as in PGP. Secondly when encrypting a file my feelings are one should
use a compression scheme that adds no information to the encrypted
data making it harder for an attacker to know if he has the correct key.
You seem to steak all sercurity on the assumption that there is not
other break than a dumb brute force seach. This is exactly the same
reasoning the germans used on Engima and they were wrong. There
is no proof that a break of AES does not exist. You can belive
in you heart there is none and that all other aspects of security
can be dropped. Or you can worry there might be and use whatever
other methods would not lessen the secruity of the system.
You can reply if you want. I am sure you will. But I hope some
day to see a PGP that does its best to add more security.
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: "Brian Gladman" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Note on combining PRNGs with the method of Wichmann and Hill
Date: Tue, 17 Apr 2001 18:34:11 +0100
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Brian Gladman wrote:
> >
> > "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote:
>
> > If you read my earlier posts you will see that I have already said that
> > adding two generators with multipliers of 1.0 and taking the result 'mod
> > 1.0' will be uniform. This was never in doubt. The issue is not this
but
> > rather that of what happens when two such generators are added with
> > multipliers that are both close to, but different from, 1.0.
>
> Well, I suppose it is evident that as the multipliers
> approaches 1.0, the result will also approach that for
> the case with multipliers exactly equal to 1.0. This
> is from simple 'continuity' considerations. Thus your
> previous claim that using small deviations from 1.0 will
> lead to very large non-uniformness clearly cannot hold.
The phrase 'very large non-uniformness' is entirely your own
misrepresentation of what I said. I used the phrase 'very non-uniform', by
which I meant that the non uniformity would be obvious. In other words, the
results would deviate so far from uniformity that the differences would be
evident from simple inspection without the need for more advanced
statistical tests to find them. And this is exactly what the data below
shows.
> > For example, here is the result of 10,000,000 trials for each of 3
PRNGs,
> > two uniform generators, A and B, and a third C, which is (0.9 * A + 1.1
* B)
> > mod 1.0:
> >
> > range gen A gen B gen C
> > [0.0:0.1) -> 999970 999545 958872
> > [0.1:0.2) -> 999207 1002146 1009123
> > [0.2:0.3) -> 998672 999233 1009761
> > [0.3:0.4) -> 1000023 999415 1009993
> > [0.4:0.5) -> 1000984 999239 1009305
> > [0.5:0.6) -> 1001546 1000377 1010543
> > [0.6:0.7) -> 998803 998860 1010898
> > [0.7:0.8) -> 1000290 999234 1008644
> > [0.8:0.9) -> 1001218 1000259 1011547
> > [0.9:1.0) -> 999287 1001692 961314
> >
> > Notice that the first and last intervals for the combined generator (C)
are
> > significantly less populated than the other eight - these intervals are
> > respectively about 0.96 and 1.01 times the frequency expected from a
uniform
> > generator.
>
> You have to study uniformity with standard statistical
> methods. I suppose that the chi-square test is useful
> for that. There must be a sufficient sample size in
> order to be able to obtain reasonable results. Small
> sample size cannot provide useful data in the sense of
> statistics. (The FIPS tests, for example, need quite a
> bit of data, even though someone in the group considered
> the amounts to be too small.)
It is not necessary to use statistical tests to see that generator C's data
above is not uniformly distributed. I am confident that, after 10,000,000
tests, the probability of getting the above distribution by chance is very
small.
I am confident in this result without the need for a formal test but you are
free to run one if you want to prove that my confidence is misplaced.
Brian Gladman
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Tue, 17 Apr 2001 17:40:03 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I like the concept of PGP. But there are many things in it that
> to me make it less secure. I can see having a validity check if
> one wants one. But the encryptor should have the option of putting
> it in or not and weather or not to use a second password for it.
> Also if there is a check it should involve the whole
> encrypted data set and not the first few bytes of encrypted data
> as in PGP. Secondly when encrypting a file my feelings are one should
> use a compression scheme that adds no information to the encrypted
> data making it harder for an attacker to know if he has the correct key.
> You seem to steak all sercurity on the assumption that there is not
> other break than a dumb brute force seach. This is exactly the same
> reasoning the germans used on Engima and they were wrong. There
> is no proof that a break of AES does not exist. You can belive
> in you heart there is none and that all other aspects of security
> can be dropped. Or you can worry there might be and use whatever
> other methods would not lessen the secruity of the system.
> You can reply if you want. I am sure you will. But I hope some
> day to see a PGP that does its best to add more security.
You have yet to prove that bijective compression is any more secure. In
fact it's not. Let's demonstrate. I get a message from you and I want to
try decrypting it. Say you use a 64-bit RC5 key or something... I feel
it's about money so amongst the ciphertexts I decrypt I get
AKSJHDKH2309SLDFJSDFHSFJKGHW
DFGJSHSKFHKJ2340OWE7FKJFSD
THE MONEY IS IN MY POCKET
345U3RWHERFRLSJFHKJGFYSUKJFTHSJK
DFGJLHGJKHGDFJKGHDFKJGDGJDFLK349
Hmm... I wonder which one it is... there are only 2^64 possible decryptions
(despite the claim that 1-1 is exponential in time with filesize that is not
true). All I have todo is go thru all 2^64 decryptions and flag the keys
that lead to english messages that make sense and have the word money.
Assume we use upper+digits (36 digits) the chance of getting the word MONEY
is 1 in 36^5 or 2^-26. That means I can throw away alot of keys off the
top when they don't include the word I want...
etc...
I await proof otherwise.
Tom
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Reusing A One Time Pad
Date: 17 Apr 2001 17:54:39 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in
<uW_C6.31194$[EMAIL PROTECTED]>:
>
>"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> [EMAIL PROTECTED] (Tom St Denis) wrote in
>> <4u_C6.31062$[EMAIL PROTECTED]>:
>>
>> >
>> >"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>> >news:[EMAIL PROTECTED]...
>> >> [EMAIL PROTECTED] (Joseph Ashwood) wrote in
>> >> <ePD6covxAHA.328@cpmsnbbsa07>:
>> >>
>> >> >The moment you reuse *any* portion of the pad, the security
>> >> >immediately falls to precisely 0. That's a simple fact of life
>> >> >(assuming you are using a standard XOR based pad). There is no
>> >> >getting around that, no amount of postulating will get around the
>> >> >mathematic problems involved, your idea is plain and simply
>> >> >insecure.
>> >> > Joe
>> >>
>> >> Actually the security is not ZERO. You may have reduced the
>> >> ppssible set of the messages but as long as there is more than
>> >> one plausble decryption it is not zero. But I agree the more
>> >> you use the less secure and its not to had to reach ZERO.
>> >> Especailly if the plain text file was known to be compressed
>> >> as part of the encryption package as in PGP.
>> >
>> >Um to disprove anything you have said for the past 8 years or so.. an
>> >OTP is secure even if the message was compressed with deflate..... so
>> >tell me again how the compression hurts?
>> >
>>
>> I don't wish to get in a long argument with you since you really
>> don't want to learn. But I will clarify what I think your
>> misunderstanding is. First of all we both know that a OTP is secure.
>> Joe was commenting that if you repeat one bit its not secure at all.
>> We all know or should know that if you use it over and over again its
>> not secure. IF a "one time Pad" is used correctly. Meaning "one time"
>> then the encryption is secure regardless of what compression was used.
>>
>> As to weakness of using nonbijecetive file compression in
>> encryption
>> systems I think you know where I stand on that after years of trying
>> to get you to understand it.
>
>Um even if I use the super evil deflate (which compresses more
>effectively then bijective huffman) and a true OTP then it's provably
>secure. You can't argue that!
I can argue with your statments about the "super evil deflate".
Being better. Compression is a lose lose situation. It is well known
for certain classes of files Huffman would be the optimal. I don't think
that can be said for deflate for any class of files.
However on most testfiles of interest that some one would likely
use it appears defalte usually wins. However if your looking for
a better compressor for most likely used files try Matts Bicom or
Biacode they make delfate look sick.
One reason delfate can not compress very well is that it
does not make full use of the binary file space it is trying to
compress to. I suspose one could fix that but then you would still
bitch that making it better by making it bijective would be a waste
of time even if the resulting compression makes it smaller. For others
out there not Tom since he can't see this. The reason delate could
not be optimal for any class of files that one is compressing to
a binary file is this. Lets assume it is opitmal for some clasee of
files. Then if it is optimal and it is compressing to the set of 8-bit
binary files. Every finte possible byte file should be the result of
some file that was copressed. Since its easy to test this one gets
files that can't be the result of some compression. This means that
since certain binary byte file combinations are not really in the
compressed sets means defalate can'b be optimal for anything since
it leaves gaps in the compressed space. I think most can see this.
Also when one does the compression and then encrypts. When one is
testing the wrong "key" you end up usually with a file that can't
be uncompressed. Which means the bad compression makes it easyer for
an attacker to rule out large classes of keys.
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: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Tue, 17 Apr 2001 18:03:57 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I can argue with your statments about the "super evil deflate".
> Being better. Compression is a lose lose situation. It is well known
> for certain classes of files Huffman would be the optimal. I don't think
> that can be said for deflate for any class of files.
There are no classes of files where huffman is optimal. If the file has a
bias towards a certain symbol more than likely it's in some pattern.
> However on most testfiles of interest that some one would likely
> use it appears defalte usually wins. However if your looking for
> a better compressor for most likely used files try Matts Bicom or
> Biacode they make delfate look sick.
Um, deflate is a general purpose standard algorithm. Just like JPEG, sure
there are "higher compression codecs" out there but jpeg is a stanard...
deflate compresses well, is open source, well understood, free, fast, small,
portable, which is more than I could say about your code.
> One reason delfate can not compress very well is that it
> does not make full use of the binary file space it is trying to
> compress to. I suspose one could fix that but then you would still
> bitch that making it better by making it bijective would be a waste
> of time even if the resulting compression makes it smaller. For others
> out there not Tom since he can't see this. The reason delate could
> not be optimal for any class of files that one is compressing to
> a binary file is this. Lets assume it is opitmal for some clasee of
> files. Then if it is optimal and it is compressing to the set of 8-bit
> binary files. Every finte possible byte file should be the result of
> some file that was copressed. Since its easy to test this one gets
> files that can't be the result of some compression. This means that
> since certain binary byte file combinations are not really in the
> compressed sets means defalate can'b be optimal for anything since
> it leaves gaps in the compressed space. I think most can see this.
> Also when one does the compression and then encrypts. When one is
> testing the wrong "key" you end up usually with a file that can't
> be uncompressed. Which means the bad compression makes it easyer for
> an attacker to rule out large classes of keys.
This is total bs. A deflate codec can output any binary digit, 0 and even
the infamous 1.
ARRG you make no sense.... compression is a method of reducing the storage
required for a message, NOTHING MORE. Why can't you see that?
Sure deflate is not optimal for 7 bit streams (technically deflate doesn't
encode files...) it's designed as a general purpose system where the typical
message is larger than a single byte.
And finally, why do you think being able to throw away keys is a way to help
attackers? If there are 2^256 possible keys... even if you could throw away
2^96 keys a second you would wither away and turn into space dust before the
key is found...
Tom
------------------------------
From: "Ryan Phillips" <[EMAIL PROTECTED]>
Subject: Re: Choosing a Smartcard/Crypto Chip for PKI on Win2K
Date: Tue, 17 Apr 2001 11:08:26 -0700
ibuttons are cool.
www.ibutton.com
""Miguel Almeida"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi!
>
> I'm trying to select a crypto chip to put on a Smartcard for a
medium-sized
> PKI implementation. Because the project assumes a custom card with other
> features besides the crypto chip, we're not considering the ready-to-use
> solutions from several vendors (which include both the cards and the
> software for the PKI).
>
> The software infrastructure will most probably be based on a custom
solution
> mixed with the Microsoft Windows 2000 PKI.
>
> My question is: knowing there are several chips on the market and given
> we're using W2K, security features aside, which chips/readers would you
> recommend to assure hardware/driver/w2k compatibility? Or do the current
> offers imply a chip/infrastructure-software bond?
>
> (please cc: any answers to [EMAIL PROTECTED])
>
> Thanks in advance
> --
> Miguel Almeida
> [EMAIL PROTECTED]
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
>
> --
> Posted from [212.18.191.61] by way of f72.law4.hotmail.com [216.33.149.72]
> via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
** 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
******************************
