Cryptography-Digest Digest #205, Volume #9 Tue, 9 Mar 99 06:13:04 EST
Contents:
Re: DIE HARD and Crypto Grade RNGs. (Jim Gillogly)
Re: Looking for encryption algorithm (BORIS KAZAK)
Re: Symmetric vs. public/private (Nicol So)
Re: ElGamal vs RSA ("Roger Schlafly")
Re: Entropy and Crypto-Grade Randomness (BORIS KAZAK)
Re: ElGamal vs RSA ([EMAIL PROTECTED])
Fingerprinting as a password (MC1148 User)
100% ANONYMOUS, NO CREDIT CARD, NO SUBSCRIPTION, NO PASSWORD,NOCENSURING (Follow me)
UK Opportunity ([EMAIL PROTECTED])
Re: ElGamal vs RSA ("Sam Simpson")
Re: Scramdisk - Possible Virus ("Sam Simpson")
----------------------------------------------------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Mon, 08 Mar 1999 16:22:43 -0800
Reply-To: [EMAIL PROTECTED]
R. Knauer wrote:
> You must use base 10. That is the only base that Champernowne's number
> is known to be normal in the Borel sense.
OK. Define ch10(n) to be the start of the base 10 Champernowne number
ending with the decimal expansion of n. Using standard gzip,
ch10(1000) compresses by 49.6%
ch10(10K) compresses by 52.3%
ch10(100K) compresses by 55.5%
ch10(1M) compresses by 63.3%
ch10(10M) compresses by 69.0%
ch10(100M) compresses by 73.1%
By contrast, a file of about 5M randomish (i.e. the output of /dev/urandom)
decimal digits compresses by 53.0% (I threw away numbers 250-255 and took the
rest mod 10), verified with three independent runs. It seems to me a fixed
Huffman code with 6 3-bit codes and 4 4-bit codes would result in a slightly
better result for random digits, about 57.5% compression if my numbers are
right (assign 0-9 to 000 001 010 011 100 101 1100 1101 1110 1111). I assume
gzip is getting burned by continually changing its dynamic Huffman table.
As with the binary case, adjacent numbers will share most of their digits,
so a compresser that understands duplicated strings in a local environment
will always win. Intuitively compression would get arbitrarily close to
100% as you do more and more of the C #. If C's # is normal in the Borel
sense, then there's more to randomness than Borel normality.
--
Jim Gillogly
Highday, 16 Rethe S.R. 1999, 23:45
12.19.6.0.1, 9 Imix 14 Kayab, First Lord of Night
------------------------------
From: BORIS KAZAK <[EMAIL PROTECTED]>
Subject: Re: Looking for encryption algorithm
Date: 9 Mar 1999 03:34:50 GMT
Reply-To: [EMAIL PROTECTED]
John Savard wrote:
>
> [EMAIL PROTECTED] (kufan) wrote, in part:
>
> > Does anyone know any kind of encryption algorithm that
> >using 2 or more keys to encrypt and using 1 key to decrypt,
> >and the encryption speed will be as fast as symmetric
> >encrypt algorithm?
>
> It isn't clear exactly what you are looking for.
>
============================
Seems very clear: he is looking for a cipher that would have a
"Master Key" to decrypt messages encrypted with a variety of
different keys.
Dream of the BIG BROTHER...
Sorry, such stuff is not very respected in this forum.
Best wishes BNK
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Symmetric vs. public/private
Date: Mon, 08 Mar 1999 23:51:25 -0500
Billy Cole wrote:
>
> I currently have the need to incorporate encryption
> into an application. I've been doing a lot of reading
> and still can't come up with an answer as to whether
> to use the public/private key method or a symmetric
> approach. Assuming I have no requirement to conform
> to the public/private key method, what will I gain/lose
> using that approach? The symmetric approach looks good
> because of speed, licensing issues, and I like the fact
> that I don't have to have a key server in the middle of
> all of this. On the other hand there are key distribution
> issues with the symmetric approach which become awkward
> because I have a requirement that more than 2 people
> could be sharing a key. I would really appreciate some
> "real world" input on this. I would also appreciate any
> pointers to papers that discuss the pros and cons.
The main thing that you gain by using public key cryptography is
simplification of key management.
First, there are fewer keys to deal with. With shared-key ciphers, if
you have a pool of N communicants, you'll need N(N-1)/2 keys to
cryptographically separate the traffic of all pairs of communicants.
With public key cryptography, you only need N key pairs.
Second, public key cryptography removes the confidentiality requirement
on the key distribution channel. You still need integrity though, i.e.
you still need assurance that a public key really belongs to its
purported owner. In many situations, removing the confidentiality
requirement greatly simplifies handling of keys.
Other advantages of public key crypto include: possibility of
constructing a digital signature scheme (e.g. RSA), perfect forward
secrecy (e.g. authenticated Diffie-Hellman).
The main disadvantage of public key crypto is inefficiency. Public key
ciphers typically have significantly longer keys and much lower
throughput than their shared-key counterparts.
BTW, you don't *need* a key server with public key crypto.
Nicol
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: ElGamal vs RSA
Date: Mon, 8 Mar 1999 19:39:07 -0800
Michael Sierchio wrote in message <[EMAIL PROTECTED]>...
>Both RSA and ElGamal have their merits. I'd
>say that RSA certainly has a lead in terms of maturity, marketing,
>licensing and reference implementation. These factors often matter
>more for security's sake than the algorithm itself.
These factors are important, but they do not give RSA a clear-cut
edge. When people say "ElGamal" they usually mean encryption,
in which case it is nearly identical to Diffie-Hellman. Diffie-Hellman
predates RSA and is widely used commercially. Licensing is cheaper
and easier with Diffie-Hellman because the patent has expired and
it is in the public domain.
------------------------------
From: BORIS KAZAK <[EMAIL PROTECTED]>
Subject: Re: Entropy and Crypto-Grade Randomness
Date: 8 Mar 1999 04:23:44 GMT
Reply-To: [EMAIL PROTECTED]
R. Knauer wrote:
> ....
> True randomness is a process, not a thing. It is an act, not an
> object. Entropy attempts to characterize that act, to measure how
> random that act is. If the entropy of that act is maximal, then the
> act is taken to be random.
>
> The problem with that concept is that there is one thing missing,
> namely that the act must operate on a sample space that has ALL
> possibilities in reality present. Operating on a subspace of limited
> possibilites can lead to maximal entropy, but that does not mean that
> the process is truly random.
>
> For example, if I reach into a jar that has only odd numbers in it -
> that is, I have deliberately excluded the even numbers - the entropy
> of that limited selection process may be maximal, but it is not truly
> random. If I color the even numbers white and the odd numbers black,
> all I would ever do is select black numbers, since I excluded all the
> white ones. That makes the entropy zero, yet that is the maximum it
> can attain in that sample space.
>
> Bob Knauer
>
=========================
Will you let a layman insert some humble words...?
The discussion is presumably centered around *crypto-grade* random
numbers, and more specifically around numbers usable for an OTP.
Let us descend down from the theoretical heavens to the practical
Earth and figure out on a small model, what is necessary for an OTP
encryption to be worth its name and reputation. The concept of a jar
will serve the purpose very nicely.
First let us assume that the plaintext is an ordinary English text
written with a 64-character alphabet (26 letters, 10 digits, space,
newline, comma, period, etc). For most practical purposes this alphabet
will be perfectly adequate.
Next let us assume that for the purposes of transmission this text
is converted into the sequence of bytes, values 0 to 63 will be used
out of possible 256. No wonder if this sequence of bytes will appear
terribly biased.
Now for the purposes of encryption we must have some chips in the
jar with the numbers written on them. We will draw these chips at
random (returning the chip back to the jar !) and XOR each consecutive
number with each consecutive byte in order to produce ciphertext.
Let us start with 2 chips with the numbers 0 and 1 written on them.
This will be equivalent to approximately half of characters being
not altered at all, with the other half being replaced by adjacent
item in the alphabetic sequence. Funny, isn't it? This is even worse
than monoalphabetic substitution, language patterns will allow anybody
to easily correct all the misspellings.
For example:
with the pad 1001011001101010
plaintext THREE BLIND MICE
yields SHRFE,ALIMC NIDE (assuming comma is adjacent to
space)
Now we add one chip, and this chip has number 2 written on it.
The same example:
with the pad 1012102021210201
plaintext THREE BLIND MICE
yields SHQGF DLLMB,MKCF (assuming comma is adjacent to
space)
This is already much better, only about a third of the characters
retain their identity, the rest are substituted from 2 different
substitution alphabets *at random*.
Bringing the process to its extreme, we place in the jar 64 chips
with numbers from 0 to 63.
I think it is obvious that the pad produced by this assortment of
chips will be perfectly adequate for encryption of any English text.
The ciphertext can be decrypted equiprobably to any possible English
plaintext of the same length. However, the sequence of bytes used
for encryption will appear to be strongly biased, with 3 higher order
bits equal 0, and will not pass any statistical test whatsoever.
So where is the threshold which divides the *bad* pads from the
*good* ones? In my understanding, it is the enthropy *per element of
the pad*. So even if the RNG (of course, TRNG, my apologies...) is
biased and produces sequences with insufficient enthropy per element,
we can always combine several elements in order to achieve the
elusive goal of generating the pad with sufficient enthropy per each
element. In extreme cases this might require using the pad with the
number of bits per element greater than in the plaintext, so what?
If we use the pad with 16-bit elements in order to encrypt a sequence
of 8-bit bytes, this will result in doubling the ciphertext size,
many conventional ciphers do it already.
Finally, about a hardware TRNG, I have an idea of a circuit based
on a pair of noise diodes which will produce a random *unbiased*
sequence of bits at a rate about 1 Mhz. I have not modeled it yet,
but the circuit appears to be very straightforward and simple. If
there will be further development, I'll let you know.
Respectfully BNK
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ElGamal vs RSA
Date: Mon, 08 Mar 1999 23:54:50 -0600
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
In <7c2572$[EMAIL PROTECTED]>, on 03/08/99
at 07:39 PM, "Roger Schlafly" <[EMAIL PROTECTED]> said:
>Michael Sierchio wrote in message <[EMAIL PROTECTED]>... >Both
>RSA and ElGamal have their merits. I'd
>>say that RSA certainly has a lead in terms of maturity, marketing,
>>licensing and reference implementation. These factors often matter
>>more for security's sake than the algorithm itself.
>These factors are important, but they do not give RSA a clear-cut edge.
>When people say "ElGamal" they usually mean encryption, in which case it
>is nearly identical to Diffie-Hellman. Diffie-Hellman predates RSA and is
>widely used commercially. Licensing is cheaper and easier with
>Diffie-Hellman because the patent has expired and it is in the public
>domain.
Well my experience with RSADSI:
In the few times that I have talked with them everyone has been
universally arrogant.
They do *not* release source code for their toolkits.
I find their licensing requirements unacceptable.
IMHO I have not seen anyone present a good case to use RSA over ElGamal.
- --
- ---------------------------------------------------------------
William H. Geiger III http://www.openpgp.net
Geiger Consulting Cooking With Warp 4.0
Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii
- ---------------------------------------------------------------
Tag-O-Matic: This is a TAG-O-Matic
Multi-line Sample
Tag
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.0i OS/2 for non-commercial use
Comment: Registered_User_E-Secure_v1.1b1_ES000000
Charset: cp850
wj8DBQE25Li6lHpjA6A1ypsRAujLAJ99mYR017FyNrAa96qFyxHokOTK7QCgprnh
QNhVeXn+NZktKEGbg7qUDwM=
=JCVz
=====END PGP SIGNATURE=====
------------------------------
From: MC1148 User <[EMAIL PROTECTED]>
Subject: Fingerprinting as a password
Date: Tue, 02 Mar 1999 17:33:51 -0500
Hi. I am a student at Bloomsburg University. I am working on a project
that would explain how fingerprinting works, and the information I have
found has not given me the mathematical information that I am searching
for. If anyone could help in this search, it would be greatly
appreciated. You may email me at [EMAIL PROTECTED] or just
post to the newsgroup. Thank you for your time.
------------------------------
From: [EMAIL PROTECTED] (Follow me)
Subject: 100% ANONYMOUS, NO CREDIT CARD, NO SUBSCRIPTION, NO PASSWORD,NOCENSURING
Date: Tue, 09 Mar 1999 06:52:44 GMT
100% ANONYMOUS, NO CREDIT CARD, NO SUBSCRIPTION, NO PASSWORD,NOCENSURING
Italian
www.thirdsex.com
English
www.xxx1on1.com
------------------------------
From: [EMAIL PROTECTED]
Subject: UK Opportunity
Date: Tue, 09 Mar 1999 08:39:11 GMT
Apologies for my intrusion:
WANTED: C++, OOD Programmers with an appreciation for Security and ideally
knowledge of cryptography.
You will be working with one of Europe's leading players in the race for
domination of the E-Commerce/Security Market Place.
Please contact me asap for further information.
Regards,
Mark.
PS. All applicants should be aware of current European immigration laws.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: ElGamal vs RSA
Date: Tue, 9 Mar 1999 08:40:54 -0000
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
"Discrete logarithms are, with the present state of knowledge,
slightly more difficult to compute modulo an appropriately chosen
prime than it is to factor a "hard" integer of the same size".
- -- The future of integer factorization by A.M.Odlyzko (1995). Is
this information now out of date?
Well, I asked on sci.crypt a couple of months ago to clarify on
this point and got similar responses from Roger Schlafly:
"Breaking a 512-bit DSA key is significantly more difficult [than
an RSA key]"..."The asymptotics are similar. But breaking DH
(ElGamal or DSA) requires some large tables. Much larger RSA
keys have been broken than DH keys."
- -- "Re: Opinions on S/MIME", sci.crypt, ~30 Dec 98
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.
- --
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!
[EMAIL PROTECTED] wrote in message
<7bvhm6$4t1$[EMAIL PROTECTED]>...
>In article <7buglm$a6g$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> In article <[EMAIL PROTECTED]>,
>> "F. Arndt" <[EMAIL PROTECTED]> wrote:
>> > A novice question: Is it generally accepted that the
ElGamal is much
>> > less secure than the RSA for comparable key lengths?
>>
>> No. DH /Elgamal offers slightly more security per key bit
than RSA.
>
>Please. For my edification and enlightenment, define what you
mean by
>"slightly more". Please explain why you think the claim is
true.
>
>I have heard this remark before. While it is true, "slightly"
should be
>"very slightly". And the reason why is subtle. And it depends if
the
>field is GF(p) or GF(2^k).
>
>I'd like to find out if anyone in this newsgroup knows the REAL
reason
>why solving a DL problem over Z_p is slightly harder than
factoring N = st
>when log(N) ~ log(p). Note that solving a DL problem over
GF(2^k) where
>k ~ log_2(N) is EASIER than factoring N.
=====BEGIN PGP SIGNATURE=====
Version: PGP 6.0.2
iQA/AwUBNuTebu0ty8FDP9tPEQJFiwCfbXIHc2GIky8pPYVDBs3KBuJrNXIAnjqA
Ya4bkPRbNOzevW74mXA+0TV7
=pSiB
=====END PGP SIGNATURE=====
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Scramdisk - Possible Virus
Date: Tue, 9 Mar 1999 10:03:08 -0000
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Further to my previous response, I have now checked all of the
downloads (including Word docs <g>) with a number of Virus
detection packages (all patched and updated) and all the programs
report the same - "NO VIRUS".
Please let me know the SW you are using (and the virus it
reported).
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!
[EMAIL PROTECTED] wrote in message
<7c1e64$oqk$[EMAIL PROTECTED]>...
>What virus? What virus detection sw?
>
>This *must* be a false detection - McAffee & Dr Solomons (with
newest pattern
>files) have turned up negative. Even so, this report is of
concern.
>
>Please supply more information (download site etc).
>
>
>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.
>
>In article <[EMAIL PROTECTED]>,
> Paul Roskos <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> I just downloaded the program from the Scramdisk web site, and
>> our corporate anti-virus program detected a virus.
>>
>> Can anyone point me to an anternate site where the program can
be
>> downloaded?
>>
>> Thanks for any help.
>>
>> Paul
>>
>
>-----------== Posted via Deja News, The Discussion Network
==----------
>http://www.dejanews.com/ Search, Read, Discuss, or Start
Your Own
=====BEGIN PGP SIGNATURE=====
Version: PGP 6.0.2
iQA/AwUBNuTx2O0ty8FDP9tPEQLKMQCfRUa0RrEhQiBuu/++QgNw22JjeskAn3mt
s7G8orzkgtrD1SbfZk+Q8ZUY
=Uhtj
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
