Cryptography-Digest Digest #326, Volume #9 Fri, 2 Apr 99 10:13:05 EST
Contents:
Re: Announce - ScramDisk v2.02h ([EMAIL PROTECTED])
Re: True Randomness & The Law Of Large Numbers (R. Knauer)
Re: FSE information anyone? (Thirteen)
Re: Alert: "HAPPY99.EXE" e-mail/newsgroup virus ("CStein")
Re: Random Walk ("Trevor Jackson, III")
Re: Announce - ScramDisk v2.02h (aman)
Re: Alert: "HAPPY99.EXE" e-mail/newsgroup virus ("Arvin Meyer")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp
Subject: Re: Announce - ScramDisk v2.02h
Date: Fri, 02 Apr 1999 12:05:58 GMT
It's nice that mr. Simpson and "Aman" continue to work on SD.
The list of enhancements in v.2.02h looks not too long, so
I decided to look at new SD manual. Nice pictures... extended
FAQ appeared... And an interesting section "Theoretical Attacks
against ScramDisk" now includes comparison of Scramdisk, BestCrypt
and PGPdisk security level:
"Real security, as provided in SD, cannot be circumvented via this
strategy: SD doesn't store the type of cipher that is used to encrypt
the disk in the header (as does BestCrypt, a "competitor" to SD). So,
basically, for every trial passphrase that you wish to try you have to
undertake at least 1x SHA-1 operations, 1x block cipher initialise &
2x block cipher decryption's FOR EACH CIPHER (there are 10 ciphers).
Thus both of the previously mentioned attacks are FAR harder against
SD compared to PGPDisk, BestCrypt et al. We conjecture that SD is
more than 10 times harder to brute force than its competitors."
Ooops... Sam and Aman have discovered a new way to make security
software 10 times harder to break than "competitor's" products?
Yes. So please keep that way in mind. Never make your software
using only one algorithm. If you use 10 algorithms or more,
you can write about other packages as "competitors" (word in
quotes). Drop away encryption products that use one algorithm
only. IDEA? Blowfish? CAST? GOST? 3DES? Since today let's believe
in products that use not one of them, but all of them together
plus a dozen of some others.
Ok, but what about brute force attack on SD? Is it 10 times slower
because of hiding algorithms' ID? May be yes in some cases, but it
is not so obvious as SD authors wrote. Blowfish key initialization,
for example, is much more longer process than the same process used
in other algorithms ( For the most optimized implementation -
521 iterations of encryption and P-array element re-initialization).
Now we brute force attack SD container and try every algorithm.
If Blowfish initialization 20 times slower than others, we'll get
SD attacking just 1.5 times slower than software using only
one - Blowfish - algorithm.
About direct attacking not password, but encrypted data directly,
the case looks even more interesting. If we have a bunch of
algorithms with different key length (from 56 to 256 bits),
we spent extremely short periods trying 56-bit algorithms
comparing with 256-bit algorithms. Even if all algorithms
were 256-bit, it would be the same to use one 260-bit
algorithms or ten 256-bit algorithms.
IMHO, comparing SD and other encryption products, SD authors
manipulates by figures and they do that to advertise their
product. Smells like Snake Oil: get my product with 10
algorithms (my mixture against 10 diseases), and see how
funny looks the product with 1 algorithm (mixture against
1 disease).
Sorry for my critics, it seems that SD authors could use
a way of improvement their software to get it better than
competitors'. If they can. But not the way of incorrect
comparisons - it just brings a negative impression on
SD itself.
Best regards,
Peter
In article <[EMAIL PROTECTED]>,
"Sam Simpson" <[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> We are pleased to release a new build of ScramDisk - version
> 2.02h.
>
> This build contains the following enhancements over 2.02g:
>
> 1) Ability to disable the "Clear cached password?" question when
> quitting the application.
>
> 2) Allow fast automated shutdown under '98.
>
> 3) "Auto-execution" function added. This allows a user to run an
> arbitrary data file or application when ScramDisk mounts specific
> containers.
>
> 4) Several ScramDisk console applications released
>
> This build is released with full source code and an updated User
> Manual.
>
> Please do not hesitate to contact us with any enquiries.
>
> Regards,
>
> Sam Simpson
> Comms Analyst
> - -- See http://www.scramdisk.clara.net/ for ScramDisk, a free
> virtual disk encryption for Windows 95/98. PGP Keys available at
> the same site.
>
> -----BEGIN PGP SIGNATURE-----
> Version: 6.0.2ckt http://members.tripod.com/IRFaiad/
>
> iQA/AwUBNwMx/+0ty8FDP9tPEQLQvACdEPAC82GMx4M74yqNaKjwyaZUYIUAoNMz
> nXyxPZ6fzSRwCbLTs6LA0xFA
> =fkvW
> -----END PGP SIGNATURE-----
>
>
============= 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: True Randomness & The Law Of Large Numbers
Date: Fri, 02 Apr 1999 12:44:08 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 01 Apr 1999 23:31:40 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>The problem with this construction is simple. While we believe that
>women are either pregnant or not, there is no test, statistical or not,
>that will be 100% accurate.
Oh, come on now. There are any number of tests that are 100% decisive.
There is the simple test of xraying the uterus and seeing the fetus
with your own eyes. There are characterstic harmones that are present
in the blood only when the woman is pregnant. Once the corpus luteum
ruptures all sorts of substances are released that give telltale signs
of successful fertilization.
>Why would we have any confidence in a test that is not guaranteed
>perfectly adequte?
> 1. It is the best we have.
Is it?
> 2. For many problems it is "good enough"
They are not "good enough" for a determination of the
non-true-randomness of a TRNG.
> 3. It is the best we have
Are you claiming that standard statistical tests are the best we have
for determing the non-randomness of a TRNG, even though what they
measure has little to do with non-true-randomness?
Is the acceptibility of an inaccurate test enhanced because it is the
only test around? Would you give validity to astrology just because it
was the only theory of planetary motion available before Newton?
>The same criteria apply to the application of statistical tests to RNG
>outputs, even though the situation is inverted --uncertainty lies in the
>reality not in the test.
Are you claiming that, because standard statistical tests are an
inaccurate way to determine non-randomness, implies that one cannot
ever hope to determine non-randomness in reality by any means? That is
a very powerful assertion. Keep in mind that quantum computation is
capable of generating truly random sequences. In fact, from one point
of view, a TRNG based on a truly random quantum process (such as
radioactive decay) can be looked upon as a specialty (dedicated)
computing device for generating truly random numbers. It is not a
general purpose quantum computer, but it does engage in quantum
calculation of a sort nevertheless.
>Note that the assertion of some "inspection process" as superior to
>statistical testing is fundamentally flawed. Mathematical history is
>littered with people who performed the most rigorus analyses of their
>algorithms, which, in practice, failed miserably. The best example of
>this is found in Knuth's early work on "super-randomness".
I would broaden the concept of an "inspection process" to include the
kinds of evaluations that scientists do to certify that their
equipment is working properly. One thing they never do is to use the
output of the equipment, namely the experimental results, as a means
of justifying the proper function of the equipment. Yet that is
exactly what proponents of statistical testing are doing - they are
claiming that you can decide the non-true-randomness of a TRNG by
examining the "experimental results", namely the sequences it
generates.
If you know with reasonable certainty that the TRNG is functioning
properly, you don't need statistical tests. If you do not know with
reasonable certainty that the TRNG is functioning properly, you cannot
use its output to determine that is it functioning properly with
reasonable certainty. That is circular reasoning.
Of course, you can hold the output up to a theoretical model and
determine if the TRNG obeys your expectations based on that
theoretical model. But in the case of true randomness, we do not have
an adequate theoretical model. All we have is a model of
"pseudo-randomness" based on at least two assumptions that do not
obtain in the case of a TRNG:
1) The claim that the true random process can be modeled by some kind
of classical process such as the uniform Bernoulli process.
2) The claim that what happens at infinity can be extrapolated to the
finite realm with lesser confidence.
Neither of those claims has any basis in classical reality for true
random number generation. You have to go to quantum reality to get
true randomness, and even then the true randomness of QM cannot be
modeled mathematically. Otherwise we would have a hidden variable
theory by now.
>A sane crypto-engineer will use both procedures, belt and suspenders, to
>detect problems. If an RNG passses all available analyic tests (in the
>sense of failing to find a disqualifying flaw), and passes all available
>statistical tests (in the sense of failing to find a disqualifying
>correlation/bias/etc), then the RNG is good enough.
It may be good enough for a particular application, but it is not
necessarily a true random number generator.
>Resolved: Given two RNGs both of which pass all tests as described
>above, they are equivalently random because there is no metric by which
>their lack of randomness can be characterized.
You have introduced two separate concepts in that one sentence:
1) You are comparing two processes. That implies that you know one of
them is truly random, and are comparing the other one to it.
NB: That is an interesting proposition, in that it seems to point the
way to using statistical tests by building a "Standard TRNG" that is
known to function properly not using statistical tests, and compare
all purported TRNGs against it. I still believe you would need an
hellaciously large sample to do the comparison with any validity,
because you still do not know the actual distribution, so you cannot
make any assumptions about the confidence levels based on the sample
size.
2) You seem to be saying at the end that there is no algorithmic test,
including statistical tests, which can be used to characterize a lack
of (true) randomness.
Resolved: Trevor Jackson agrees completely with Bob Knauer on item
number 2 above.
It is I who has been claiming that no such metric can be found to
demonstrate the lack of true randomness for a TRNG with reasonable
certainty.
>Futher, a crypto-engineer who fails to employ all available tests of
>both flavors is negligent. An adversary should be expected to utilize
>all available flavors of tests for flaws.
Yes, but if the keystreams are truly random, those tests are of little
value, as examples we have given before point out.
>There is no amount of
>analytic inspection that can substitute for a simple statistical
>evaluation of the RNG output.
That is simply not true for experimental equipment. If it were, then
all of experimental science would not be valid.
I think what you are referring to is PRNGs.
>And, there is no amount of statistical
>testing that can substitute for a simple inspection of the RNG
>mechanism.
I fully agree. But your terminology is a bit misleading, to me anyway.
I do not understand what you mean in this context by the term "simple
inspection" or the term "analytical inspection" above. In fact, on the
face of it, those two comments seem to contradict one another.
What is the difference between "analytical inspection" above - which
is not satisfactory compared to statistical tests - and "simple
inpection" below - which is satisfactory compared to statistical
tests?
Bob Knauer
"First, it was not a strip bar, it was an erotic club. And second,
what can I say? I'm a night owl. Anyway the bitch set me up."
- Marion Barry, Mayor of Washington DC
------------------------------
From: Thirteen <[EMAIL PROTECTED]>
Subject: Re: FSE information anyone?
Date: Fri, 02 Apr 1999 06:18:49 -1000
> David Crick wrote:
> >
> > Does anyone who attended FSE (right after AES2) intend to compile
> > a brief report on it? (like we had for the two days of AES2)
Rome is a beautiful city for a conference to be held in, with
cobblestone streets, charming plazas with fountains, and
beautiful women. The traffic is anarchy, with motor scooters
and tiny Fiats maneuvering for every advantage, scooters even
zooming onto sidewalks to park in their accustomed spot.
Scramble All, Encrypt Small: sharing work with a smart card
On Wednesday last week the paper by Jacobsson, Stern, and Yung
was presented with surprising and enlightening teachings. While
FSE is for fast Software encryption, this scheme involves a
smart card, a Hardware device as a trusted, keyed device that
works with a more powerfull computer which hashes larger amounts
of information. The smart card contributes one block of keyed,
encrypted information to a larger collection of information
which is then hashed together with the encrypted block by the
more powerful, unkeyed computer (host).
The host may be a server that is vulnerable to attack from many
sources, but which can compute thousands of hashes faster than
a smart card can compute one encryption. The smart card is in
trusted hands (yours) and has a key that is known to be
uncompromised. The card only does one encryption or decryption
in this paper, an advance over previous work that needed more than
one such operation (Blaze '96). The new plan offers balanced
computation, low communications, and security for arbitrarily long
messages secured by a single encryption or decryption operation
by the feable device in cooperation with many hashes by the
untrusted host.
The message is padded by the Card with a k bit random number. The
padded message M is split in half ML, MR being two halves.
The Host hashes the two halves and XORs in a Feistel network with
the other half, making CL CR, two ciphertexts. The host extracts
the last k bits of CR with and the Card encrypts that. The Host
places that encrypted block in place of the extracted k bits.
The message is now encrypted.
To decrypt, the Host splits the ciphertext in half and sends the k
bits of CR to the Card to decrypt. The host puts the decrypted block
in place of the k bits. The Host hashes CR and CL and XORs in a Feistel
structure with CL and CR to recover the message.
> > To be continued...13
------------------------------
From: "CStein" <[EMAIL PROTECTED]>
Crossposted-To:
comp.lang.pascal.delphi.misc,comp.databases.paradox,comp.databases.ms-access
Subject: Re: Alert: "HAPPY99.EXE" e-mail/newsgroup virus
Date: Fri, 2 Apr 1999 08:25:28 -0600
Chuck Grimsby <[EMAIL PROTECTED]> wrote:
>
> Shameless repost from comp.risks:
:
<snip 18K of useless info about the Melissa.A virus>
Perhaps you SHOULD be shamed, Chuck.
If I wanted to download an 18K post in order to know more about Melissa (as
if local news and other sources haven't gone into enough depth on the
subject), I would've visited a .virus or .antivirus newsgroup (or better
yet, visited a trusted anti-virus website such as the CIAC -
http://ciac.llnl.gov/ciac/ , McAfee online -
http://vil.mcafee.com/villib/alpha.asp , or Symantec) ... NOT
comp.lang.pascal.delphi.misc, comp.databases.paradox,
comp.databases.ms-access, or even sci.crypt.
Come on... newsgroup names have a PURPOSE... use them for what they were
intended.
------------------------------
Date: Fri, 02 Apr 1999 09:27:33 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Random Walk
R. Knauer wrote:
>
> On Fri, 02 Apr 1999 00:04:17 -0500, "Trevor Jackson, III"
> <[EMAIL PROTECTED]> wrote:
>
> >Now, given a constant confidence level, how does the sample size
> >required to reach that level of confidence grow as the size of the
> >parent population grows? This is related to the sharpening of the
> >central spike in a gaussian distribution as the size grows.
>
> Then you do have a theoretical model for true randomness.
No. It has nothing to do with randomness, true or false. It is only a
description of the state space availabe to a FINITE aggregate of
indepedent values.
>
> At medium
> >large numbers (10e6) the spike is quite sharp. At really large numbers,
> >like the moles of air in a room (10e25?) the spike is incredibly thin.
> >Thus we never see any measurable pressure differential across a room,
> >much less a segregation of air molecules.
>
> >For truly huge numbers, such as 2^256, the spike is essentially
> >everything. It is really very hard to get a sequence of that length
> >that is at all far from the center. For numbers like those you
> >mentioned, 2^1000, it is impossible in practice.
>
> >Given this narrowing of expectations,
>
> The "narrowing of expectations" is a presumption based on a
> theoretical model, such as the uniform Bernoulli process. I am not
> going to put words into your mouth by saying that you believe that a
> UBP is a correct model for a TRNG - as many others have said in the
> literature - but I am going to ask if you think it is.
No. The model for a TRNG is a topic unrelated to the expected deviation
or variance of a statistical sample. The criteria for evaluating RNG
output is the core of this dispute. IIUY, you claim there is no
possible valid test because we cannot evaluate large (> 2^100) samples.
The change in sample size for a constant confidence level as the
population/state-space increases is related to the narrowness of the
distribution of large samples.
Stick to the issue.
>
> >it does not take a large sample to
> >give good confidence that the sample properly represents the parent
> >population.
>
> Just how large is a "large sample"? And what is the justification for
> making that statement in general?
As I said, this is a good question. The answer is readily available. I
recommend that you find one you believe to be satisfying rather than
accapting one given here.
>
> I do not believe either question can be answered unless you posit a
> theoretical model, and make the assumption that is correctly models
> the TRNG output. Can you provide us with that model, so we can see how
> you can calculate such things as a "large sample" and see how such a
> "large sample" actually allows us to make inferences.
>
> >I have purposely left out any prescriptive reference,
> >thinking that if you derive the actual forumla for the sample size
> >necessary to reach a given level of confidence then you will have gained
> >the insight necessary to comprehend the answer. Without that insight
> >the answer will be counter-intuitive gobbledogook.
>
> You cannot calculate amything until you have been given the
> theoretical model. So, just exactly what is the theoretical model for
> true randomness?
These issues are unrelaed. Stick to the issue.
>
> >Good luck.
>
> Oh, cut it out - such calculations are taught in elementary
> undergraduate courses.
Good. Then you will not have any trouble finding an expression that
describes sample size based on population.
> Don't evade the fundamental issues with
> condescention.
>
> >This is another reasonable question, but I'm not well-enough grounded in
> >the axioms of statistics to answer it at all authoritatively. I am
> >certain that the analyses I learned had nothing, zero, to do with
> >infinite samples.
>
> Then how come Triola says omp. 212:
>
> "The mean of a discrete random variable is the theoretical mean
> outcome for *infinitely* many trials."
His definition may be useful in interpreting his book, but it is not an
interesting or useful one for our purposes.
>
> How much more explicitly would you want someone to state that infinity
> plays a large part in statistics than when that someone uses it to
> discuss the calculation of such a fundamental quantity as the mean
> value of a distribution?
You are making a critical, fundamental error. The infinite case is easy
because there is only one. All infinite sequences, even two that start
with 1000 ones and 1000 zeros respectively, have the same statistics.
For finite populations the situation is harder because a population may
not be perfectly gaussian. Thus there are lots (to put it mildly) of
different population distributions. Thus the finite case is much
harder.
Look at it linguistically. You said "THE mean value of a
distribution". There is only one possible mean of an infinite sequence
of equal probabilities. There are MANY possible mean values of finite
distributions.
Mathematically, any prefix bias will be lost in the rounding of an
infinite sequence. A prefix bias will, however, afect the statistics of
a finite sample.
>
> I rest my case:
>
> 1) Statistical tests assume a theoretical probability distribution;
>
> 2) Statistical tests rely on the passage to infinity in the
> calcualtions of expectations.
>
> >I would guess your suspiscion is related to something
> >like the central limit theorem in which the answers are approximations
> >until the limit is reached. That is most certainly NOT true of
> >statistics. All of the principles are founded in finite populations.
>
> Not true according to Triola. He makes a big deal over distributions
> (p. 202):
Well, I'm no authority, but I disagree with his statements as quoted by
you.
>
> "Without a knowledge of probability distributions, users of statistics
> would be severely limited in the inferences they could make. We intend
> to develop the ability to work with discrete and continuous
> probability distributions, and we begin with the discrete case because
> it is simpler."
>
> >They are several (probably more than I am aware of) shortcuts that can
> >be taken because a sample may be shown to approximate a "perfect"
> >distribution (based on an infinite collection), which makes it easier to
> >manipulate. But AFAIK this are just Q&D techniques unrelated to
> >fundamental statistical analysis.
>
> I do not doubt what you said in the general case - I am challenging
> that assertion as it applies to tests for true randomness of finite
> sequences.
OK, what is special about "tests for true randomness of finite
sequences" that leads you to believe that what holds in the general case
does not hold in that specific case? Have I missed something?
------------------------------
From: [EMAIL PROTECTED] (aman)
Crossposted-To: alt.security.pgp
Subject: Re: Announce - ScramDisk v2.02h
Date: Fri, 02 Apr 1999 14:51:15 GMT
On Fri, 02 Apr 1999 12:05:58 GMT, [EMAIL PROTECTED] wrote:
>
>Sorry for my critics, it seems that SD authors could use
>a way of improvement their software to get it better than
>competitors'. If they can. But not the way of incorrect
>comparisons - it just brings a negative impression on
>SD itself.
We have no competitors.
Scramdisk is not a commercial product, and we don't care if people use
it or not. It is up to them to make their own mind up.
To be honest, I sometimes wonder why I bothered.....
Aman.
------------------------------
From: "Arvin Meyer" <[EMAIL PROTECTED]>
Crossposted-To:
comp.lang.pascal.delphi.misc,comp.databases.paradox,comp.databases.ms-access
Subject: Re: Alert: "HAPPY99.EXE" e-mail/newsgroup virus
Date: Fri, 2 Apr 1999 10:12:00 -0500
The information was very useful, but your point is well-taken, a link would
have been sufficient. In my previous post, a link wasn't feasible because it
came from a list-server. I suspect Chuck, was just trying to be helpful and
was over zealous.
=====
Arvin Meyer
[EMAIL PROTECTED]
CStein wrote in message ...
><snip 18K of useless info about the Melissa.A virus>
>If I wanted to download an 18K post in order to know more about Melissa (as
>if local news and other sources haven't gone into enough depth on the
>subject), I would've visited a .virus or .antivirus newsgroup (or better
>yet, visited a trusted anti-virus website such as the CIAC -
>http://ciac.llnl.gov/ciac/ , McAfee online -
>http://vil.mcafee.com/villib/alpha.asp , or Symantec) ... NOT
>comp.lang.pascal.delphi.misc, comp.databases.paradox,
>comp.databases.ms-access, or even sci.crypt.
>
>Come on... newsgroup names have a PURPOSE... use them for what they were
>intended.
------------------------------
** 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
******************************
