Cryptography-Digest Digest #77, Volume #9 Sat, 13 Feb 99 12:13:01 EST
Contents:
SFS & Iomega (Michael Hortmann)
Re: What is left to invent? (Gurripato (x=nospam))
Re: RNG Product Feature Poll (Dave Knapp)
Re: New high-security 56-bit DES: Less-DES (TONY BARTOLETTI)
Randomness based consciousness?. (Was: Re: *** Where Does The Randomness Come From
?!? *** ) (Seisei Yamaguchi)
Re: Tell-Tale DES Byte-Length Encoding ([EMAIL PROTECTED])
Re: Java random ("Else")
Re: New high-security 56-bit DES: Less-DES ("Steve Sampson")
Re: RNG Product Feature Poll (Herman Rubin)
Re: SCOTT COMPRESSION ([EMAIL PROTECTED])
Re: Metaphysics Of Randomness (R. Knauer)
Re: hardRandNumbGen (R. Knauer)
Re: RNG Product Feature Poll (R. Knauer)
Re: hardRandNumbGen (R. Knauer)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Michael Hortmann)
Crossposted-To: alt.security.pgp
Subject: SFS & Iomega
Date: Sun, 07 Feb 1999 09:47:19 +0100
I've been using Peter Gutmann's SFS (Secure File System)
for several years under DOS/Windows3.x/Windows95 to encrypt
a partition of my hard disks or diskettes. I'd really like
to use it for my Iomega ZIP and JAZ media, too.
Does anyone know of a way to do this?
Or is there another good cryptographic file system for
Windows95 which can be used instead?
Michael Hortmann
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Certified PGP Key http://www.trustcenter.de
------------------------------
From: [EMAIL PROTECTED] (Gurripato (x=nospam))
Subject: Re: What is left to invent?
Date: Fri, 12 Feb 1999 08:22:35 GMT
On Thu, 11 Feb 1999 01:09:43 -0600, [EMAIL PROTECTED] (wtshaw) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
>>
>> "It is not a matter of what is true that counts, but a matter of
>> what is perceived to be true."
>> --Henry Kissinger
I knew Kissinger had a PhD, but didn�t know it was on quantum
physics!
------------------------------
From: Dave Knapp <[EMAIL PROTECTED]>
Subject: Re: RNG Product Feature Poll
Date: Sat, 13 Feb 1999 09:36:33 GMT
R. Knauer wrote:
>
> On Fri, 12 Feb 1999 06:23:47 -0500, "Trevor Jackson, III"
> <[EMAIL PROTECTED]> wrote:
>
> >A white, uniform generator might work, but that phrase will
> >trigger a lot of questions of the form "please define white"
> >and "please definer uniform".
> I believe the term "uniform distribution" is well defined in
> statistics. However, as Li and Vitanyi point out in their book on
> Kolmogorov Complexity, it is not sufficient to characterize
> randomness.
That's why you _specify_ a *random* uniform generator, instead of just a
uniform generator.
Random implies no correlation, and uniform implies no bias.
Why are you guys making this so complicated?
I understand that it is difficult, a priori, to establish whether a
particular source is random or not. But that complexity does NOT affect
the _definition_ of "random," which is quite solid. There are many ways
to express it; but fundamentally, it means lack of correlation.
-- Dave
------------------------------
From: TONY BARTOLETTI <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: New high-security 56-bit DES: Less-DES
Date: Sat, 13 Feb 1999 09:40:08 GMT
[EMAIL PROTECTED] wrote:
>
> [EMAIL PROTECTED] wrote:
>
> > 2. To send a message to Alice, Bob forms the first part of his
> > desired message as a plaintext block of 64 bits:
> >
> > M1 = 0123...63
>
> I'd suggest the first block should carry 64-M bits of plaintext
> (like the others) and M bits of random padding, in order to
> resist known plaintext attack. If we can't add random bits, for
> fear they will be deemed "key", we could defend against partially
> known plaintext by taking the M-bit pad from a hash of the entire
> message.
>
> > The Less-DES protocol may answer concerns regarding possibly
> > diverging interpretations of export-free or WA terms -- since there
> > is no additional key in Less-DES, of any kind, not even ignored, when
> > security is enhanced from the 56-bit level.
>
> Alas, the way the regulations are implemented in the US, it's the
> government's interpretation that carries the day. The rules do not
> say that 56-bit or even 40-bit encryption systems are freely
> exportable, and neither does the latest statment of intentions to
> "relax" export restrictions.
>
> Instead, there's a "one-time review". The various agencies are under
> no obligation to permit export based on adhearence to the letter of
> the WA or even the agencies' own guidlines. If one wants to argue
> that a system falls within legal limits, he'll be making that argument
> to government cryptographers.
Yes, I tend to agree. They define what the rules mean, case-by-case.
But this argues for Ed's first (bit more cumbersome) proposal, M-DES.
Everyone just uses plain-old-already-approved DES. But there is an
"established" table of 2^14 64-bit "random" strings published.
I DES encrypt a message, but XOR all of the output blocks with one
string randomly selected from the set of 2^14. I tell no one which
string was used, only that I used "14-DES". Now everyone (attacker
and intended recipient alike) have 2^14 times as much effort to expend
as they did before, whatever the previous effort bias.
I don't see any realistic way to regulate this practice. Nor can I
see regulations on a "plug-in" filter that receives an M-DES message,
and cycles through the XOR-strings as it passes each trial to DES.
Its just too easy to write an XOR-machine and verify its correctness,
so no need for export concerns.
Of course, it may become a crime to deal in random numbers...
___tony___
------------------------------
From: [EMAIL PROTECTED] (Seisei Yamaguchi)
Crossposted-To:
sci.skeptic,sci.philosophy.meta,sci.psychology.theory,alt.hypnosis,sci.logic
Subject: Randomness based consciousness?. (Was: Re: *** Where Does The Randomness Come
From ?!? *** )
Date: 13 Feb 1999 12:05:26 GMT
Hi, this is Seisei.
In <79elv9$iuh$[EMAIL PROTECTED]>, peterdjones <[EMAIL PROTECTED]>
says...
>gdmvkzcexmgzczt
This pattern ``gdmvkzcexmgzczt'' looks like random
(inputted via general keyboard at ADy001999)
is caused by link-pattern of general cells of the brain.
Brain's general cells' link-pattern organize {
* Table (s) of {
disposition of {
* Fingers.
It is caused by at least DNA pattern.
* Keys of keyboard.
It is caused by at least the alphabet code.
}
} from signals always come from the interface.
* Pattern generating routine for wide use.
It is sure to {
* Refer to the disposition tables in the brain.
The eyes are exist for sending signals to brain.
* Influenced by signals come from
global network of the brain
as the character of person who generates pattern
(For example, ``gdmvkzcexmgzczt'' 's most letters is
two-lines' keys of general keyboard at ADy001999.
Sherlock Holmes may not overlook it
for image her|him|other) .
See the document of hypnosis as science.
}
}.
If the link ---adaptive network--- pattern of the brain cells
(include pattern generating routine (distributed system) )
is TRUE RANDOM,
it means our consciousness
---cells network organized from astronomical number of
pulses come from the interfase and self feedback system---
is controled by TRUE RANDOMNESS.
I think, coming soon the time to decide which one.
Our consciousness is {
* Randomness based.
* Causality based.
}.
And, mike, we'll hear singing voice from many workplaces and not
---in short, many places people staying--- ,
before AD0022nd century, perhaps. ":)"
--
Seisei Yamaguchi (name( first( $B@D@1(B ), last( $B;38}(B ) ))
http://hp.vector.co.jp/authors/VA010205/
Today is first day of rest of the life.
J( $B:#F|$O;D$j$N?M@8$N:G=i$NF|(B ) --from BH90210 (J)
I want your indication. J( $B%,%D%s$H8@$C$F$/$l(B )
I want workplace we may sing and dance if the job isn't bear on music.
J( $B$_$s$J$G2N$C$FMY$l$k;E;v>l(B ($B2;3Z7O$G$J$/$F$b(B)
$B$,$"$C$?$i$$$$$J(B )
My message is copylefted (see GPL) .
I limit number of my lovers to 68, at a time.
ps.
I chose some of references.
http://dir.yahoo.com/Science/Complex_Systems/
http://dir.yahoo.com/Science/Computer_Science/Algorithms/
http://dir.yahoo.com/Social_Science/Psychology/
http://dir.yahoo.com/Business_and_Economy/Companies/Paranormal_Phenomena/Hypnotists/
* Paranormal_Phenomena?.
http://dir.yahoo.com/Computers_and_Internet/Software/Operating_Systems/Unix/
http://dir.yahoo.com/Computers_and_Internet/Software/Operating_Systems/Realtime/
http://dir.yahoo.com/Recreation/Games/Computer_Games/Programming/
http://dir.yahoo.com/Computers_and_Internet/Hardware/Components/Microprocessors/
http://www.yahoo.com/Computers_and_Internet/Software/Programming_Tools/Object_Oriented_Programming/
http://dir.yahoo.com/Science/Computer_Science/Distributed_Computing/
http://dir.yahoo.com/Computers_and_Internet/Communications_and_Networking/
http://dir.yahoo.com/Computers_and_Internet/Software/Operating_Systems/File_Systems/
http://dir.yahoo.com/Science/Biology/Anatomy/Brain/
http://dir.yahoo.com/Science/Engineering/Electrical_Engineering/Neural_Networks/
http://www.yahoo.com/Science/Biology/Molecular_Biology/
http://dir.yahoo.com/Science/Mathematics/Combinatorics/Graph_Theory/
http://dir.yahoo.com/Social_Science/Linguistics_and_Human_Languages/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Tell-Tale DES Byte-Length Encoding
Date: Sat, 13 Feb 1999 13:11:08 GMT
In article <7a24s6$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Michael Wojcik) wrote:
>
snip ..
>
> However, I'm not sure how big an exposure this really is. As
> you point out, it reduces the amount of ciphertext you need to
> store for brute-force matching, but that amount is still prohibi-
> tive; and it helps with rejecting wrong keys, but only after
> decrypting the whole message, so it's not in the innermost loop.
>
> But I'm not a cryptanalyst, just a sci.crypt lurker.
>
Just thought I would comment on the most glaring error in your
ramblings. If one is using the blessest forms of chainning that
the crypto gods have fooled people like you into using one does
not need to decode the whole message. You need only to decode the
last few blocks. If you where using something like "wrapped PCBC"
you would not need this extra byte and you would have an all or
nothing type of encryption where one needs to decode the whole file
to get at the bottom bytes of file. But don't feel bad the NSA and
such have done a great job. 90% or more people would make the same
mistake as you so it is understandable that you would be so easily
mislead in this area.
David Scott
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Else" <[EMAIL PROTECTED]>
Subject: Re: Java random
Date: Sun, 7 Feb 1999 16:26:12 +0300
>Why do you need to generate entropy on the client? Is the client
>trying to create a secret that it needs to keep away from the server?
>If not, how about having a native RNG on the server side and have the
>server send some initial PRNG state to the client over the SSL
>connection?
The Java clients is only one part of a much larger project. Clients generate
RC4 session keys and pass them to the server encrypted with RSA - just like
SSL does. We could not get acceptable SSL license on all platforms we have
to support. Besides, who said SSL generates better keys than this method?
>I'm a little skeptical of this. If the counter goes to a few thousand
>in 10 ms, what is the statistical distribution if you do that several
>thousand times? Have you looked at that? You might be getting only a
I've done preliminary analysis already. The distribution looks gaussian with
the average around 10,000 and standard deviation of 1,500 - should be enough
for 1 byte. The output looks completely flat. I am somewhat concerned with
the performance on slower computers, though. More tests are planned.
------------------------------
From: "Steve Sampson" <[EMAIL PROTECTED]>
Subject: Re: New high-security 56-bit DES: Less-DES
Date: Sat, 13 Feb 1999 07:42:08 -0600
Congress is working along the lines of Freon and Cocaine; that is,
crypto tools will be contraband, and mere possession will be
reason enough to ruin more families, and fill the concentration
camps. Only an insulated academic could envision this as
a good thing.
Americans are sheep...
Steve
"Federalism is just plain evil" -- The Tick
TONY BARTOLETTI wrote
>Of course, it may become a crime to deal in random numbers...
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: RNG Product Feature Poll
Date: 13 Feb 1999 08:48:18 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On Fri, 12 Feb 1999 05:56:40 GMT, Dave Knapp <[EMAIL PROTECTED]> wrote:
>>A random uniform generator is what you are looking for.
>That's a bit circular, isn't it?
>And the digits in Champernowne's number are almost uniform with regard
>to bit groups, yet it is hardly a candidate for a TRNG.
>I like the term "equiprobable" because it imparts the concepts of
>independence and equidistributed in one word. I believe independence
>and equidistributed are sufficient for a crypto-grade TRNG.
>Independence means there are no correlations and equidistributed means
>there is no bias. Numbers that have no bias or correlation cannot be
>predicted, which means they are proveably secure for use in crypto.
This is very definitely NOT the case. Lack of correlation only involves
pairs of random variables, while there exist n-tuples of random variables
such that any n-1 are independent, but any one can be determined from
the others. This definitely applies ot random bits.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: SCOTT COMPRESSION
Date: Sat, 13 Feb 1999 13:27:56 GMT
In article <N_2x2.4$[EMAIL PROTECTED]>,
"karl malbrain" <[EMAIL PROTECTED]> wrote:
>
> <[EMAIL PROTECTED]> wrote in message
> news:79vf61$ghl$[EMAIL PROTECTED]...
>
> > I am assuming they KNOW the compression methods and have a copy
> >of the program. However to decompress a few bytes at the start of
> >file relies on inoformation that is farther down the file than in
> >just the first few bytes. The passes are in different directions.
> >
>
> From a LINEAR perspective, <<farther down>> is an UNBASED term. E.g. if you
> want me to wait until your ending before beginning -- that's just called
> buffering. Karl M
>
>
It is well known my English sucks. But I don't think I meant buffering. You
can wait for my code. But I think people still can't follow what I did in
scott16u or scott19u. But I meant transversing through the file in different
directions. If you look at scott16u. To encrypt I read the file over and over
again in the forward direction. But to decrypt I have to process the file
over and over again in the backward direction. I know few programs that force
the attacker to look at file in reverse direction to decrypt. Most chaining
methods are so poor that an attacker could actually look at file in ether
dirrction to decode it so the forward direction is picked for ease of use. I
feel strongly that when one is doing compression for cyrptographic purposes
that the passes should be in opposite directions also. But in the compression
program I am writing I will chop the file up so that one could either use the
whole file or use the method on a contiuious stream of data. The first and
third pass will be all the way forward passes but the second pass will be the
chopped reverse pass so maybe the word buffering is suited for anything less
than a full file but in either case the reverse processing of the second pass
is what I intended to communicate.
David Scott
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Metaphysics Of Randomness
Date: Sat, 13 Feb 1999 15:22:34 GMT
Reply-To: [EMAIL PROTECTED]
On 11 Feb 1999 15:38:23 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>Oh, you mean that you paid money for the availability of the library?
>I guess it wasn't free, then. 8-)
"Free at the point of use" (that's socialist doublespeak for paying
for something but not being charged for it).
>Correlation is just another kind of sequence bias.
Champernowne's number in base 10 exhibits no bias for any digit
groups, yet it is extremely correlated.
Bob Knauer
"The one thing every man fears is the unknown. When presented with this
scenario, individual rights will be willingly relinquished for the guarantee
of their well being granted to them by their world government."
--Henry Kissinger
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: hardRandNumbGen
Date: Sat, 13 Feb 1999 15:31:48 GMT
Reply-To: [EMAIL PROTECTED]
On 11 Feb 1999 15:42:48 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>>A TRNG must be capable of generating all possible finite sequences
>>equiprobably. If it is biased, then is it not doing that. Anti-skewing
>>procedures do not generate those sequences that under-representted
>>because of the bias.
>Um... This is simply incorrect. That's *exactly* what anti-skewing
>procedures do.
I would like to see how that is possible.
>Think of it this way. Assume you have a biased, but independent, bit
>source that generates 1s with probability p > 0.5. Consider two
>successive bits, x, y.
>The probability of getting the sequence 1, 0 is p * (1-p).
>The probability of getting the sequence 0, 1 is (1-p) * p, which is
>identical to the above.
>So if you output a 1 bit when you see the pair 1,0 and a zero bit
>when you see the pair 0,1 (and nothing otherwise), then you've
>got a provably unbiased output stream -- the bias has been scrubbed
>from the input -- by the technique of throwing away everyting that
>*isn't* unbiased, broadly speaking.
I believe that algorithm is attributed to Knuth.
This all sounds good on the surface but I am not convinced at this
point. For example, there are sequences from a TRNG that are heavily
biased, like 111...1 and 000...0, yet the scheme above does not seem
to be able to produce those sequences. Can that anti-skewing technique
above generate all possible sequences including 111...1 and 000...0
with their expected probability based on their length? Is so, please
show us how.
If there is a reference in Li & Vitanyi, please cite it, since I have
renewed the book for a couple more weeks for a second reading. If not,
perhaps you can provide another reference. I might as well get as much
out of my "free" library as I can, since I am paying for it.
Bob Knauer
"The one thing every man fears is the unknown. When presented with this
scenario, individual rights will be willingly relinquished for the guarantee
of their well being granted to them by their world government."
--Henry Kissinger
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: RNG Product Feature Poll
Date: Sat, 13 Feb 1999 15:47:55 GMT
Reply-To: [EMAIL PROTECTED]
On 11 Feb 1999 10:47:09 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>>If you can prove
>>experimentally that a TRNG is pac-secure to an acceptable level, then
>>it is "proveably secure" to that level.
>Excuse me -- if you prove that something is "probably approximately
>secure," than that counts as provable?
>Um.... This is exactly what you've been complaining about w.r.t.
>statistical testing; all you can achieve is a statment that something
>is "probably" secure or "probably" unbiased to within a particular
>approximation.
That is not what I have been saying. I have criticized statistical
testing of the output numbers themselves. That is not the same as pac
inference.
Once again I will restate my criticism of statistical testing of the
output to characterize a TRNG: It is not possible to determine that a
RNG is a TRNG from statisitcal testing of the output because such
tests are only necessary and not sufficient. The reason for that is
that a PRNG can be built to pass any set of such tests.
Of course, if you had infinite resources, then you could use
statistical tests to characterize a true random number because you
would be able to test for *every* form of non-randomness in that
infinite number. Then you could reject all PRNGs directly. But since
you cannot do that in a practical manner, some PRNGs can slip by your
tests - PRNGs which are not secure for crypto purposes.
And even if you had an infinite amount of resuorces, how do you take
into account the problem with Champernowne's number in base 10? That
number passes all statistical tests yet it is the poorest choice for a
TRNG I can imagine short of a generator that put out all 0s.
Here is another consideration: A TRNG only needs to be *capable* of
generating all possible finite sequences equiprobably - it does not
nedd to actually generate them. If you attempted to generate all
possible finite sequences, you would have to generate an infinite
number of them.
Because you cannot do that, you cannot test the output of a TRNG
adequately to characterize the generator itself as a TRNG. The only
way you can do that is to audit the design and provide for diagnostic
tests on each subsystem.
Bob Knauer
"The one thing every man fears is the unknown. When presented with this
scenario, individual rights will be willingly relinquished for the guarantee
of their well being granted to them by their world government."
--Henry Kissinger
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: hardRandNumbGen
Date: Sat, 13 Feb 1999 15:50:54 GMT
Reply-To: [EMAIL PROTECTED]
On 11 Feb 1999 15:42:48 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>>A TRNG must be capable of generating all possible finite sequences
>>equiprobably. If it is biased, then is it not doing that. Anti-skewing
>>procedures do not generate those sequences that under-representted
>>because of the bias.
>Um... This is simply incorrect. That's *exactly* what anti-skewing
>procedures do.
>
>Think of it this way. Assume you have a biased, but independent, bit
>source that generates 1s with probability p > 0.5. Consider two
>successive bits, x, y.
>
>The probability of getting the sequence 1, 0 is p * (1-p).
>The probability of getting the sequence 0, 1 is (1-p) * p, which is
>identical to the above.
>
>So if you output a 1 bit when you see the pair 1,0 and a zero bit
>when you see the pair 0,1 (and nothing otherwise), then you've
>got a provably unbiased output stream -- the bias has been scrubbed
>from the input -- by the technique of throwing away everyting that
>*isn't* unbiased, broadly speaking.
I have a further objection to this method.
If this method produced perfectly secure numbers, then it could be
applied to the output of any PRNG to produce perfectly secure random
numbers. But we know this is impossible in general.
I still think that correlation and bias are completely separate
concepts. You may be able to anti-skew a sequence, but that won't
remove correlation.
Bob Knauer
"The one thing every man fears is the unknown. When presented with this
scenario, individual rights will be willingly relinquished for the guarantee
of their well being granted to them by their world government."
--Henry Kissinger
------------------------------
** 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
******************************
