Cryptography-Digest Digest #867, Volume #8 Fri, 8 Jan 99 16:13:04 EST
Contents:
Re: On the Generation of Pseudo-OTP (Mok-Kong Shen)
RSA question (Rx Video)
Learn Encryption Techniques with BASIC and C++ (CryptoBook)
Re: On the Generation of Pseudo-OTP (R. Knauer)
Re: RSA-Modulus decomposition (Gary Woods)
Re: On the Generation of Pseudo-OTP (R. Knauer)
Re: On the Generation of Pseudo-OTP (Mok-Kong Shen)
Factoring ("Michael Scott")
Re: Factoring ("Tony T. Warnock")
Hiding data in jpeg files - Beta test versions of programs available (Allan Latham)
Re: ScramDisk - password size - high ASCII (Jim Dunnett)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On the Generation of Pseudo-OTP
Date: Fri, 08 Jan 1999 16:02:18 +0100
R. Knauer wrote:
>
> I realize that. But I am pointing out that by using the term "pseudo
> OTP", you are implying that it is a good approximation to an actual
> OTP.
>
> There is a *fundamental* difference between a natural language text
> stream - however you doctor it - and the output of a TRNG.
Well, as foreigner I am not competent in discussing the exact
implication of an English word. I myself have no assocation between
'pseudo' and 'good', rather some between 'pseudo' and 'not perfect'.
(I stressed e.g. in my article on my WEAK4-EX, that by using
a PRNG to simulate a probabilistic automaton one in fact gets a
deterministic process, i.e. strictly speaking not probabilistic at
all.) Again I am convinced that by combining a sufficiently large
number n of text using appropriate techniques one arbitrarily
comes near to a good OTP.
>
> >I was simply calling attention to a (I believe)
> >possibly fruitful way of obtaining something (I term it pseudo-OTP)
>
> And it is that usage to which I object, not on pedantic grounds but
> because it is fundamentally incorrect usage.
In which way do you mean incorrect? Why is on the other hand hardware
OTP, which is also inperfect, correct??
>
> >that could, on the assumption that suitable techniques (either
> >currently known as I sketched or yet to be developed or refined)
> >are applied,
>
> We already discussed/debated that whole matter a year ago and
> concluded that a text cipher, no matter how you buggered it, is still
> fundamentally different from an OTP generated by a TRNG.
If you mean OTP here an ideal one, yes. But not necessarily so
for an OTP generated by a real physical process.
>
> >approximate an ideal OTP
>
> One cannot "approximate" an OTP per se. One can approximate the
> unbreakability, perhaps.
O.K. Then a hardware device also cannot appoximate an (ideal) OTP
in your (present) logic.
>
> I think what you are trying to say is that it may be possible to
> concoct a text stream cipher that is, to a very good degree of
> approximation, as good as an OTP.
>
> >to some (for practical
> >purposes) satisfactory degree just as some good hardware devices
> >are supposedly already doing that way.
>
> That remains to be proven. The discussion a year ago raised serious
> doubts with respect to text streams. The problem was how to remove the
> inherent correlations in the least significant bits selected for the
> bit sequence. I proposed using the decorrelation methods described by
> Schneier in his main book, but others claimed that such methods did
> not remove text stream correlations, even if the stream were
> antiskewed first.
Note that one technique I mensioned is to take the parity of a
32 bit words. That is from 4 bytes, originated from 4 characters,
one takes one bit. That should be highly effective, I believe,
to destroy the auto-correlations that are present in the character
sequence of the texts. And if that is not enough, one can apply
other techniques and these recursively, as I said in the original
post.
>
> >I hope that this clears
> >up some misunderstandings. I don't doubt that much experiments
> >are needed in order to get really good pseudo-OTP.
>
> I still object to the use of the term "pseudo-OTP" as being
> fundamentally incorrect.
>
> Look, I used the same term a year ago and got my stuff jumped from all
> quarters. And I ended up agreeing with those critics because the point
> they were making had very fundamental significance.
I think the choice of the name is unessential. Essential is the
purpose that a thing serves. You could instead call it, say, 'a
somehow generated bit sequence intended to approximate an OTP
to some satisfactory degree', if you don't mind the length of the name.
>
> The fact that it took some thousand to get it right is a measure of
> how confusing this topic can be, largely due to prejudices that come
> from learning statistical mathematics.
>
> >Music and voices are also good sources for use in similar sense
> >as the texts, if devices are available to digitalize them. Note that
> >I am not anti-hardware.
>
> I was thinking of a music CD.
>
> >A physical device may, if one wants, be
> >integrated in my proposed scheme.
>
> A music CD represents the data that comes from physical devices,
> namely musical instruments and associated electronics, and therefore
> is different from a natural language text stream. There is enough
> music to download on the Internet to make text unnecessary as a source
> for a stream cipher.
>
> Also, human speech might work. It might turn out that one of the best
> sources of randomness is a political speech, like a debate on the
> floor of congress. The recent impeachment debates in the House could
> very well be a very rich source of complete randomness for decades to
> come.
>
> Or if you want to engage in irony, use the speeches that were given in
> the congressional debate over key length legislation. IOW, use the
> politicians own verbalizations to encrypt unbreakable messages. :-)
But note that there are also auto-correlations. In general, akin to
the texts, many sources can be used, for instance digitalized pictures,
photos, etc.
M. K. Shen
------------------------------
From: Rx Video <[EMAIL PROTECTED]>
Subject: RSA question
Date: Fri, 08 Jan 1999 12:46:46 -0500
Hello,
I've recently read through the theory on RSA algorithm. I just wanted to
make sure if the factorization of the N (modulus) number is the keystone
of its security ?
p*q=N - I have not tried to compute all the possible values for p and q
with known N, but the approach to find those values would be to divide N
by i, with i increasing with every step (or changing i to the next prime
number), until one of p or q is found. I do not know how difficult that
task is for sufficiently long N. I would appreciate a comment on this
one.
Sincerely yours,
Martin
------------------------------
From: [EMAIL PROTECTED] (CryptoBook)
Subject: Learn Encryption Techniques with BASIC and C++
Date: 08 Jan 1999 17:46:56 GMT
Classical Crypto Books is pleased to announce that the following major new book
is in stock and ready for immediate shipment.
Learn Encryption Techniques with BASIC and C++
by Gilbert Held
The development of computer programs to encipher and decipher messages by
classical techniques is the primary focus of this book. A distinctive feature
is the use of two different programming languages, Microsoft QuickBasic and
Visual C++, for all program examples. In eight chapters, the author covers:
Technology and Terminology, Monoalphabetic Substitution Concepts, Keyword-Based
Monoalphabetic Substitution, Transposition-Based Monoalphabetic Substitution,
Polyalphabetic Substitution, Using Random Numbers, Developing Practical
Programs, Public Key Encryption. An appendix describes the contents of the
companion CD-ROM (i.e., source code listings and executables for all programs).
Wordware Publishing, 1999, xiv + 402 pp, CD-ROM.
Softbound: Pub. $39.95, Member $30.95
Member prices are available to members of the American Cryptogram Association,
the US Naval Cryptologic Veterans Association, and full time students. A
shipping and handling charge applies to each order. Visa and MasterCard are
accepted. For complete ordering information, a free catalog of crypto books
stocked, or for information about membership in the American Cryptogram
Association, please send email to [EMAIL PROTECTED]
Best Wishes,
Gary Rasmussen
Classical Crypto Books
E-Mail: [EMAIL PROTECTED]
Fax: (603) 432-4898
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Fri, 08 Jan 1999 19:08:31 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 8 Jan 1999 18:44:27 +0100, <[EMAIL PROTECTED]>
wrote:
>The best approximation of an OTP is a hardware TRNG based on quantum
>mechanics: The effects used for this TRNG are neither reproducable nor can
>be foreseen using any technology we know at the moment, and - if our
>theories are not completely wrong - they will be unforseeable forever.
You don't believe in Hidden Variable theories, eh.
>The main problem is to make such a device statistically good or we
>wouldn't get an unbreakable cipher.
A TRNG has only one "statistical" property, namely that it is capable
of outputting all sequences of a given finite length equiprobably.
That, however, is not verifiable - not even "statistically". The best
you can do is test a TRNG to see if it does something which violates
its prime directive, like output all 0s in worst case.
I remind you that you cannot decide by formal means if TRNG or its
output is truly random, only that they are *not* truly random. The
reason for this goes to the heart of number theory. (See Chaitin, op.
cit.)
>My suggestion is to make the device as
>good as possible and hash a larger amount of the output to generate the
>pad.
There are cryptographers who would disagree that a hash is suitable to
"randomize" the output of a faulty TRNG. The reason is that all
algorithmic procedures introduce non-random characteristics such as
periodicity and correlation by their very nature.
I would have thought that the scheme for removing correlation that
Schneier discusses in his main book would have done the trick, since
it involved the simple "mixing" of two or more streams. But someone
who claimed to know what he was talking about said that is not the
case.
>While this system is not perfect it is much better than everything that
>could be done in software: Whatever is done using software is
>reproducable.
So is hashing. Once the attacker discovers that you are hashing the
output of a faulty TRNG, he can presumably use that against you.
Bob Knauer
"We hold that each man is the best judge of his own interest."
--John Adams
------------------------------
From: [EMAIL PROTECTED] (Gary Woods)
Crossposted-To:
alt.privacy,alt.security,alt.security.pgp,comp.security.pgp.discuss,talk.politics.crypto
Subject: Re: RSA-Modulus decomposition
Date: Fri, 08 Jan 1999 19:14:57 GMT
[EMAIL PROTECTED] (David Hamilton) wrote:
>This is how things are. Alex ([EMAIL PROTECTED]) makes silly, =
untrue
>claims.=20
This one has been 'round the horn several times. I started out thinking =
Alex was simply a troll,
but now I believe he's a genuine card-carrying loony who believes his =
mathematical drive. He _is_
smart enough to not accept any challenge to his clearly silly statements.
Mine still stands.... email me something signed with my private key, and =
I'll listen further....
--=20
Gary Woods O- K2AHC Public key at www.albany.net/~gwoods, or get =
0x1D64A93D via keyserver
[EMAIL PROTECTED] [EMAIL PROTECTED]
fingerprint =3D E2 6F 50 93 7B C7 F3 CA 1F 8B 3C C0 B0 28 68 0B
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Fri, 08 Jan 1999 19:11:52 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 08 Jan 1999 18:23:25 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>If you like to rank yourself with Goedel and Russel
Where did I ever say any such thing?
> then I
>suggest that you first keep all discussions tightly within the
>bounds of the science of cryptology.
I am pointing out that there is no formal procedure to decide that a
number is truly random. That is about as "tightly bound" to crypto as
it can get.
Bob Knauer
"We hold that each man is the best judge of his own interest."
--John Adams
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On the Generation of Pseudo-OTP
Date: Fri, 08 Jan 1999 19:16:38 +0100
[EMAIL PROTECTED] wrote:
>
> The ideal OTP can't be reached - neither in hardware nor in software.
Thanks for stating this. I had apparently not much success in
doing the same.
>
> The best approximation of an OTP is a hardware TRNG based on quantum
> mechanics: The effects used for this TRNG are neither reproducable nor can
> be foreseen using any technology we know at the moment, and - if our
> theories are not completely wrong - they will be unforseeable forever.
> The main problem is to make such a device statistically good or we
> wouldn't get an unbreakable cipher. My suggestion is to make the device as
> good as possible and hash a larger amount of the output to generate the
> pad.
>
> While this system is not perfect it is much better than everything that
> could be done in software: Whatever is done using software is
> reproducable. Once the key is smaller than the message the system is
> provably not as secure as OTPs. On the other hand if the key is at least
> as large as the message the problem to generate the key is equivalent to
> the problem to generate a OTP.
>
> There are some special problems that can be solved using OTPs based on
> hardware. In this case it wouldn't make sense to use the much weaker
> software to solve the problem.
>
> In all other cases I wouldn't even think about OTPs and use the present
> cryptographic systems or develope new ones based on existing technology.
However the context of my proposal is that one can only get
56-bit cryptos (and very likely only software). So I think that even
a not so good approximation of an OTP helps to a certain degree, for
it can be used in conjunction with a 56-bit crypto software and
enhance its strength. We have to collect all useful things and
combine them, so that those who can only get 56-bit cryptos (those
outside of the 33 countries) can still obtain adequate security
in their communications.
M. K. Shen
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Factoring
Date: Fri, 8 Jan 1999 19:37:43 -0000
15 years ago the biggest "difficult" number to be factored (that is the
product of two large primes) was (10^71-1)/9. This record factorisation was
acheived by Davis & Holdridge at Sandia National Laboratories, requiring 9.5
hours on a Cray XMP.
Things have of course moved on since, but the standard Home Computer has
finally caught up, and this number can now be factored in about 5 hours or
less on the basic 266MHz, 32Mb Pentium box.
So, announcing an updated version of my free Windows NT/'95 Command Prompt
factoring program ftp://ftp.compapp.dcu.ie/pub/crypto/factor.exe
This 32-bit program uses 6 different factoring algorithms, culminating in
the multiple polynomial quadratic sieve. This latter uses a lot of memory
for bigger numbers.
However don't expect to set records - modern factoring algorithms
parallelise almost perfectly, so records are set on networks of computers
working together, not on solo workstations.
--
Mike Scott
=========================================
Fastest is best. MIRACL multiprecision C/C++ library for big number
cryptography
http://indigo.ie/~mscott
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Factoring
Date: Fri, 08 Jan 1999 12:56:06 -0700
Reply-To: [EMAIL PROTECTED]
Michael Scott wrote:
> 15 years ago the biggest "difficult" number to be factored (that is the
> product of two large primes) was (10^71-1)/9. This record factorisation was
> acheived by Davis & Holdridge at Sandia National Laboratories, requiring 9.5
> hours on a Cray XMP.
Actually the work was done at Los Alamos National Laboratory. It did require 9.5
hours on a 1 processor XMP (9.5 nseq cycle). Better math would reduced it to
about 1 hr. Better programming to only a few minutes. I ran the code after
rewriting one loop to get a 100 fold speedup. (At Davis and Holdridge request.)
I debugged the code on 58 and 60 digit numbers that had been claimed to take
over a century to factor (30secs and 5 mins). The quadratic sieve (and I guess
other sieves) map very well onto vector architures. (I explained how this
mapping of the algorithm, one Cray cycle per operation, would work and the D&H
wrote the code.)
Tony
------------------------------
Date: Thu, 07 Jan 1999 21:46:03 +0100
From: Allan Latham <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Hiding data in jpeg files - Beta test versions of programs available
=====BEGIN PGP SIGNED MESSAGE=====
Is there anyone who would like to test the latest versions
of JPHIDE and JPSEEK and JPHSWIN for me?
These are DOS and Windows 95 programs which hide data in
jpeg files using a pseudo random number generator based on
blowfish and keyed from a user entered pass phrase.
In particular I am interested if anyone can detect the
presence of the hidden data in the absence of the original
unmodified jpeg as a reference. i.e if I give you a jpeg file
you have never seen before can you say with any given degree
of certainty that it contains hidden data.
The package is avilable from:
http://pweb.de.uu.net/flexsys.mtk/jphs_05.zip
It contains:
JPHIDE.EXE
JPSEEK.EXE
JPHSWIN.EXE
README
in a zip file
plus a PGP signature file.
My PGP key is available from http://pweb.de.uu.net/flexsys.mtk
Allan Latham <[EMAIL PROTECTED]>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
iQCVAwUBNpUOjOJCY/+xqTOxAQFMeQP8C4oz3iSNv7ioqIeKmyAScDYRB/8P21AB
hfGP8S9lROqm9LDdS25AyC5M3uamkrIo4WY2wYEEKrIn35S9tKO7QwRnLRdkjou5
EO4uOyAP1Yhn+CyjBuMvVQuwgaV2dNWzLU2S64YM8kzcM9kouN/GfXRWYjMltah1
yW6n0RQV/VA=
=vXb5
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Jim Dunnett)
Subject: Re: ScramDisk - password size - high ASCII
Date: Fri, 08 Jan 1999 20:34:39 GMT
Reply-To: Jim Dunnett
On Fri, 08 Jan 1999 10:52:51 GMT, [EMAIL PROTECTED] wrote:
>> however any serious
>> cryptographic system worth its salt :) either "hashes" or otherwise
>> scrambles its passwords, before using them as keys, or uses a cipher
>> whose ciphertext is relatively random with respect to any arbitrary
>> key.
>
>I can confirm that ScramDisk uses a hash (SHA-1 to be specific) to compress an
>arbitrary length passphrase into a fixed width 160-bit digest.
So making it ridiculously long does not increase the
security by that much.
The structure of the passphrase is more important than
its length as such.
--
Regards, Jim. | A drunk man is more likely to find a
olympus%jimdee.prestel.co.uk | woman attractive. So if all else fails,
dynastic%cwcom.net | get him drunk.
nordland%aol.com | - Dr Patrick McGhee, who coaches women
marula%zdnetmail.com | on successful dating.
Pgp key: wwwkeys.uk.pgp.net:11371
------------------------------
** 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
******************************
