Cryptography-Digest Digest #273, Volume #9 Tue, 23 Mar 99 17:13:03 EST
Contents:
triple-DES (Drew Schlosser)
Re: Scramdisk ("Sam Simpson")
Re: password ("Sassa")
Re: Live from the Second AES Conference (DJohn37050)
Re: RSA key distribution (DJohn37050)
Maurer's Universal Statistical Test C (was Re: idea for random numbers
([EMAIL PROTECTED])
Re: idea for random numbers ([EMAIL PROTECTED])
Re: triple-DES (John Savard)
Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED (John Savard)
Re: Live from the Second AES Conference (STL137)
Re: triple-DES (DJohn37050)
Re: ElGamal vs RSA ([EMAIL PROTECTED])
Re: Testing Algorithms ("Trevor Jackson, III")
----------------------------------------------------------------------------
From: Drew Schlosser <[EMAIL PROTECTED]>
Subject: triple-DES
Date: Tue, 23 Mar 1999 10:25:53 -0500
Can anyone tell me the relation between DES and triple-DES?
Est-ce que quelqu'un pourait me dire la relation entre DES et
triple-DES?
Drew Schlosser
RMC of Canada
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Scramdisk
Date: Tue, 23 Mar 1999 17:18:59 -0000
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
As far as we know, no!
The file format was deliberately designed to be entirely
encrypted - even the algorithm identifier etc are enciphered.
I have extensively tested container files with DieHard and all of
them are "acceptable".
Regards,
- --
Sam Simpson
Comms Analyst
http://www.scramdisk.clara.net/ for ScramDisk hard-drive
encryption & Delphi Crypto Components. PGP Keys available at the
same site.
If you're wondering why I don't reply to Sternlight, it's because
he's kill filed. See http://www.openpgp.net/FUD for why!
Anonymous wrote in message
<[EMAIL PROTECTED]>...
>Is there any way to prove by analysis that an unmounted
Scramdisk volume is
>encrypted data.
>
>Apart from the file extension (which can be changed) can the
files be
>linked to the program.
>
>Thanks
>TM
=====BEGIN PGP SIGNATURE=====
Version: 6.0.2ckt http://members.tripod.com/IRFaiad/
iQA/AwUBNvfM6O0ty8FDP9tPEQLg0gCZAZXMz2ylTZk3aqrnkUCuwJZPl14AoNST
DzJXpUliW/9tSsoIw//rAOz7
=AuGl
=====END PGP SIGNATURE=====
------------------------------
From: "Sassa" <[EMAIL PROTECTED]>
Subject: Re: password
Date: Tue, 23 Mar 1999 19:38:29 +0200
Reply-To: [EMAIL PROTECTED]
> In plain UNIX C, is there a way to display * as user enter password as
> input,
possible at all?
> or blank the input just like the UNIX logon does?
redirect stdout to null while inputting psw
--
Sassa
Apiary Inc.
______
@()(_)
/\\
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Live from the Second AES Conference
Date: 23 Mar 1999 19:31:24 GMT
For an alternative viewpoint to Schneier's "choose one" perspective, see my
"Future Resiliency" paper on the NIST website.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: RSA key distribution
Date: 23 Mar 1999 19:42:20 GMT
If you want to try to see if an RSA public key is arithmetically plausible,
this is called public key validation and is a research topic. Bob Silverman
has done some work on this, has presented some stuff to ANSI X9 and should
present more at next meeting.
Don Johnson
------------------------------
From: [EMAIL PROTECTED]
Subject: Maurer's Universal Statistical Test C (was Re: idea for random numbers
Date: Tue, 23 Mar 1999 19:31:33 GMT
This is a command-line program to measure the entropy of a file.
Usage: ueli8 mysample
Sample output: the effect of compression on a file's entropy.
C:\temp>\uli\uli Work.tar
UELI 1 Dec 98
L=8 256 258560
Measuring file Work.tar
Init done
Work.tar fTU= 3.36398 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Expected value for L=8 is 7.1836656
C:\temp>\uli\uli Work.tar.gz
UELI 1 Dec 98
L=8 256 258560
Measuring file Work.tar.gz
Init done
Work.tar.gz fTU= 7.16259 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Expected value for L=8 is 7.1836656
/*
UELI8.c ---blocksize of 8
23 Mar 99 posted to sci.crypt
This implements Ueli M Maurer's
"Universal Statistical Test for Random Bit Generators"
using L=8
Accepts a filename on the command line;
writes its results, with other info, to stdout.
Handles input file exhaustion gracefully.
Ref: J. Cryptology v 5 no 2, 1992 pp 89-105
also on the web somewhere, which is where I found it.
Built with Wedit 2.3, lcc-win32
http://www.cs.virginia.edu/~lcc-win32
Usage:
UELI filename
outputs to stdout
*/
#define L 8
#define V (1<<L)
#define Q (10*V)
#define K (100*Q)
#define MAXSAMP (Q + K)
#include <stdio.h>
#include <math.h>
int main( argc, argv )
int argc;
char **argv;
{
FILE *fptr;
int i;
int b, c;
int table[V];
double sum=0.0;
int run;
extern double log(/* double x */);
printf("UELI 1 Dec 98\nL=%d %d %d \n", L, V, MAXSAMP);
if (argc <2)
{printf("Usage: UELI filename\n"); exit(-1); }
else
printf("Measuring file %s\n", argv[1]);
fptr=fopen(argv[1],"rb");
if (fptr == NULL) {printf("Can't find %s\n", argv[1]); exit(-1); }
for (i=0; i<V; i++) table[i]=0;
for (i=0; i<Q; i++) {
b= fgetc(fptr);
table[ b ]=i;
}
printf("Init done\n");
run=1;
for (i=Q; run && i<Q+K; i++)
{
b=fgetc(fptr); if (b<0) run=0;
if (run) {
sum += log( (double) ( i-table[b] ) ) ;
table[ b ]=i;
}
}
if (!run) printf("Premature end of file; read %d blocks.\n", i-Q);
sum = (sum/( (double) (i-Q) ) ) / log(2.0);
printf("%s fTU= %g\n\n", argv[1], sum);
printf("Expected value for L=8 is 7.1836656\n");
}
About 60 or 70 percent of NSA were smoking pot -- a lot of them while on
duty. It's very relaxing, particularly when you're bored with the
Russian or East German traffic that is coming through.
http://jya.com/nsa-40k.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: idea for random numbers
Date: Tue, 23 Mar 1999 19:13:53 GMT
In article <[EMAIL PROTECTED]>,
bob taylor <[EMAIL PROTECTED]> wrote:
> Reading the noise from a sound card for random numbers is not a new
> idea, nor very random if taken as whole bytes. But what if you try
> this:
> Only use the LSB (bit 0) for the random sample, and you can even take
> the next bit (bit 1) to control the sample interval(stagger). You get
> random data sampled at random intervals. It maybe slow but I dont see
> any statistical problems.
> If the data cant be predicted or calculated,
> wouldn't it be good enough for OTP. (you can always hash it too)
>
> Also, if I try to run the data thorugh DIEHARD, it gives me alot of
> data, but how can I tell if those numbers are good or bad (pass/fail)?
You REALLY need to read RFC 1750. You will enjoy it and learn lots.
(I've travelled the fascinating path you're obviously starting. Eventually
you get to the point where you think, hmm, the steam out of my espresso maker
sounds like it has the high-freq hiss that distinguishes raw from
full-entropy noise. That is, if you've converted your data samples to
audio..)
You must measure your output. Otherwise you're not doing science,
you're just handwaving. Use Diehard; use Maurer's Universal
Statistical Test for True RNGs. GET A SAMPLE OF GOOD RANDOM (or PR) data
for comparison. Run a cipher in feedback mode to get sample data.
Or find the RAND Co.'s Million digits and their Deviant Friends,
convert to binary, and use that.
Use the entropy-measuring tools on your raw data. Then cook it with your
algorithm, and measure again. Then repeat: any change?
Try this where your 'cooking function' is parity. Every N bits yields a bit.
Try different N.
BTW, what you look for in Diehard output is p-values NOT at 0.000 or 1.000.
But you should discover this when you try these experiments.
What you look for in Maurer's test is a measured entropy value vs. expected
value. Look at your raw data's measure, then cook it, measure again.
It's entropy should eventually asymptote if you keep reducing it.
(e.g., try distilling with parity of 2; then take the result, measure it,
distill it again.)
About 60 or 70 percent of NSA were smoking pot -- a lot of them while on
duty. It's very relaxing, particularly when you're bored with the
Russian or East German traffic that is coming through.
http://jya.com/nsa-40k.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: triple-DES
Date: Tue, 23 Mar 1999 20:29:01 GMT
Drew Schlosser <[EMAIL PROTECTED]> wrote, in part:
>Can anyone tell me the relation between DES and triple-DES?
>Est-ce que quelqu'un pourait me dire la relation entre DES et
>triple-DES?
Triple-DES simply refers to encrypting a message with DES three times in a
row, but not with the same key each time.
There are different styles of Triple-DES. While the most obvious one is
simply encrypt with key 1, encrypt with key 2, encrypt with key 3, the most
common forms are different from the obvious one.
One form uses only two keys:
Encrypt with key 1. Decrypt with key 2. Encrypt with key 1.
This form is sort of considered the "standard" when triple-DES is referred
to. If key 1 = key 2, two of the steps cancel out, so interoperation with
older single-DES equipment is easy, if wasteful.
The next most common is still EDE (encrypt-decrypt-encrypt), but with three
independent keys.
The reason triple-DES, rather than double-DES, is used is because of a
possible attack on double-DES (requiring a lot of memory) that could,
theoretically, make double-DES not much harder to crack than single-DES.
Also, it should be noted that the three DES encipherments in Triple-DES are
block encipherments, producing a new block cipher as a result. This block
cipher can be used in CBC or other modes, but it is not recommended to use
three layers of CBC encryption with DES instead of a single layer in which
the block cipher is three consecutive DES operations.
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED
Date: Tue, 23 Mar 1999 20:50:40 GMT
[EMAIL PROTECTED] (Doug Stell) wrote, in part:
>On Sat, 20 Mar 1999 03:46:01 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
>wrote:
>>John Savard wrote:
>>> The use of KEA with FORTEZZA at least appears to indicate that the NSA now
>>> trusts public key methods - with *unclassified*, but sensitive,
>>> information.
>Initially, some of us thought the above statement was meant as a joke.
Oh, I was serious, if a bit whimsical as well as guarded.
Basically, I was responding to a poster who seemed to me to be saying that,
since KEA is public-key based, all the doubts about public-key methods
alluded to in the _Wired_ article are things of the past.
While he is at least partly right - presumably, if the NSA is authorizing
the use of public-key methods for certain purposes, it believes them to
offer security adequate to _those_ purposes - since the system he is
referring to is for traffic of the "unclassified but sensitive" category,
it doesn't constitute proof that Diffie-Hellman, with suitable restrictions
and modifications, is trusted enough to handle *everything* the encryption
of which the NSA is trusted with.
And, of course, the "appears" indicates that we can't know for sure what
goes on in the minds of a secret agency...perhaps they know how to crack
Diffie-Hellman, but it's such a closely guarded secret that they can't
disclose it by avoiding the use of public-key methods in publicly described
systems that people would *expect* to make use of such methods. I'm not
claiming anything about the _probability_ of that scenario, but I _cannot_
completely exclude it. (Several people have given what I admit are very
good reasons for viewing the probability of that scenario as extremely low.
Unlike RSA, the proof of the Taniyama-Shinomura conjecture probably was not
devised 10 years ahead of time in the secret toils of the NSA or GCHQ.)
>In Whit Diffie's landmark paper, "The First Ten Years of Public Key
>Cryptography," he gives the cover name of the algorithm and has a
>picture of the STU-III. The algorithm was described as "The
>Government's extensions to public key cryptography suitable for
>handling classified information" or something very much like that. To
>my knowledge. this was the only statement that could be made about the
>algorithm, which I first encountered over 15 years ago.
Well, if they have found a way to significantly enhance the security of
public-key methods (e.g., the way that EKE does it, or by allowing a wider
range of public-key algorithms by the use of a new concept) it is quite
understandable that it will remain a secret for a long time.
>Actually the private key is "split" between the phone and the CIK.
>Therefore, the CIK works only in one phone. The CIK, if compromised,
>is useless by itself.
And it makes sense they would take all possible precautions, which is, in a
sense, what I was recommending. (Incidentally, if you lose your bank card,
it is supposed to be useless without a combination of digits that you have
memorized. I trust the NSA has considered putting some of the private key
there too.)
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (STL137)
Subject: Re: Live from the Second AES Conference
Date: 23 Mar 1999 20:58:36 GMT
Merced isn't a supposed chip - it is definitely going to come out mid-2000.
-*---*-------
S.T.L. ==> [EMAIL PROTECTED] <== My quotes page is at: http://quote.cjb.net
~~~ My main website is at: http://137.tsx.org ~~~
If you see a message of mine posted on two newsgroups, then it is because I
have replied to a crossposted message. I *never* crosspost of my own accord!
I block all unapproved E-mail. If you wish to talk to me, post to alt.test.9
with the subject "Moo" and your E-mail address in the body. I will allow you
as soon as I sign on next.
"This universe is not hostile, or yet is it friendly. It is simply
indifferent" - John H. Holmes, The Sensible Man's View of Religion
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: triple-DES
Date: 23 Mar 1999 20:59:22 GMT
Triple DES is an ANSI standard X9.52. It describes modes of operation for
TECB, TCBC, TOFB and TCFB, as well as parallizable forms for the latter 3 modes
(TECB is inherently able to run in parallel).
Don Johnson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ElGamal vs RSA
Date: Tue, 09 Mar 1999 21:48:42 GMT
In article <[EMAIL PROTECTED]>,
Medical Electronics Lab <[EMAIL PROTECTED]> wrote:
> Sam Simpson wrote:
> >
> > BTW does anyone still use GF(2^n)? It said as long as 14-years
> > ago that GF(2^n) ought to be avoided in all cryptographic
> > applications - who would still consider it in the same breath as
> > GF(p)?
> >
> > Look forward to any pointers to more recent literature you may be
> > able to provide.
>
> Check out "Elliptic Curve Public Key Cryptosystems" for use of
> GF(2^n). Who said it should be avoided? Have you got a reference
> for that?
Would I dare offer such advice on sci.crypt without a citation ;-)
"Discrete logarithms in finite fields and their cryptographic significance"
A.M.Odlyzko
Though this paper may pre-date EC based systems.......
Regards,
Sam
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: Tue, 09 Mar 1999 18:09:16 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Testing Algorithms
<HTML>
Herman Rubin wrote:
<BLOCKQUOTE TYPE=CITE>In article <7c3n0g$5c0$[EMAIL PROTECTED]>,
<BR>Patrick Juola <[EMAIL PROTECTED]> wrote:
<BR>>In article <81dF2.705$[EMAIL PROTECTED]>,
<BR>>David Miller <[EMAIL PROTECTED]> wrote:
<BR>>>Herman Rubin ([EMAIL PROTECTED]) wrote:
<BR>>>: In article <7bm5lm$17k$[EMAIL PROTECTED]>,
<BR>>>: Patrick Juola <[EMAIL PROTECTED]> wrote:
<BR>>>: >In article <[EMAIL PROTECTED]>,
<BR>>>: >Shawn Willden <[EMAIL PROTECTED]> wrote:
<BR>>>: >>Withheld wrote:
<P>>>: >>> In article <[EMAIL PROTECTED]>, Darren New
<BR>>>: >>> <[EMAIL PROTECTED]> writes
<P>
................
<P>>>: >>You should take a look at the section in Schneier's book on thermodynamic
<BR>>>: >>limitations to brute-force attacks. He assumes an ideal
computer, one in
<BR>>>: >>which the energy required to change the value of one bit in the
processor is
<BR>>>: >>the smallest possible -- namely the quantum unit.
<P>>>: >And, has been REPEATEDLY pointed out in this forum, he gets this
<BR>>>: >dead wrong as the smallest possible unit of energy for computing
is
<BR>>>: >zero if you use reversible computations and get it back.
<BR>>>:
<BR>>>: One might be able to use reversible COMPUTATIONS, but they will
<BR>>>: not get the energy back. A device capable of maintaining
a bit
<BR>>>: requires some sort of a hysteresis loop to keep the bit from
<BR>>>: drifting uncontrollably. The second law intrudes.
<P>>And what's the minimum possible size for such a loop?
<P>>We don't need to get the energy down to zero exactly. Merely
<BR>>sufficiently close -- which will mean that the total amount of energy
<BR>>necessary is 2^256 * epsilon, which is still arbitrarily small.
<P>>>Doesn't the reversibility require the storage of state? IE,
wouldn't
<BR>>>zero energy counting to 2^256 require a minimum of 2^256 bits of
<BR>>>storage?
<P>>Depends on how intelligently you use the state bits, I suspect.
<P>>And in theory, there's no limit to the number of states you can store
<BR>>in a single atom. How many states are there for an excited hydrogen
<BR>>atom?
<P>The number of possible states is infinite. BUT it gets harder
and
<BR>harder to maintain them; in fact, all except the ground state will
<BR>decay spontaneously.
<P>The problem is not how many states there are; it is how many stable
<BR>states there are, and also how much energy it takes to change from
<BR>one stable state to another. One CAN sometimes increase the numbe
<BR>of states by using energy to maintain them, using error correcting
<BR>codes and using energy to refresh the states, etc. But some energy
<BR>will have to be used.</BLOCKQUOTE>
Yes. But the limit on the amount of energy per bit processed is a
technological limit, not a fundamental scientific limit. In fact,
there *is* no fundametal scientific limit to how close to zero we can get.
<BLOCKQUOTE TYPE=CITE>
<P>--
<BR>This address is for information only. I do not claim that these
views
<BR>are those of the Statistics Department or of Purdue University.
<BR>Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
<BR>[EMAIL PROTECTED]
Phone: (765)494-6054 FAX: (765)494-0558</BLOCKQUOTE>
</HTML>
------------------------------
** 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
******************************
