Cryptography-Digest Digest #942, Volume #10 Fri, 21 Jan 00 00:13:01 EST
Contents:
Re: NTRU Cryptosystems Inc. (Peter Pearson)
Re: Intel 810 chipset Random Number Generator (Peter Pearson)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
What's with transposition? (KitKat)
Re: RNG for OTPs during WWII (Sundial Services)
Re: Stage 8: Singh's Cipher Challenge (Paris Guffey)
Re: Wagner et Al. (Jerry Coffin)
Re: NTRU Cryptosystems Inc. (DJohn37050)
Re: ECC vs RSA - A.J.Menezes responds to Schneier (DJohn37050)
Re: ECC vs RSA - A.J.Menezes responds to Schneier (DJohn37050)
Re: MIRDEK: more fun with playing cards. (Paul Rubin)
Re: What's with transposition? ("Douglas A. Gwyn")
Re: Stage 8: Singh's Cipher Challenge ("Douglas A. Gwyn")
using SCRAMdisk for archiving files on CD ROM (write once) ("Lee")
simplistic oneway hash ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Peter Pearson <[EMAIL PROTECTED]>
Subject: Re: NTRU Cryptosystems Inc.
Date: Thu, 20 Jan 2000 17:13:08 -0800
David Wagner wrote:
>
> In article <85teng$1sb$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> > NTRU Cryptosystems Inc., delivers the world's fastest secure public key
> > cryptography system, operating more than 100 times faster than any
> > competitor!
>
> Is there any basis in fact for this `100 times faster than any
> competitor!' claim, or is this pure marketing fluff? It sure looks
> like unsubstantiated marketing froth to me.
Note that according to NTRU's performance numbers, elliptic curves
offer no speed advantage over RSA. I inquired about this at NTRU's
booth at RSA2000, and was told that since Certicom was uncooperative
about providing (or licensing, I forget which) software for use in
the comparison, the ECC implementation actually used may have been
less than the best.
(Disclaimer: I have pro-Certicom leanings.)
- Peter
------------------------------
From: Peter Pearson <[EMAIL PROTECTED]>
Subject: Re: Intel 810 chipset Random Number Generator
Date: Thu, 20 Jan 2000 17:40:25 -0800
If any followers of this thread are still interested in
information on the Intel RNG, it was reviewed by Ben Jun
and Paul Kocher, of Cryptography Research, in a paper
available at www.cryptography.com/intelRNG.pdf.
------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 21 Jan 2000 02:14:49 GMT
Reply-To: [EMAIL PROTECTED]
Paul Koning ([EMAIL PROTECTED]) wrote
]Michael Kagalenko wrote:
]>
]> Paul Koning ([EMAIL PROTECTED]) wrote
]> ]seifried wrote:
]> ]> ...it really boils down to "do you trust an
]> ]> american company to generate your random data?".
]> ]
]> ]It's not just american companies that have done sneaky
]> ]things in this area... Crypto AG was Swiss, if memory serves.
]> ]
]> ]> ...
]> ]> If you want a real hardware RNG you can verify there are simple ones
]> ]> based of radio crystals/etc that plug into a serial or parallel port
]> ]
]> ]Crystals? Not likely. Resistors, noise diodes, Zener diodes, all
]> ]those sound plausible, but crystals won't serve at all for this
]> ]application.
]>
]> Yes, they will. Crystals have thermal noise.
]
]Of course they do. But their signal to noise ratio is high.
]If you're after noise, then you want a source that has a low
](preferably negative) signal to noise ratio. Crystals fail
]that criterion by a very large margin, which is why no competent
]designer uses them for this purpose.
That's fair comment, however note, that quartz crystals are a very common
component of digital equipment, and atomic time standard is available
via internet. You can produce thermally random
data by measuring the clock drift against more precise clock (first
you'd have to find out the crystal frequency, of course). To elaborate
a bit, if t is precise time, and t' is the time measured by quartz
oscillator (reclaibrated by using t to avoid systematic drift),
then
<t-t'> = 0 (1)
(<> stands for math. expectation), however, that does not
mean that there is no drift, but that drift in both directions is equiprobable
(the recalibration I mentioned above consists in making sure that (1)
holds)
If the drift can be assumed to be brownian random walk,
the average square drift < (t-t')^2 > grows linearly with time
< (t-t')^2 > = constant * t
------------------------------
From: KitKat <[EMAIL PROTECTED]>
Subject: What's with transposition?
Date: Thu, 20 Jan 2000 21:24:02 -0500
Some time last summer I came up with my own nifty lil'
transposition scheme and I thought it was pretty cool (off course: it's
mine). I actually spent quite some time coding it. Picking up on
cryptography and the like I recently bought Schneier brick "Applied
Cryptography".
He affirms (twice) that transposition is "as a general rule"
easily broken. My first reaction, in its purest form, was something in the
vincinity of "Dang it!". My problem is that he doesn't seem to explain why
anywhere close to that statement. I'd like to have the explanation as to
why transposition (-only) cryptosystems are easily defeated (as in: "no
matter how "complex" your transposition scheme may look to you").
Actually, information as to where to find extended e-litterature on the
subject would be greatly appreciated!
KitKat
--
I'd rather be coding;
------------------------------
Date: Thu, 20 Jan 2000 19:28:22 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: RNG for OTPs during WWII
My memory is that for a while the Russians used "secretaries banging
away at typewriters" but that it turned out that these "random"
sequences were none too random.
>Paul Rubin wrote:
>
> In article <85u8bf$k4s$[EMAIL PROTECTED]>,
> Bayard Randel <[EMAIL PROTECTED]> wrote:
> >Just out of historic interest, would anyone happen to know what sort of RNGs
> >would have typically been used by either Allied or Axis forces for OTP
> >keystream generation ? dice, playing cards ?
>
> Winterbotham discussed this in "The Ultra Secret". I vaguely recall
> that dice were used, but I'm not sure.
====================================================================
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:[EMAIL PROTECTED] (PGP public key available.)
> Why =shouldn't= it be quick and easy to keep your database online?
> ChimneySweep(R): "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/cs3web.htm
------------------------------
From: [EMAIL PROTECTED] (Paris Guffey)
Subject: Re: Stage 8: Singh's Cipher Challenge
Date: Fri, 21 Jan 2000 02:30:10 GMT
I am having difficulties getting this enigma emulator to compile. If
anyone could offer hlep I would appreciate it.
I don't have a commercial compiler, so I looked on the web and found a
couple of free ones, Bloodshed Dev-C and lcc-win32.
Bloodshed Dev-C doesn't come with math.h, so that's no good.
Lcc-win32 complains that two functions (getopt and strlen) are not
prototyped and won't compile. Do I need to put another #include to
get those two functions, or are they supposed to be standard C
statements?
I have written a Perl program that helps with the general case of a
text cipher, and I would be happy to send it to anyone who wants it.
My program can compute letter frequencies (including digrams,
trigrams, etc), it can do letter substitutions, it can search for
repeated patterns in the text, and it generally helps with the
counting tasks associated with cryptanalysis.
I appreciate any help that I can get regarding this Enigma program.
Thanks.
--
Paris Guffey
On Fri, 14 Jan 2000 10:38:35 -0800, Mark VandeWettering
<[EMAIL PROTECTED]> wrote:
>So, I began by writing a simple Enigma simulator. It turned out to be
>relatively difficult to find a truly adequate description of the Enigma
>machine, and I am not quite sure I've got it down entirely. I found out
>some obvious things (rotors stepping before encoding, the oddness in
>stepping the middle rotor), but am still confused on a number of things.
>In particular, I am not sure of the interaction between the ring
>settings and the notch positions. Rather than pollute this newsgroup
>with the code for this simulator, I'll just post this pointer:
>
>http://tempest.idle.com/~markv/singh/stage8.html
>
>which has a link to the simple ANSI C program I wrote to do the
>simulation. If anyone finds any errors in the simulation, or even just
>finds it of use, I'd appreciate an email.
>Mark
>--
>Mark T. VandeWettering Telescope Information (and more)
>Email: <[EMAIL PROTECTED]> http://www.idle.com/~markv/
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Wagner et Al.
Date: Thu, 20 Jan 2000 19:54:46 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> > IIRC, no. When a user requests access to a secured object, the first
> > security check the system does is to find whether the user has the
> > ability to take ownership of the object. If they do, the user is
> > immediately granted access without any other checks being done.
>
> Do you have a reference for this? Under NT v4 sp3-5 removing both local and domain
> administrator from a file system ACL prohibits access. Note that many resources have
> default access privileges for OWNER/CREATOR and Administrator. The latter would be
> superfluous if access were automatically granted.
Inside Windows NT, Second Edition, page 313, bullet number 2 (in the
first set of bullets at the top of the page).
I haven't tested this personally, but David Solomon is _usually_
pretty dependable, so perhaps I'm misinterpreting what it says...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: NTRU Cryptosystems Inc.
Date: 21 Jan 2000 03:06:18 GMT
NTRU public keys are larger than RSA public keys for approx. same "claimed"
strengh.
Also, any performance comparisons are based on key size equivalence, which is
unclear for NTRU.
Certicom's ECC implementation speeds are faster than other toolkits have been
able to achieve.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: 21 Jan 2000 03:08:40 GMT
I asked for copies of his slides. Not sure what will happen.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: 21 Jan 2000 03:13:35 GMT
I see the group structure argument as an advantage of ECC over RSA. The ECC
group structure is entirely open and specified in the domain parms. If a new
attack is discovered, one can see very simply if the attack applies.
Contrast this with RSA. The order must be secret. One might need to use the
private key owner as an oracle to see if an attack applies. But a bad guy
could just try the attack and hope for luck.
I mentioned this in my PKS '99 paper.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: MIRDEK: more fun with playing cards.
Date: 21 Jan 2000 03:40:59 GMT
Paul Crowley <[EMAIL PROTECTED]> wrote:
re: [RC4 with a deck of cards]
>But third and most importantly, I very much doubt that
>encryption/decryption would be relatively fast as you say. I suggest
>you try it with a real deck of cards and see how fast you can go;
>compare to a computer implementation to see whether you're getting the
>right answers. You'll have to count lots of cards to index into the
>deck, swap cards without losing your place, and do Vigenere addition
>(or for decryption, subtraction, which is worse) in your head. Try
>feeding the output of the Unix "fortune" program into your
>implementation and decrypting it; I suspect you'll find it a
>demoralising experience, with lots of time burned on incorrect
>decryptions.
You'd lay out 4 rows of 13 cards face up, with a pair of coins
(not identical) to mark where the X and Y pointers are. Losing
your place swapping cards doesn't sound like a problem. Since 4 and 13
are co-prime, you'd do the arithmetic mod 4 and 13 separately, so
you'd go up 2 columns and over 5, or etc. I've gone through this
in my head and it doesn't seem too bad. I'll have to try it with
an actual deck of cards sometime when I get around to borrowing one
(I don't have one handy and don't feel like buying one just for this).
>You can see that Solitaire is strongly influenced by RC4, but the
>differences are there because Solitaire is a relatively practical hand
>cipher and RC4 turns out not to be.
I think Bruce just didn't like the idea of laying out all the cards
face up (he and I discussed this stuff by email sometime before he
designed Solitaire).
>Mirdek is IMHO considerably more practical than Solitaire. As you'll
>see from the website, I've spent quite a bit of time with a stopwatch
>and a pack of cards, making sure I've got a cipher that can be done in
>reasonable time. I've successfully decrypted thirty character
>ciphertexts with six character keyphrases in just over twenty minutes,
>using only a conversion chart (which is easily drawn from memory) and
>a pack of cards. Once you've tried doing RC4 by hand and got bored,
>try doing Mirdek, and I think you'll appreciate why I felt the need to
>design a new cipher.
One character/minute sounds pretty painful. How about RC4 (even with
255 = 15*17 elements) with pencil, paper, 2 coins, and an eraser?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: What's with transposition?
Date: Fri, 21 Jan 2000 03:55:22 GMT
KitKat wrote:
> I'd like to have the explanation as to
> why transposition (-only) cryptosystems are easily defeated
Basically, it's because it is so easy to match up adjacent pieces.
For example, the English-letter transposition cipher text
OENNNTPUERAAEVKSQSOKWEE is moderately well scrambled, but look:
Q is followed by U; perhaps nearby letters have similar connections,
brought out by writing segemnts of ciphertext down the columns:
..VN.. ?
..KT.. ?
..SP..
..QU.. <-
..SE.. !
..OR.. !
..KA..
Here, ! marks a particularly likely English digram and ? marks
a relatively unlikely one. Dropping for now the unlikely rows,
we look for another column to align next to the ones we already
have; in so doing, we note that U and Q were separated by 8
positions, which suggests perhaps every 4 positions (give or
take 1, for reasons that will be clear at the end) is a good
spot to look in for an adjacent character:
..VNR.. ?
..KTA..
..SPA..
..QUE.. !
..SEV..
..ORK..
..KAS..
The first row is definitely not English text, but the others
match up rather well. Continuing the process,
..__RO..
..KTAK..
..SPAW..
..QUEE.. !
..SEVE.. !
..ORK_..
..__ROO..
..KTAKE.. !
..SPAWN.. !
..QUEEN.. !
..SEVEN.. !
..ORK__..
The letters of the last row overlap (in the cipher text) the
letters of the first row. They make sense only as the first
row, so the final message is: ROOKTAKESPAWNQUEENSEVEN.
Note that this wasn't the actual matrix I used to encipher the
text, but it's *equivalent* to it.
In a more elaborate example, for example with a spiral route,
not so many characters would line up, but so long as the
pattern has a fair amount of localization, this sort of
matching up of adjacent likely n-grams often works.
For harder cases, it may be necessary to collect more than
one message *of the same length* and anagram them concurrently;
e.g. QU in one might correspond to NG in the other, suggesting
ING which would produce whatever precedes QU in the first, etc.
Of course, the same kind of thing can be done in binary if one
has a good idea of the plain-text "language", but it usually
requires more formal mathematical methods for finding the most
likely permutation.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Stage 8: Singh's Cipher Challenge
Date: Fri, 21 Jan 2000 03:57:53 GMT
Paris Guffey wrote:
> Lcc-win32 complains that two functions (getopt and strlen) are not
> prototyped and won't compile. Do I need to put another #include to
> get those two functions, or are they supposed to be standard C
> statements?
strlen is a standard C function, declared in <string.h>.
getopt() is non-standard, but available on essentially all UNIX
clones, or you can use a public-domain implementation from
either AT&T or yours truly, posted long ago and findable via
Web search.
------------------------------
From: "Lee" <[EMAIL PROTECTED]>
Subject: using SCRAMdisk for archiving files on CD ROM (write once)
Date: Fri, 21 Jan 2000 04:04:53 GMT
Is it possible to write a CD ROM using scramdisk? If so, then how?
Thanks
Lee Laird
------------------------------
From: [EMAIL PROTECTED]
Subject: simplistic oneway hash
Reply-To: [EMAIL PROTECTED]
Date: 20 Jan 2000 23:43:55 -0500
I have what is probably a rather unusual request. I need a very simple
to code and understand one-way hash. I don't care a great deal as to
whether it is truly secure at all, as long as it can be implemented
in no more than a couple dozen lines of code in Fortran 90.
The reason for my needing such a function is that I have been asked by
a professor at my university to help construct a project for his
Programming Languages class. He would like to introduce his students
to parallel processing by assigning them a project that required them
to code in High Performance Fortran on our school's beowulf cluster.
He asked for a suggestion of an appropriate project, and the idea of
brute-forcing the plaintext given a one-way hashing function and the
ciphertext came to mind.
The purpose of this assignment will not be understanding cryptography,
coding up a hundred lines worth of a truly secure hashing algorithm,
or solving some major problem in the universe. This will only be one
programming assignment out of several for this class in many different
programming languages. They should come out of it knowing a little
bit about a new programming language (Fortran 9x/HPF), and being a
little bit familiar with the concepts being parallel processing. As
a side note, if someone can think of another semi-interesting, simple
project that they think would be more appropriate than brute forcing
a one-way hash, I'm open to suggestions.
I have had some difficulty finding such a simple one-way hash. It
seems that cryptographers aren't very interested in making cruddy
algorithms just because they are simple (imagine that ;). I need
an algorithm that fulfills the following requirements:
1) It must be simple to code (no more than a couple dozen lines)
2) It must be collision free
3) It must be relatively one-way (such that they won't be tempted to
take a short-cut. we'll still look to make sure they really wrote
they code, which is the most important part).
The other possibilities are that I code up something like md5 myself
in a module that is passed out to the class, which makes the project a
little bit too simple for the students, or we give them a regular two-way
hash function and ask them politely to not "cheat."
Does anyone have any suggestions for an algorithm, and pseudo- or source
code?
-Dave Wilburn
--
* David Wilburn
* JMU Computer Science Student
* JMU Unix Users Group President
* OpenPGP: 4A32 BFBF B449 92D7 AD17 A2B2 B960 B69E B584 B213
------------------------------
** 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
******************************
