Cryptography-Digest Digest #656, Volume #9 Fri, 4 Jun 99 10:13:05 EDT
Contents:
Re: what cipher? (Terry Ritter)
Re: what cipher? ("Douglas A. Gwyn")
Re: Viability of encrypted flash cards? (Matthias Bruestle)
German government decision to crypto policy (Mok-Kong Shen)
Re: Oriental Language Based Enryption (Patrick Juola)
Re: random numbers in ml ([EMAIL PROTECTED])
Re: Oriental Language Based Enryption (Mok-Kong Shen)
Re: random numbers in ml ([EMAIL PROTECTED])
Re: random numbers in ml ([EMAIL PROTECTED])
Re: Challenge to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
Re: Challenge to SCOTT19U.ZIP_GUY (Patrick Juola)
Re: The BRUCE SCHNEIER Tirade (SCOTT19U.ZIP_GUY)
Re: Is SSL CPU intensive? (Thierry Moreau)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: what cipher?
Date: Fri, 04 Jun 1999 08:30:05 GMT
On Fri, 04 Jun 1999 06:57:57 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>> OK, I'll bite: What do *you* think would work? That would be: in
>> general, for messages of arbitrary size, with accepted security in all
>> cases.
>
>Seems to me almost any modern military cryptosystem would work just
>fine.
As it turns out, I think he is OK with most any stream cipher.
>Unfortunately, there isn't a lot published about systems
>fielded after WWII. The Encyclopedia Brittanica article on
>cryptology describes the "n-stage Fibonacci" system, which was one
>of the earliest successful "purely electronic" cryptosystems, and
>offers further comment on extensions of the idea. There are
>exceedingly few people outside the official cryptologic services who
>could crack such a system, and even then, favorable circumstances
>are required for the attack to succeed.
OK, I *have* that article (on CD). Although the "n-stage Fibonacci"
terminology is unfamiliar to me (although I do know that Marsaglia
calls the additive and similar RNG's "Fibonacci"), the text
description (and especially figure 8) shows a linear feedback shift
register (LFSR). That is an old friend which I know very well from
electronics, random number generators, and polynomial fields mod 2,
and have successfully "attacked" such systems. But the article
describes using the LFSR differently than the open systems I know. It
implies that we drop plaintext into the SR, step it for a while, then
use the result as ciphertext. I would call that a form of block
cipher. The article implies that the keying is the step count, and
fortunately with a LFSR we do have fast ways to step. It also implies
that we have a keying register, which we step enough to diffuse the
key and each value we take, then use those values to indicate how much
we step the cipher register. Now, I've never tried to recover LFSR
step distance knowing initial and resulting values, and with multiple
registers that sounds tough. That said, I have experienced LFSR's
completely exposing themselves to almost unbelievable degrees. So I
can believe that such things could be used, and may be strong, yet
know enough to be wary, and not enough to actually do it myself. And
I am unaware of anything in the literature which would be much help.
I note that we can of course re-key our well-known block ciphers on a
block-by-block basis as controlled by another cipher or even a hash of
some sort of counter. That has been proposed here before, and
generally ignored, but as a matter of fact it may be one of the things
we should take more seriously.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: what cipher?
Date: Fri, 04 Jun 1999 10:27:21 GMT
"Douglas A. Gwyn" wrote:
> ... Encyclopedia Brittanica ...
I didn't think that looked right when I wrote it.
It's "Britannica", of course.
Hm, it's one of those words that doesn't look right
no matter *how* you spell it...
------------------------------
Crossposted-To: alt.security,talk.politics.crypto
From: [EMAIL PROTECTED] (Matthias Bruestle)
Subject: Re: Viability of encrypted flash cards?
Date: Fri, 4 Jun 1999 09:17:08 GMT
Mahlzeit
Cor! ([EMAIL PROTECTED]) wrote:
> However, I always keep an open mind, and I'm sure if somebody could
> suggest good, practical reasons why non-criminals would use this, then
> I'm sure my mind would change.
Journalists, Human-rights groups
Mahlzeit
endergone Zwiebeltuete
--
PGP: SIG:C379A331 ENC:F47FA83D I LOVE MY PDP-11/34A, M70 and MicroVAXII!
--
Hey Martina! Du bist die Traumfrau meines Lebens. Ich glaube, auf Dich
habe ich schon immer gewartet. Ich muss dich haben: jetzt, hier und
sofort!!!
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: German government decision to crypto policy
Date: Fri, 04 Jun 1999 14:21:19 +0200
The German government has on 2nd June made essential decisions to its
crypto policy, viz. in direction of liberalizing instead of restricting
usage of crypto. The original document is at
http://www.bmwi.de/presse/1999/0602prm1.html
An English translation is available at John Young's site
http://jya.com/de-crypto-all.htm
M. K. Shen
====================================
http://www.stud.uni-muenchen.de/~mok-kong.shen/ (Updated: 12 Apr 99)
(Origin site of WEAK2-EX, WEAK3-EX and WEAK4-EX, three Wassenaar-conform
algorithms based on the new paradigm Security through Inefficiency.)
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Oriental Language Based Enryption
Date: 4 Jun 1999 09:09:35 -0400
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>
>> It would be fun to play a game like kids use to play but with lagnuges.
>
>It depends on what material is going to be translated. Normal
>messages needing the protection of encryption are mostly 'technical'
>in nature and not literary (involving nuances and fine points of
>style). For such stuffs even laymen (not trained translators) would
>be able to perform good and meaning-preserving translations to
>serve the purpose being discussed. Quite a time ago I learned that
>the European Union has funded a project on automatic translators
>with the goal, I presume, to master the huge task of translating
>official documents for its member countries, e.g. texts of industrial
>standards etc.
If you think that the texts of official EU industrial standards
don't require careful analysis and translation of nuances, you've
obviously never been involved in a lawsuit. Someone, somewhere, will
follow the Spanish "standard" and get sued in a Danish court by a
Dutch company that bought what they consider "substandard" parts,
and the nuances of the various standards will be examined extremely
closely.
But you're correct that the EU is a major player (and funder) in the
MT game; are you familiar with the VerbMobil project? But most of
the research has been focusing not just on technical documents but
on business needs; for example, the official VerbMobil project is
simply translation of meeting schedules....
-kitten
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.sys.cbm
Subject: Re: random numbers in ml
Date: 4 Jun 1999 07:27:08 GMT
Reply-To: [EMAIL PROTECTED] (Matthew Montchalin)
| Still intrigued with the numbers generated by the aforementioned
| algorithm, I tried out the seed $ff $ff $ff $ff $ff (five bytes, each
| 255), and like all the other seeds examined, zeroed out the two bytes
| labeled as 'temp' and got the following bytes:
|
| 00-07 : ff fe fe fd fd fc f8 f6
| 08-0f : 6c 28 30 1c 4b e9 0a 11
| 10-17 : be f7 49 73 4e 02 a0 3a
| 18-1f : 87 df bb 07 c6 de 83 a8
| 20-27 : e8 7f b1 1a 3c 52 c6 5c
| 28-2f : 80 6f 7a ff a7 5a a9 fb
| 30-37 : 0f ce 8b 47 da d5 6b 4d
| 38-3f : 2b e7 06 21 79 25 22 2f
|
| BTW, if one should test the first 114,688 numbers generated (that is,
| after $1c000 iterations), the following weights are distributed throughout
| the following nybbles (again, using the $ff $ff $ff $ff $ff seeding):
|
| Nybble How Many Times Generated
| 0 $3851
| 1 $37c4
| 2 $37f9
| 3 $3793
| 4 $3867
| 5 $3841
| 6 $37fd
| 7 $3805
| 8 $37ac
| 9 $381d
| A $3774
| B $37c9
| C $38f3
| D $380f
| E $377c
| F $3831
|
| And I doubt that it would change greatly if I were to wait through four
| times as many iterations, but rather, that the distribution would come
| very close to $ffff per nybble.
Actually, if one allows the counter to go through sixteen times as many
iterations (i.e., until it hits $1c0000), the distribution does
seem to change a bit:
Nybble How Many Times Generated
0 $37b82
1 $38790
2 $37b24
3 $37c97
4 $38045
5 $38187
6 $37e2f
7 $37625
8 $3832e
9 $38608
A $384cd
B $375ca
C $38811
D $38380
E $379e9
F $385cc
The reason the distribution departs from that observed during the first
$1c000 hits, is that the seed has stabilized into a self-repetitious
pattern different from the first pattern, and the next fifteen $1c000
iterations must serve to balance it out. Or so I would guess.
(Naturally many of you will prefer to point out where I went wrong...)
--
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Oriental Language Based Enryption
Date: Fri, 04 Jun 1999 14:46:11 +0200
SCOTT19U.ZIP_GUY wrote:
>
> It would be fun to play a game like kids use to play but with lagnuges.
It depends on what material is going to be translated. Normal
messages needing the protection of encryption are mostly 'technical'
in nature and not literary (involving nuances and fine points of
style). For such stuffs even laymen (not trained translators) would
be able to perform good and meaning-preserving translations to
serve the purpose being discussed. Quite a time ago I learned that
the European Union has funded a project on automatic translators
with the goal, I presume, to master the huge task of translating
official documents for its member countries, e.g. texts of industrial
standards etc.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.sys.cbm
Subject: Re: random numbers in ml
Date: 4 Jun 1999 02:06:03 GMT
Reply-To: [EMAIL PROTECTED] (Matthew Montchalin)
Matthew Montchalin wrote:
| I plugged in the following seed: $00 $00 $00 $00 $01 (sort of a worst
| case scenario for a seed) and zeroed out the two bytes at temp, and then
| got the following results for the first 64 bytes generated:
|
| 00-07 : 01, 01, 01, 05, 09, 0d, 11, 23
| 08-0f : 46, 6c, ae, b4, 7c, 5c, bb, 77
| 10-17 : 84, c4, 9d, 27, b7, 9e, 37, 02
| 18-1f : 5e, d5, d2, 9b, 84, 39, ad, 31
| 20-27 : 9c, 02, 6e, 1e, 1a, 49, fb, bd
| 28-2f : d5, 7e, 71, 51, 6b, 6e, fe, 3d
| 30-37 : 23, a3, cd, 92, 2f, 93, 09, 77
| 38-3f : 38, 6b, f5, f3, 47, 4e, 92, 3b
Still intrigued with the numbers generated by the aforementioned
algorithm, I tried out the seed $ff $ff $ff $ff $ff (five bytes, each
255), and like all the other seeds examined, zeroed out the two bytes
labeled as 'temp' and got the following bytes:
00-07 : ff fe fe fd fd fc f8 f6
08-0f : 6c 28 30 1c 4b e9 0a 11
10-17 : be f7 49 73 4e 02 a0 3a
18-1f : 87 df bb 07 c6 de 83 a8
20-27 : e8 7f b1 1a 3c 52 c6 5c
28-2f : 80 6f 7a ff a7 5a a9 fb
30-37 : 0f ce 8b 47 da d5 6b 4d
38-3f : 2b e7 06 21 79 25 22 2f
BTW, if one should test the first 114,688 numbers generated (that is,
after $1c000 iterations), the following weights are distributed throughout
the following nybbles (again, using the $ff $ff $ff $ff $ff seeding):
Nybble How Many Times Generated
0 $3851
1 $37c4
2 $37f9
3 $3793
4 $3867
5 $3841
6 $37fd
7 $3805
8 $37ac
9 $381d
A $3774
B $37c9
C $38f3
D $380f
E $377c
F $3831
And I doubt that it would change greatly if I were to wait through four
times as many iterations, but rather, that the distribution would come
very close to $ffff per nybble.
--
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: random numbers in ml
Date: 4 Jun 1999 07:31:56 GMT
Reply-To: [EMAIL PROTECTED] (Matthew Montchalin)
Matthew Montchalin muttered:
>> I think 'C' tries too much to insulate the programmer from the cold
>> reality of 6502 assembly language,
Jerry Coffin explained:
>For most people, 6502 assembly language is NOT "cold reality" -- it's
>a distant memory, or else something altogether foreign to their
>experience.
Okay. I stand corrected.
>When you're trying to express an algorithm, C has the distinct
>advantage of being understandable to a wide variety of programmers.
Okay, that may be true.
>For writing the fastest possible programs, assembly language is a fine
>choice. For conveying algorithms, it's not nearly as universal.
Hmm. Okay...
--
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Fri, 04 Jun 1999 14:13:40 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Tim Redburn wrote:
>> Do you understand what is being asked yet ?
>
>My suggestion is that he read *and understand* the classic book,
>"The Elements of Programming Style" by Kernighan & Plauger, or the
>recently published "The Practice of Programming" by Kernighan & Pike.
I have been a programmer for over 30 years. I could give a dam what
they say about style. Style is just a tem used so that programmers
who can' program waste a lot of paper and then management is under
the illusion that they porduces something. Style is used to force creative
programs in a mold that they don't need.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: 4 Jun 1999 09:40:24 -0400
In article <7j8jdv$2hb0$[EMAIL PROTECTED]>,
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>>Tim Redburn wrote:
>>> Do you understand what is being asked yet ?
>>
>>My suggestion is that he read *and understand* the classic book,
>>"The Elements of Programming Style" by Kernighan & Plauger, or the
>>recently published "The Practice of Programming" by Kernighan & Pike.
>
> I have been a programmer for over 30 years. I could give a dam what
>they say about style. Style is just a tem used so that programmers
>who can' program waste a lot of paper...
I see. Glad to hear that Brian Kernighan and Rob Pike "can'[t] program."
I guess that explains why you've never heard of any programs they've
written. Helps that they're working for a company no one's heard of,
either.
It also explains why "SCOTT19OS" is a household word with a section in
every Barnes and Noble in the States. You're just a *better programmer*
than Drs. Kernighan and Pike.
-kitten
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The BRUCE SCHNEIER Tirade
Date: Fri, 04 Jun 1999 14:06:24 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim
Redburn) wrote:
>You keep reversing your arguments. If I say that the effective key
>size is unknown then you say, use such a big key that it doesn't
>matter. Then when I point out the problems of a large key, you say
>that if you're happy with 128bit security, then use 128bit keys.
>
>However, you admit in your post that your can only guess at the
>size of key you need for 128bits. Surely you must see why people
>have doubts about the security of your algorithm ?
I ok I guess I have to spoon feed you to show you how you can get
exactly 128 bits of security since the concept is above you,
To get exactlt 128 buts of secruity you would need to be able to type
in 16 charaters each of which has 256 combinations. This is not feasible
since cetain patterns not allowed or could abort the program. So here
is a way you could do it. Let the pass phrase be made of octal characters
"0,1,2,3,4,5,6,7" then take your 128 bits of key you
need and rewrite is in hex this makes it 128/3 which equals 43 octal
characters. Type in these for the password. SInce you get a unique
S-table for each octal combination you have your 128bit key that could
be used but becareful all 7's is to big and make sure you use exactly
43 octal characters to represent the binary key of your choice.
Note the part that may be confusing you. In order to get some speed
I make the table not from a binarry number but from a list of remainders
for speed. You have pointed out and that since I do a mod on each random
number with a decreasing base that certain remainders are more favored
than others. on other words for those that have no looked at the entropy
if I have a random number in range 0 to 7 and need a number 0 to 2 I
could divide by 3 and get a remainder of 0 to 2 but then there is more
chance of the remainders 0 to 1 occuring then the remainder 2 since
0 resultes from 0,3,6 while 1 restults from 1,4,7 while 2 results
form 2,5 so it is less likely.
However when the tables is built from the short key you no longer have
random input and since the string is repeated over and over you keep
dividing the same numbers by a decreasing base as you build the table.
since each number is repreated many times but a dieffernt divsor is used
I don't think there is a problem of 2 octal sequences as described
above producing the same sequences. IF there is then I am wrong and
maybe you can show me the error.
>>
>> The doEnce function is the main encryption routine it is very short
>>on input you have a pointer to location in memory while the virtual
>
>That bit is obvious. But what conceptually is at that memory location?
>A few minutes examination reveals that it is most likely the plain
>text. But it shouldn't be necessary for someone reading your
>code to have to work that out. It wastes time, time which
>most people don't have to spare.
It is either the Plain text by itself or the plain text with the padding
if one used the mod with padding
>
>
>>file is laid out and the other input is the number of bytes in the file
>>on output the virtual file has overlaid the other file in memory and it
>>is the output file and the lenght in is exactly the same as lenght out.
>>The rest should be easy to follow in the routine it is very short.
>>
>
>No, the rest is not easy to follow.
>
><snip>
>
>>>to one method, there seem to be places in your code where you use
>>>one method to access the tables one minute, then another the next.
>>>
>>
>> like where in the code do you mean?
>>
>
>An extract from the doEnce function....
>-----------------------------------------------------
> if( i19 != i19s){
> pf19->a00 = 0x7ffff;
> iz = geto19(ppo19, i19-1);
> pf19->a00 = 0;
> izz = geto19(ppo19, i19-1);
> i19s += 0 == ( iz ^ izz);
> }
>-----------------------------------------------------
>
>You are using the structure "pf19->a00" to set the
>value, then the macro "geto19(ppo19, i19-1)" to
>get the value.
I explained exactly what this piece of code was doing.
the i19-1 entry of the ppo19 pointer is not necessiarly the
same as the pf19<a00 entry. They are 2 different structures
the area of memory that access is a funntion of field size
bit rotation and file length.
>
>And back to the other point about variable names......
>What on earth do "iz" and "izz" represent ?
There are internal varibles only used in that spot. I have to
put the 19 field bit variables on 32 variables since C does not
seem to recognize a 19bit variable unsigned integer type.
Maybe only some specail hardware this would not be needed.
>
>And more to the point, what on earth is going
>on here and how does it help the security ?
This was shown in the previous post
>> I think Paul Onions could write it up if he felt like it.
>
>It is possible to find problems with your algorithm without
>understanding it all. Paul might have made the effort
>to decipher it all. If he did, it would be great if he would
>share it with everyone. But you changed it since he analysed
>it, so he would have to start over again. I doubt he
>has the time or the inclination. (quite understanably).
>
But the coding style is the same and I am sure
he could follow it.
>>I don't Bruce could since this is to different than the
>>weak stuff he plays
>
><opinion without basis mode on>
>Yes, scott19u.zip is weaker......
><opinion without basis mode off>
>
>
><snip>
>
>- Tim.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Thierry Moreau <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Is SSL CPU intensive?
Date: Fri, 04 Jun 1999 09:05:30 -0400
Tim wrote:
>
> How CPU intensive is SSL? I would be sending (encrypting with SSL) ~100
> bytes of data per second. I have a 68030 running at 20 MHz (embedded
> server application) and can allow 20%-30% of the CPU for this task.
> Does anybody know of, or where I can get the number of required clock
> cycles per byte for SSL?
>
> --Tim
Establishing a session requires public key computations on the server,
at a bare minimum one full Diffie-Hellman exponentiation each time a new
client comes to the server. Your actual requirements might exceed this.
Fisrt approximation, a 20MHz 68030 may take in the order of 1 to 20
seconds to set up a brand new SSL connection.
I just looked at this issue yesterday, and if you want the details of my
findings and possible work-arounds, you may contact me off-line.
- Thierry Moreau
CONNOTECH Experts-conseils Inc.
Tel.: +1-514-385-5691
Fax: +1-514-385-5900
------------------------------
** 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
******************************
