Cryptography-Digest Digest #331, Volume #11 Tue, 14 Mar 00 17:13:01 EST
Contents:
Re: how to introduce hs students to cryptography ("Adam Durana")
Re: MD5 collisions (Kevin Buhr)
Re: Improvement on Von Neumann compensator? (Mok-Kong Shen)
Q: Coding of music notes (Mok-Kong Shen)
Re: Improvement on Von Neumann compensator? (Scott Nelson)
Re: linux's /dev/random (Scott Nelson)
Re: I have found that RC4 stinks.. (Nemo psj)
Re: sci.crypt Cipher Contest ("Adam Durana")
Re: public key encryption (Wolfgang Gothier)
Re: Universal Language (Mike McCarty)
Re: NSA Polygraph Screening Exposed (JimD)
Re: linux's /dev/random (Kevin Buhr)
Re: how to introduce hs students to cryptography ("Rob Kings")
Re: Cellular automata based public key cryptography (Tim Tyler)
Re: Random permutations (Mok-Kong Shen)
Re: Improvement on Von Neumann compensator? (Mok-Kong Shen)
Re: linux's /dev/random (antirez)
Re: linux's /dev/random (antirez)
Re: NSA Polygraph Screening Exposed (SCOTT19U.ZIP_GUY)
Re: Cipher Contest (Boris Kazak)
Resume (Boris Kazak)
Re: Universal Language (dan)
----------------------------------------------------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: how to introduce hs students to cryptography
Date: Tue, 14 Mar 2000 14:26:08 -0500
I think your goal should be to give your students a little taste of
cryptography in its simplest form. Since most of the replies to the post
missed the "one or two lessons" part and think you have several weeks to
spend on the topic, I don't think you should go into the more complex
ciphers of today. I think you should stick to the very simple ciphers, like
Caesar and other ciphers that can easily be done with paper and pencil.
Explain basic ideas like substitution and etc. After your students have a
good understanding of these ciphers, you should let them design their own
ciphers without the aid of computers. Once they all have their ciphers
designed they could be assigned to implement their cipher in C, or whatever
programming language they know. I could see this all being fit into 2
lessons, if you gave your students some hand outs on classical ciphers
before the first lesson. Then you could spend the first lesson explaining
and answering questions on the material covered in the handout. Then they
could be assigned to design their cipher for the next class, and the next
class you could inspect their ciphers, they could compare ciphers with
classmates and etc. And their last assignment could be to write a simple
program that would demonstrate their cipher. A very important thing would
be to let them know that this is just the basics of cryptography, and if
they are interested in it you could recommend courses for them to take.
This would also be a good programming exercise.
If you are looking for a book to make your handouts from, The Handbook of
Applied Cryptography is online and you can download all the chapters for
free. I don't remember the website off the top of my head but a good search
engine should lead you to it. It addresses quite a few of the classical
ciphers which would be perfect for your class. It would be a good idea to
give them the URL to the book so they can learn more if they want to.
- Adam
<[EMAIL PROTECTED]> wrote in message news:8allmf$rfo$[EMAIL PROTECTED]...
> I want to design one or two lessons for 12th grade students majoring in
> computer science, that will introduce them to the basic concepts,
> problems, and ideas of cryptography. The activity can include anything
> from a computer lab session to group activity or perhaps even a
> cryptosystem competition of some sort.
> If you have any creative, engaging, interesting ideas please share them
> with me. Where would you start? what do you think is most important?
> what should my goals be?
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Kevin Buhr)
Subject: Re: MD5 collisions
Date: 14 Mar 2000 13:22:18 -0600
[EMAIL PROTECTED] (Larry) writes:
>
> For the sake of argument: it's 50,000 usernames. All 95 printable
> ASCII characters are legal. I want to create a file for each
> username.
So this might be a web application where you'd like to allow users to
specify their own username?
In that case, you need to check for a username collision anyway, so
why don't you just *define* a collision to be a collision of the
hashes rather than the usernames.
Suppose user A picks "i_am_an_idiot.com" as his username and user B
comes along and picks "pickles are actually cucumbers". In the
extremely unlikely case that these usernames hash to the same value,
simply tell user B a white lie: "that username is already taken, try
another one."
This should satisfy the non-techies in your group. In fact, write
code to log the usernames in cases where the MD5 hash matches but the
usernames don't, and tell them you'll give $1000 to their favorite
charity the first time it happens. (Also, if it happens, post the
result on sci.crypt---I think everyone here would love to have
examples of short, human-readable chunks of text with the same MD5
hash.)
An alternative to "untainting" the usernames by quoting special
characters, by the way, is to turn the entire username into a
base64-style encoding. (MIME Base64 won't work unmodified because it
includes the "/" character.)
Kevin <[EMAIL PROTECTED]>
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Improvement on Von Neumann compensator?
Date: Tue, 14 Mar 2000 20:43:50 +0100
Mike Rosing wrote:
>
> Assuming the time between events is random, that will work. If the time
> between events is not random, but biased somehow, it won't. The reason
> is
> you don't "ignore" anything. The Von Neumann method will stop sending
> output if the system locks up and this proposal won't. So it's
> definitly
> not better.
Given a bit sequence, one could evidently apply the device of von
Neumann multiple times. Would that be any beneficial in comparison
to single application? Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Q: Coding of music notes
Date: Tue, 14 Mar 2000 20:43:58 +0100
Could someone give links on coding of music notes for computer
processing? Are there any coding standards? Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Improvement on Von Neumann compensator?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 14 Mar 2000 19:41:52 GMT
On 14 Mar 2000 00:57:47 EST, [EMAIL PROTECTED] (Guy Macon) wrote:
>
>Recently we had a discussion about turning certain time related physical
>effects that are believed to have a random component (time between zero
>crossings of a thermal noise source, time between radioactive decay
>events) into a string of ones and zeros without (if possible) adding bias.
>
>Now if I latch the output of a free running oscillator that has lots of
>cycles between the random events, I will get somewhat random data, but
>I am counting on a perfgect 50/50 duty cycle and a perfect 50% threshhold.
>Otherwise I get a bias towards ones or towards zeros.
>
>It has been suggested (and implemented by Intel) that a Von Neumann
>compensator (0 followed by 1 = 1, 1 followed by 0 = 0. 1 followed
>by 1 or 0 followed by 0 = ignored)would remove the bias.
>
Just because it's been done, it doesn't follow that it works.
If you believe the CRI report on the Intel device,
then the results after the Von Neumann compensator are still biased.
It's great in theory, but one of the assumptions of that theory
is that the events are independent,
which is rarely the case in the real world.
>I recently heard of another method: measure the time between a pair
>ov events, then do it again. If the first time measurement is longer,
>call it a one. If the second time measurement is longer, call it a
>zero. Would this be a better scheme than the Von Neumann compensator?
>
Yes, measuring the total time between events is much better
than just using the least significant bit (a.k.a. latching
an oscillator.)
If you measure time with infinite precision, and make the same
ridiculous independence assumptions that you must for the
Von Neumann compensator to work,
then this will produce unbiased bits.
If time is measured with finite precision,
then it's necessary to reject equal length timings,
but it will then theoretically produce unbiased bits.
However, it's exceptionally unlikely that you are dealing
with actual independent events. Even radio-active decay
is dependant on the size of the source. Each event reduces
the size of the source, so there is a slight bias for the
second event taking longer. But compared with other sources
of error, this bias is insignificant.
Scott Nelson <[EMAIL PROTECTED]>
- Don't forget to vote on sci.crypt.random-numbers
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: linux's /dev/random
Reply-To: [EMAIL PROTECTED]
Date: Tue, 14 Mar 2000 20:04:48 GMT
On Mon, 13 Mar 2000 23:53:35 GMT, antirez <[EMAIL PROTECTED]> wrote:
>I played a bit with /dev/random. It seems to overstimate
>the entropy.
Many other people have the same complaint.
>For example under Linux/i386 if you press
>a key and didn't relase it, the PC write "aaaaaaaaaaaaaa" with
>a constant period, but /dev/random trust this as good entropy
>(and trust this as _a lot_ of entropy! 40 bit for every
> key pressure or release)
40 bits per key press sounds high for /dev/random.
IIRC, /dev/random estimates entropy based on the time
between events, and nothing can generate more than 32
bits. But even if we limit it to 4, it's still to high,
since only the first key press has any entropy to speak of.
>This seems really not so conservative.
>Comments?
>
Estimates are not accurate - that's why we call
them estimates. However, there are better approaches.
For example, Yarrow keeps two estimates, a high and a low.
This still might have problems, since we are likely
to estimate more than 0 per key press, even though
in the stuck keyboard case it probably should be 0.
Other improvements are possible - time based entropy
events can be rejected if they are too small a delta,
or if the delta between two deltas is too small.
/dev/random sort of handles the first delta case,
but not the second.
Scott Nelson <[EMAIL PROTECTED]>
- Don't forget to vote on sci.crypt.random-numbers
------------------------------
From: [EMAIL PROTECTED] (Nemo psj)
Subject: Re: I have found that RC4 stinks..
Date: 14 Mar 2000 20:09:21 GMT
I was suspecting that thanx i suppose ill try and make a work around then :)
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: sci.crypt Cipher Contest
Date: Tue, 14 Mar 2000 15:14:01 -0500
The contest hasn't started yet, I am still trying to hammer out the
requirements. :)
"Runu Knips" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Adam Durana schrieb:
> > [...] I thought it might be fun to have a contest such as AES. [...]
>
> Until now, nobody has published any cipher for that contest.
> So thats a nice but dead idea, isn't it ?
>
> Too, creating a new standard block cipher is basically very
> simple: add a whitening at start and end, put a 16-, 20- or
> whatever halfround Feistel in between... the only problem is,
> (a) how to create the whitening and round key data and
> (b) how should the Feistel look like ?
> This is really time consuming, I think.
>
> And how should we do the contest itself ? I'm not a
> professional, not even a mathematican, so how can I finally
> state "hey this cipher is not attackable" ?
>
> I think we should just continue like before, let anyone
> publish his or her cipher if she or he wants, and discuss
> them - if the people are so graceful to publish the
> algorithm itself, not only some random data saying "Hey
> try to break this" 8-)))
------------------------------
From: Wolfgang Gothier <[EMAIL PROTECTED]>
Subject: Re: public key encryption
Date: Tue, 14 Mar 2000 21:17:28 +0100
The best source I know about is Peter Gutmann's homepage:
http://www.cs.auckland.ac.nz/~pgut001/
You will find there a tutorial as well as a huge
list of links concerning encryption and public keys.
Wolfgang
In article <y9ky4.29$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> Hi! I am researching public key encryption for a Uni assignment.
> Can anyone recommend useful sites on the WWW on the subject.
>
> Thanks for your help in advance,
> Marianne.
>
------------------------------
From: [EMAIL PROTECTED] (Mike McCarty)
Subject: Re: Universal Language
Date: 14 Mar 2000 19:50:39 GMT
In article <8alge4$g6d$[EMAIL PROTECTED]>,
Richard Herring <[EMAIL PROTECTED]> wrote:
)In article <[EMAIL PROTECTED]>, Mok-Kong Shen ([EMAIL PROTECTED])
wrote:
[snip]
)You haven't tried learning any isolating languages, then?
)Mainly monosyllabic words, no inflections, just add extra words
)to indicate plural, past tense etc.
)
)> German is more complicated (I like though
)> the possibility of concatenating two nouns to form a compound)
)> and Russian is even more complicated in my view.
)
)Arguable. Six cases, but only two aspects and two tenses.
[snip]
Err, seven cases. Though they are not fully represented.
--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel <- They make me say that.
------------------------------
From: [EMAIL PROTECTED] (JimD)
Subject: Re: NSA Polygraph Screening Exposed
Reply-To: JimD
Date: Tue, 14 Mar 2000 20:27:22 GMT
On Mon, 13 Mar 2000 22:30:38 GMT, [EMAIL PROTECTED] (Dan Day) wrote:
>On Sun, 12 Mar 2000 06:09:21 -0700, "John E. Kuslich"
><[EMAIL PROTECTED]> wrote:
>>The polygraph only works if the subject (victim) confesses out of fear. The
>>polygraph, plain and simple, is a fear machine and it works exactly as well
>>as voodoo and for the same reasons.
>
>I've read a number of accounts of cops who took a not too bright
>suspect and then got him to confess via a laughably fake "lie detector".
>In my favorite example, they stuck some wires into a kitchen colander
>and put it on the suspect's head, and then sat him next to a copier,
>into which they had placed a piece of paper with the words "he's lying"
>written on it. Every time the guy said something they found dubious,
>they pressed the "Copy" button and showed him a fresh sheet with "results"
>from the "lie detector". Figuring he was caught, the guy confessed.
Sounds pretty much like present British police investigative methods.
--
Jim Dunnett.
dynastic at cwcom.net
Exiled in Somerset
Right at the heart of England's BSE Industry.
------------------------------
From: [EMAIL PROTECTED] (Kevin Buhr)
Subject: Re: linux's /dev/random
Date: 14 Mar 2000 14:37:16 -0600
antirez <[EMAIL PROTECTED]> writes:
>
> For example under Linux/i386 if you press
> a key and didn't relase it, the PC write "aaaaaaaaaaaaaa" with
> a constant period, but /dev/random trust this as good entropy
This is easily fixed. Autorepeat is characterized by multiple "key
down" events with identical scancodes and no intervening "key up"
event. Therefore, we simply ignore an event if it has the same
scancode and up/down state as the last event. (Holding down multiple
keys, at least on the keyboards I've seen, results in only the last
key pressed engaging in autorepeat.)
I've submitted a patch to Alan Cox, so it may make it into 2.2.15.
I'll get a patch to Linus, too, so it should eventually make its way
into 2.4.xxx.
Kevin <[EMAIL PROTECTED]>
------------------------------
From: "Rob Kings" <[EMAIL PROTECTED]>
Subject: Re: how to introduce hs students to cryptography
Date: Tue, 14 Mar 2000 20:42:43 -0000
Well for my 2 pence worth, I don't know how old 12th grade is (being
English) but starting with lectures on number theory sounds a bit heavy. I
read an excellent book last summer called "The Code Book" by Simon Singh. It
covers codes and crptography throughout history up to and including PGP, RSA
etc. It also includes a competition at the back to win £10,000 (about
$15,000) and some of these might make good examples.
I liked that fact that far from discussing crypto from the stand point of
big numbers, or maths, it looked at the social aspects. How the US was drawn
into the first world war by a decoded German Cipher, how Mary Queen of Scots
was beheaded because the Duke of Walsingham broke hers, enigma during WWII
etc. It also looks at things like the Beale cipher (the gold is still out
there in the US somewhere)
It was a very readable introduction, but not a no-brainer. Simon Singh is a
very knowledgeable writer (his other big-selling book was on the discovery
of the solution to Fermat's last theroem.)
That's where I'd start, get them to see the point of good crypto before you
do their heads in.
Cheers
Rob
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Cellular automata based public key cryptography
Reply-To: [EMAIL PROTECTED]
Date: Tue, 14 Mar 2000 20:44:10 GMT
Boris Kolar <[EMAIL PROTECTED]> wrote:
: Tim Tyler <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> To confuse matters, I'll mention that there *is* a sense in which an
:> infinite cellular automata can be *more* powerful than a Turing machine(!)
:>
:> A Turing machine can only do one thing at a time. If it is presented with
:> an infinite quantity of input data, it could be severely I/O bandwidth
:> limited.
:>
:> An infinite cellular automata can do lots of things simultaneously.
:> Given certain types of function with an infinite input, and requiring an
:> infinite output, it can calculate the results in a finite time. By
:> contrast, a TM would never even finish reading in all the inputs, let
:> alone process them.
:>
:> Consequently there are types of calculations a CA can perform, which a TM
:> cannot ;-)
: Not true. CA is of course "faster" than TM, but they are equivalent in
: power. [...]
What about the type of calculation I mentioned? A CA can perform these in
a finite time, while a Turing machine cannot ever perform them.
If one system can do rapidly something that the other cannot /ever/ do, in
what sense are they "equivalent in power"?
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
I've no idea what I'm doing out of bed.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random permutations
Date: Tue, 14 Mar 2000 22:19:51 +0100
Scott Nelson schrieb:
>
> On Mon, 13 Mar 2000 18:40:36 +0100, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>
> >Scott Nelson wrote:
> >>
> >
> >> Number of keys are almost always powers of 2.
> >> Number of permutations are always N!.
> >> Therefore, theoretically, the quality would be lower,
> >> since all permutations can not be equi-probable.
> >> But compared with other problems (such as the probability
> >> of the code being improperly written) this bias is
> >> insignificant.
> >
> >I am afraid that I don't yet quite understand your argument.
> >Could you please illustrate with a very tiny example? Thanks.
> >
>
> Consider the 3 element list {1, 2, 3}.
> There are 3! = 6 possible permutations:
> {1, 2, 3} {1, 3, 2} {2, 1, 3} {2, 3, 1} {3, 1, 2} {3, 2, 1}
>
> Now consider a RNG with a 4 bit seed.
> It generates 2^4 = 16 possible sequences.
> Each sequence will map to one of the permutations.
> But 6 doesn't divide 16 evenly, so at best,
> some of the permutations will happen 2 times, and some 3.
Thanks. But your computation above needs a tiny modification, I
suppose. The range of the RNG has 16 values. To do the sorting,
one requires a vector of 3 elements. There are 16^3 such vectors
that are equally probable and this is not divisible by 6.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Improvement on Von Neumann compensator?
Date: Tue, 14 Mar 2000 22:19:00 +0100
Scott Nelson wrote:
>
>
> However, it's exceptionally unlikely that you are dealing
> with actual independent events. Even radio-active decay
> is dependant on the size of the source. Each event reduces
> the size of the source, so there is a slight bias for the
> second event taking longer. But compared with other sources
> of error, this bias is insignificant.
I vaguely remember that someone claimed that quantum effects are
truly random. Is this only theoretical or could be practical for
obtaining bits for actual use? Thanks.
M. K. Shen
------------------------------
From: antirez <[EMAIL PROTECTED]>
Subject: Re: linux's /dev/random
Date: Tue, 14 Mar 2000 21:05:13 GMT
In article <[EMAIL PROTECTED]>,
Runu Knips <[EMAIL PROTECTED]> wrote:
> I have my linux system not at hand, but AFAIK the /dev/random
> device only counts the TRUE (physical) keypress and keyrelease,
> which is random. If it isn't that way, I would agree that this
> is a bug which should be fixed.
I really understand your dubious, but (it's very strange)
/dev/random is sensitive to key auto-repeting.
If there are problem (for example portability) a siple
way to fix this is "if oldkey == key no_entropy(); else entropy();"
Anyway try this:
/* just pool /dev/random,
* 100% public domain,
* <[EMAIL PROTECTED]>
*/
#include <stdio.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <fcntl.h>
#include <unistd.h>
int main(void)
{
int fd, n_read;
char buffer[1024];
if ((fd = open("/dev/random", O_RDONLY)) == -1) {
perror("open");
exit(1);
}
while(1) {
n_read = read(fd, buffer, 1024);
printf("%d bytes readed\n", n_read);
}
/* unreached */
return 0;
}
--
antirez
email: antirez@linuxcare dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: antirez <[EMAIL PROTECTED]>
Subject: Re: linux's /dev/random
Date: Tue, 14 Mar 2000 21:08:05 GMT
In article <[EMAIL PROTECTED]>,
Anton Stiglic <[EMAIL PROTECTED]> wrote:
>
> --------------D6D35D03DAF53BCBF71C7FD5
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> Doesn't /dev/random depend on time delays betwwen key strokes and
other
> stuff as well?
Sure, the problem is just this. Since if you press 'a' and don't
release it the delay is constant this is unsafe. The unguessable
data is just the first timestamp, if you guess it you can recover
the others delay with little work.
--
antirez
email: antirez@linuxcare dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NSA Polygraph Screening Exposed
Date: Tue, 14 Mar 2000 22:16:14 GMT
In article <[EMAIL PROTECTED]>, JimD wrote:
>On Mon, 13 Mar 2000 22:30:38 GMT, [EMAIL PROTECTED] (Dan Day) wrote:
>
>>On Sun, 12 Mar 2000 06:09:21 -0700, "John E. Kuslich"
>><[EMAIL PROTECTED]> wrote:
>>>The polygraph only works if the subject (victim) confesses out of fear. The
>>>polygraph, plain and simple, is a fear machine and it works exactly as well
>>>as voodoo and for the same reasons.
>>
>>I've read a number of accounts of cops who took a not too bright
>>suspect and then got him to confess via a laughably fake "lie detector".
>>In my favorite example, they stuck some wires into a kitchen colander
>>and put it on the suspect's head, and then sat him next to a copier,
>>into which they had placed a piece of paper with the words "he's lying"
>>written on it. Every time the guy said something they found dubious,
>>they pressed the "Copy" button and showed him a fresh sheet with "results"
>>from the "lie detector". Figuring he was caught, the guy confessed.
>
>Sounds pretty much like present British police investigative methods.
>
I got my census form from the feds today. It kind of reminds me of a
polygraph test. it says you are required under penalty of law to fill it
out but that all the information is confidentially and not other US agency
looks at it.
BULLSHIT like I've stated before my mom worked for the FBI they and
most likely the NSA will screen every thing. The US government routinely
lies to its citiizens hoping to entangle the ones stupid enough to tell the
truth.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Cipher Contest
Date: Tue, 14 Mar 2000 21:27:55 GMT
Mike Rosing wrote:
>
*****************
> I'd go the other way, 32 for beginner, 64 for intermediate
> and 128 for advanced.
> The beginner class can learn from comparisons between brute
> force and analysis,the intermediates can better understand the
> attacks and the advanced can have fun. It also makes the
> catagories clearly distinct and if someone has something
> good, they can move it up to the next catagory
> (and watch it fail there :-)
>
> Patience, persistence, truth,
> Dr. mike
***********************************
There always will be some items that don't clearly fall into
any catagory. For example, what if the cipher has scalable design,
so that its block size can be #defined in the header? Should it be
thrown out or admitted to all 3 catagories?
Same question about key scheduler - what if it accepts any length
key, from 3 to 64 bytes and produces a randomized subkey stream?
My suggestion - we should hold a vote which by majority will decide,
where does this or that design belong. For this to happen, design code
and description must be posted or linked to, people must have a chance
to look at it and express their opinion. Certainly, the preferences of
the author must also be taken into consideration, if the author wants
his design to compete in the intermediate catagory, we should not
push it into advanced. (However, we might degrade it to "beginner").
Best wishes BNK
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Resume
Date: Tue, 14 Mar 2000 21:31:15 GMT
BORIS N. KAZAK
3418 Waco Street #2,
San Diego, CA 92117
tel: 619-276-3147 (home,msg) E-mail: [EMAIL PROTECTED]
OBJECTIVE: ENGINEERING or TECHNICAL SUPPORT position
EDUCATION: M.S. in Physics from the Moscow Physico-Technical
Institute,
Moscow, Russia.
Certification as Web Server Administrator from San Diego State
University.
LEGAL STATUS: USA citizen since August 1996.
QUALIFICATIONS:
Keywords: data acquisition, embedded, RTOS, data logging, Web, HTML,
JScript,
multilingual, presentations, support, training, field, troubleshooting.
# Computer proficiency, both hardware and software, including DEC,
Intel and Motorola microprocessors, MS-DOS, WINDOWS, LINUX and
UNIX operational systems.
# Programming in FORTRAN, ASSEMBLER, FORTH, C languages, experience
with embedded real-time systems, hardware-software interfacing.
# Office Applications, word processing, EXCEL, LOTUS and QUATTRO-PRO
spreadsheets, Access, Power Point, graphics and multimedia.
# HTML-3 and HTML-4, JavaScript, Web Pages authoring and maintenance.
# Technical writing, preparation of reports and articles for
publication. Public presentation at scientific conferences,
consulting, training of the new equipment users.
LANGUAGES: Fluent in - ENGLISH, FRENCH, GERMAN.
Able to read and communicate in - SPANISH.
Native language - RUSSIAN.
ACADEMIC TRANSCRIPTS AND PUBLICATIONS LIST: Available upon request.
EMPLOYMENT HISTORY
Hughes-JVC Technology Corporation, Carlsbad, CA
Systems Support Engineer - International Desk
05/1996-12/1999 (Company went out of business)
PMD Scientific,INC. Bloomfield, CT
Development Engineer
12/1993-05/1995
Institute of Geophysics and Planetary Physics,
Scripps Institution of Oceanography, UCSD, La Jolla, CA.
Development Engineer
07/1990-03/1993
Immigrated into USA in 10/1989
Before 10/1989 - Senior staff scientist at Department of
Seismology, Institute of the Physics of the Earth, Ac.Sci.USSR,
Moscow, Russia.
REFERENCES: Will be made available at the time of interview.
------------------------------
From: dan <[EMAIL PROTECTED]>
Subject: Re: Universal Language
Date: Tue, 14 Mar 2000 16:23:04 -0500
Paul Koning wrote:
>
[... snip ...]
> There are some oddball word order patterns around: most languages
> are either SVO (subject verb object, e.g., English) or SOV (subject
> object verb, e.g., Latin). There's at least one language that's
[... more snip ...]
Actually, Latin has no word order. There might be a "standard" order
that most people write in, but the language in and of itself doesn't
care if you write SVO, SOV, OVS, OSV, VSO or VOS. Makes those ending
_really_ important...
my $.02
dan
------------------------------
** 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
******************************
