Cryptography-Digest Digest #470, Volume #9 Tue, 27 Apr 99 10:13:03 EDT
Contents:
Re: True Randomness & The Law Of Large Numbers (Herman Rubin)
Re: Amature information on cryptography? (CryptoBook)
Re: Obvious flaws in cipher design (Sandy Harris)
Re: Obvious flaws in cipher design (Sandy Harris)
Computing the run time for NFS. ("Steven Alexander")
Re: RSA-Myth (Anonymous)
S-Boxes ("Ruppert")
Re: scramdisk for AMAN ("Sam Simpson")
about analysis (let's see if I can explain this better...)
([EMAIL PROTECTED])
Re: Papers on RC4 key size (Nathan Kennedy)
Re: Papers on RC4 key size ([EMAIL PROTECTED])
Re: S-Boxes ("Douglas A. Gwyn")
Re: True Randomness & The Law Of Large Numbers (R. Knauer)
Re: True Randomness & The Law Of Large Numbers (R. Knauer)
Re: FSE-6 Report: Slide Attack (Patrick Juola)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: 26 Apr 1999 20:06:43 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On 25 Apr 1999 11:01:32 -0500, [EMAIL PROTECTED] (Herman
>Rubin) wrote:
>>You have suggested taking approximations as exact.
>When we were discussing the specification, we were talking about the
>ideal. When we were talking about an actual TRNG, we were talking
>about an approximation that was reasonably certain to be a
>representation of the ideal.
The precision desired here is comparable to that for a wheel,
and the accuracy available from measurement is far less.
--
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] (CryptoBook)
Subject: Re: Amature information on cryptography?
Date: 27 Apr 1999 01:10:41 GMT
In article <9o5V2.12119$[EMAIL PROTECTED]>, "Dan"
<[EMAIL PROTECTED]> writes:
>I am looking for information on encrypting text strings.
>
>I would prefer to find some sample source code written in Visual Basic as I
>haven't yet learned C or C++ As the subject suggests I am an amature at
>cryptography, I have wrote some very simple character shifting code (I
>hesitate to call it a cypher) but we all have to start somwhere right? What
>I am doing is encrypting fields in a Microsoft Access database for use with
>a program I am writing.
The following book from the CCB catalog may be of interest:
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, ACA 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] (Sandy Harris)
Subject: Re: Obvious flaws in cipher design
Date: Tue, 27 Apr 1999 01:40:29 GMT
[EMAIL PROTECTED] (Jaime Suarez) writes:
>Let's say that I am an amateur cryptographer and have written -just for the
>fun of it- an algorithm. I would like the group to explain me their 'top ten'
>reasons to see that it has obvious flaws. For example looking only at the
>output it shouldn't compress very much, right?
It shouldn't compress at all. It should be indistinguishable from
random noise. Any pattern is a weakness.
> or maybe change some bits of the input and see how the output comes out?
For a block cipher, change one bit of either input or key and about
half the output bits should change. This should be true after far
fewer rounds than the actual cipher uses.
For a stream cipher, changing one bit of key should change the
output a lot also.
> And what should I avoid in the algorithm itself?
Look at the sizes of everything. In a block cipher, block and key
should both be large enough to prevent the enemy attacking
with large tables. Current generation mostly have 64-bit block,
128-bit key.
Any password or passphrase used should have adequate
size, should not be stored or transmitted unencrypted, and
should be hashed before use.
A stream cipher should have an adequate amount of
internal state (>100 bits?) and a long period before it
repeats, perhaps 2^100 bits?
Any random numbers used should be strong. That's a whole
topic of its own. Start with RFC 1750.
>I am not talking about 'high' cryptanalysis here, just plain things.
>Thank you and sorry for my English.
>
I won't complain; it's whole lot better than my Spanish.
------------------------------
Subject: Re: Obvious flaws in cipher design
From: [EMAIL PROTECTED] (Sandy Harris)
Crossposted-To: alt.gothic,uk.people.gothic,boulder.general,at.test
Date: 27 Apr 1999 02:10:26 GMT
Reply-To: [EMAIL PROTECTED] (Henrietta K. Thomas)
Fuck You If You Aint Goth!!!
------------------------------
From: "Steven Alexander" <[EMAIL PROTECTED]>
Subject: Computing the run time for NFS.
Date: Tue, 27 Apr 1999 00:26:03 -0700
I'm not sure how to compute the run time for the number field sieve and
would like for someone to confirm this for me. The run time that I have for
the algorithm is
e^^[O(log^^1/3 n log log^^2/3 n)]
What I'm not sure about is:
Is n the value of the number to be factored, or its length in bits(I've seen
other problems represented this way)?
Are the logarithms of base 10 or base 2?
I've been using the value, not the length, of n, and a base of 10. Am I
correct? I hope that this isn't a dumb question. I just wanted to be sure
before relying to heavily on any of the numbers that I'm playing with.
Thanks in advance.
-steven
------------------------------
Date: Tue, 27 Apr 1999 11:16:31 +0200 (CEST)
From: Anonymous <[EMAIL PROTECTED]>
Subject: Re: RSA-Myth
> Be careful not to let too many politicians know about this for they might
> fear the competition.
A certain prominent politicians inaugural address...
This new what is our own renewal. We must define what America an idea
tempered by ancient hatreds and in our task today we must do no less.
Our mission is OUT, who is still by the new generation of deadlock and
discipline (deep divisions among our worry endlessly about who are
still by the face of winter but strong steps but less).
It is held in the very foundations of our made change we have borrowed
our ideals, from all, and demand more free, but we earn our founders
boldly declared America's independence to time nation we must play your
part voices in well, as we can feel the URGENT question of intrigue and
our founders boldly declared America's independence to reform our
history; democracy and not made change our the pain and our nation I ask
now universal? When others who is done so much to make our greatest
strength is still by ancient hatreds and when others who are people who
has already enriched the world warmed by the world, we inherit an
American renewal.
When the Persian Gulf, in our revolution, and who is.
------------------------------
From: "Ruppert" <[EMAIL PROTECTED]>
Subject: S-Boxes
Date: Tue, 27 Apr 1999 08:11:17 +0200
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Hi there,
i have a question abt S-Boxes.
How can a 8*8 Bit S-Box (like RC4) using 256 different indexes?
thx
Ruppert
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.0.2i
iQA/AwUBNyVG9i6671FxDS+qEQKnEgCg/XEErpl+HG/gDlex8mpVJr2TftsAoL7M
RxcKQ0y4mHqmvisI/G/y23qW
=ZFQS
=====END PGP SIGNATURE=====
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: scramdisk for AMAN
Date: Tue, 27 Apr 1999 09:56:28 +0100
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
The problem has not been resolved.
The workaround: dismount all ScramDisk containers before
defragging.
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!
m. bell <[EMAIL PROTECTED]> wrote in message
news:7fttpl$fs$[EMAIL PROTECTED]...
> looked at the program and docs and very interested. however, i
noticed in
> the documentation that problems can occur when the program is
installed and
> one runs a defrag. has this been resolved with the newest
version, occur on
> all machines, occur every time one tries to defrag, any work
around for the
> problem, etc?
>
> thanks mike
=====BEGIN PGP SIGNATURE=====
Version: 6.0.2ckt http://members.tripod.com/IRFaiad/
iQA/AwUBNyV7te0ty8FDP9tPEQJrQQCguy4XdPKRRIJnZvI1a5PbYSSSWlsAn3Ae
NQpSpzVd+8eOPINp+r8Rc91w
=AKIu
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED]
Subject: about analysis (let's see if I can explain this better...)
Date: Fri, 23 Apr 1999 11:24:46 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Ok let me see if I can rephrase the
question I asked...
Let's say I had an algorithm (A to D = input)
for r = 0 to rounds
A = A + ((B xor (D * S[2 * r])) <<< B)
C = C + ((D xor (B * S[2 * r + 1])) <<< D)
(B,C,D,A) = (A,B,C,D)
next r
What would be the first thing to examine with
relation to various popular attacks?
Thanks,
Tom
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.0.2i
iQA/AwUBNyBXG/IPgV4W6pz7EQJy1gCgnohR3SLDpx+Nwg2rlEnAGQtLnQQAmgOr
hiPOMR5hNpoSmeMb5UBjGgpX
=NfNL
=====END PGP SIGNATURE=====
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Nathan Kennedy <[EMAIL PROTECTED]>
Subject: Re: Papers on RC4 key size
Date: Tue, 27 Apr 1999 17:30:40 +0800
[EMAIL PROTECTED] wrote:
>
> Does anyone know of any papers that discuss the RC4 key-size? Any scientific
> account of relative strengths would be extremely usefull. Primary interest is
> the relative strengths of 40-bit and 128-bit keys, for SSL of course.
>
> Daniel
AFAIK, there has been research into weaknesses in the RSA key schedule
(solved by tossing some output or running the key setup multiple times),
and a few unexploitable statistical weaknesses. Naturally, until some
other weakness (other than the keyschedule weaknesses, which make certain
classes of keys "weak") in RC4 in found, the difficulty of breaking the
cipher is equal to the difficulty of keysearch, which is proportional to
2^b where b is the number of bits. So the obvious answer to your question
is, it is 309,485,009,821,345,068,724,781,056 times harder to break 128-bit
RC4 than 40-bit RC4... In practice, such large numbers have no meaning
after so many digits. Breaking 40 bits by brute-force is generally the
most straightforward since it would only take a week or so on an ordinary
desktop. With 128 bits, it simply is nowhere near possible. You would
either attack implementation weaknesses, or just cryptanalyze the cipher
until a new, unknown and unforseen weakness is found. As far as SSL, you
can find a good analysis paper about it at Counterpane.
Apologies if I misinterpreted your question.
Nate
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Papers on RC4 key size
Date: Tue, 27 Apr 1999 10:41:13 GMT
<snip>
There is a mini-weakness in the key schedule which is the fact that if you
repeat a byte (thru the entire key) is has an effective length of one byte.
This is the same as in Blowfish too.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: S-Boxes
Date: Tue, 27 Apr 1999 07:31:31 GMT
Ruppert wrote:
> How can a 8*8 Bit S-Box (like RC4) using 256 different indexes?
8 input bits => 2^8 = 256 indices
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Tue, 27 Apr 1999 11:55:08 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 27 Apr 1999 04:11:21 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>You keep insisting on absolute proofs, whereas the real world is one
>of relative degrees of certainty.
In this context I am interested only in analytical considerations.
>I'd sure choose the latter, which experience has shown is
>the correct policy.
Yes, I agree - but you did not choose the latter for analytic reasons.
However there is another consideration, which I have mentioned before.
What if I know you are monitoring my traffic and I decide to fake you
out. I send this ciphertext:
ATTACK AT DUSK
Unbeknownst to you the key is the XOR of that ciphertext with the real
message:
ATTACK AT DAWN
[NB: Yeah, I know - that requires sending that special key by a secure
channel, in which case I could just as well sent the message itself,
but it is my intent to trick you.]
Having received the above ciphertext you will conclude that my TRNG
has a shorted output. Little consolation for you when you discover the
hard way that you were tricked.
I would expect good cryptanalysts to know better than to rely on their
prejudices.
>This is the first mention of any mechanism other than simple XOR
>of a random keystream.
What you mean to say is that it is the first mention that you paid any
attention to.
If you had been paying full attention you would have recalled the
several exchanges we had on the topic of strong mixing, in particular
with Terry Ritter.
Go back in the archives and check out such keywords as {"strong
mixing" OR "latin square" AND Ritter AND Knauer}. You will find
several posts. But they were not in the context of purely analytical
considerations. In fact at that time we were discussing text-based
RNGs.
>If your "TRNG" works correctly, there is no
>need for anything fancier than a simple XOR.
I agree on analytic grounds. The reason for strong mixing is to make
up for any practical deficiencies of the RNG, which is not an analytic
consideration.
>If it is broken, the
>loss of security is easier to comprehend by considering how it
>affects the simplest reasonable application to encryption.
I agree. If the TRNG can't produce keystreams stong enough to be used
with the standard OTP and its XOR mixing scheme, then the TRNG is not
a strong keystream generator. But since we know that TRNGs are not
perfect, there is no harm in strong to forestall leakage of
information.
>No, I said what I said. The reason for testing the output stream
>is to *infer* something about the generator.
Unless you can point to an exact failure mode that results in the kind
of bias which is being tested for by the Monobit Test, you are
attempting to infer a property of the process.
If the test can be related directly to a known mode of malfunction,
like a floating or shorted output, then I would not object as long as
the test attempts to measure that condition directly, like a Long Run
Test would do.
What I do object to are those tests which purport to infer something
about the generation process itself. You cannot use single simplistic
small sample statistical tests of the output stream to infer anything
meanignful about the generation process itself.
You cannot infer the properties of the generation process itself from
a time average of the output stream. You cannot infer (even
"probabilistically") that p != 1/2 just because the output stream
fails the FIPS-140 Monobit Test. The Monobit Test does not test for a
known mode of failure, and therefore it is just a snake oil test.
Bob Knauer
"A fear of weapons is a sign of retarded sexual and emotional maturity."
-- Sigmund Freud
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Tue, 27 Apr 1999 11:59:25 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 27 Apr 1999 04:17:44 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>FIPS-140's small battery of tests was meant to be applied during
>operation of a level 3 or 4 device, to cause an error check if it
>started to malfunction,
An error is generated if any of the FIPS-140 tests is failed. So
exactly what failure mode is being tested by the Monobit Test?
I can see the reason behing the Long Run Test - it is testing for a
floating or shorted output. But the Monobit Test is not testing for
any known mode of failure that I can see.
Bob Knauer
"A fear of weapons is a sign of retarded sexual and emotional maturity."
-- Sigmund Freud
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: FSE-6 Report: Slide Attack
Date: 27 Apr 1999 09:16:17 -0400
In article <7g319p$gg8$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>
>> You may be thinking of the Battle of Midway, possibly the most
>> decisive chosen-plaintext attack ever perpetrated. It's featured in
>> the movie, but according to Kahn, it really did happen. The
>> cryptographers in the Pacific believed the code word was Midway
>> Island; those in Washington were convinced that Hawaii would be the
>> Japanese primary target. The Americans arranged to have a message sent
>> from Midway stating that one of the water purifiers had broken down,
>> using a code that they knew the Japanese had broken. When they
>> subsequently intercepted a message stating that location "AF" was
>> suffering a shortage of fresh water, they knew that "AF" was the
>> target and were able to concentrate their naval forces there.
>
>Cool, no offence, but heres an interesting question. How does this apply to
>normal file, or communication links of today? I really would like to know.
It's called a "known plaintext" attack; if you can get the opponent
to encrypt a message that you know something about, you can use your
knowledge of the message to help recover something further about the
encryption method.
For example, if you were using a simple LFSR-based stream cypher, and
I could persuade you to encrypt and transmit a particular phrase --
perhaps some deliberately leaked secrets -- I could recover the stream
you used and recreate the LFSR. This is *REALLY* easy to do on something
like a Web page; I fill in a web-commerce form, capture the message
sent to your cgi script, figure out how you encrypt the data, and then
mine for other people's credit card numbers.
Of course, this trick is fairly widely known and most modern cyphers
are designed to be resistant to this sort of attack. But there are
always novices or people who insist on rolling-their-own.
-kitten
------------------------------
** 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
******************************
