Cryptography-Digest Digest #74, Volume #10 Thu, 19 Aug 99 07:13:03 EDT
Contents:
Re: CRYPTO DESIGN MY VIEW (wtshaw)
Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . . ("Phlip")
Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . . ("Douglas A. Gwyn")
Re: Cracking the Scott cryptosystems? ("Douglas A. Gwyn")
Re: Decrypted International Crypto inside the US (wtshaw)
Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . . (Philemon)
Re: VEA - Video Encryption Algorithm (Jerry Coffin)
The Future of Cryptology - is happening now. (Re: Future Cryptology) (Anthony
Stephen Szopa)
Re: Europe and USA encryption export restrictions (Anthony Stephen Szopa)
Re: Q. a hash of a hash ... (David Wagner)
LFSRs in a5 (Maciej Maciejonek)
Re: Cipher-Feedback Mode (Mark Wooding)
Re: CRYPTO DESIGN MY VIEW (Mok-Kong Shen)
Re: CRYPTO DESIGN MY VIEW (Anssi Bragge)
Re: CRYPTO DESIGN MY VIEW (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Wed, 18 Aug 1999 21:48:44 -0600
In article <7pfhpg$1t9m$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
>...Which brings up another point when I post my code for dscussion how could
> lawyer types like you prove I violated any patent if my coding is such that
> no one can even decipher what I did even when it is in plain site.
>
Einstein wrote words to the effect that if you can't explain something to
a child, then you probably do not understand it well enough yourself.
I feel that algorithms are best explained in non-cryptic format; a
specific implementation of an algorithm may be written in differenct forms
of source code, yet remain equivalent in ciphertext produced as long as
the same principles and formulae are followed.
Being able to simply plug in sourcecode and make it work has no
requirement on the user that it be understood; whereas, writing from a
description mandates a complete understanding of the algorithm.
--
All's fair in love, war, and crypto. ERACE
------------------------------
From: "Phlip" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c++
Subject: Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . .
Date: 18 Aug 1999 21:22:32 PDT
Douglas A. Gwyn wrote:
> fungus wrote:
> > Why would that be then? Why couldn't it be the "Microsoft
> > documentation viewer"...?
>
> In fact the Help system used to be a special Microsoft format.
> They are changing over to HTML for fairly obvious reasons.
At the risk of dragging this thread to its final conclusion, that
system was called Rich Text Format, and it was MS's attempt at an
HTML-style markup language. According to their original specs, it
was "human readable" (using raw text, not binary, with delimiters
around marked-up blocks), "transportable" (7-bit ASCII only),
"portable" (rendering into many display spaces), and "hyper"
(supporting links, anchors, etc.).
As usual with an MS-only protocol they then proceeded to tie it up
in crud that made it un-portable, proprietary, impossible to read,
and very fragile to display. It lived longest in their help system,
and as the native format for the Rich Text Edit control. With a
simpler specification and more portability it might have took over
the niche now occupied by HTML. But keep RTF in mind whenever you
hear MS brag about "the incredible momentum of all our products."
RTF, like p-code, DDE or Pen Windows, was one of those completely
in-house products MS sunk a lot of money into that went nowhere
because they never stole anyone else's supporting technology to
start it with.
--
Phlip at politizen dot com (address munged)
======= http://users.deltanet.com/~tegan/home.html =======
-- By contrast, news:alt.fan.drew-barrymore
remains glued to _its_ topic... --
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c++
Subject: Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . .
Date: Thu, 19 Aug 1999 03:08:59 GMT
fungus wrote:
> Why would that be then? Why couldn't it be the "Microsoft
> documentation viewer"...?
In fact the Help system used to be a special Microsoft format.
They are changing over to HTML for fairly obvious reasons.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cracking the Scott cryptosystems?
Date: Wed, 18 Aug 1999 15:16:30 GMT
Doug Stell wrote:
> ... As for algorithms built around a good block cipher, there
> isn't that much call for them, which is one reason why they
> are not discussed very often.
The major application area seems to be in "secure" network
protocols (which may use a PK system to authenticate and
negotiate a session key) and block-coded commo systems,
i.e. wherever the data is already being handled as blocks.
For more stream-oriented communications, naturally stream
cipher systems are more convenient.
David Scott has some good technical ideas, but they might
be better expressed. At any rate, it is worth noting that
the following system structure
PT -> compress -> encrypt -> FEC-encode -> CT
has tremendous advantages over
PT -> encrypt -> CT
The compression removes redundancy that could help to
crack the encryption, while the error-correction adds
redundancy (which does *not* help crack the encryption)
that dramatically reduces the problems caused by data
corruption in the (noisy) communication channel.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto
Subject: Re: Decrypted International Crypto inside the US
Date: Wed, 18 Aug 1999 21:25:47 -0600
In article <[EMAIL PROTECTED]>, "Dan Kaminsky"
<[EMAIL PROTECTED]> wrote:
>
> If a european partner of an American multinational company sends *us* a
> propietary decryption application, is it illegal for us to use it?
>
Currently, probably not, although a case might be made that it is the
American company that is really in control, but employees do have free
time which is not under any employer's control, and not all employees of
American companies overseas are actually American citizens. If you leave
out the actual software application and deal with descriptions, it seems
there are no forbidden bounds from the US legal prospective.
One of the things I advocate is complete descriptions from
cryptographers. There is no doubt from experience that actually writing
an application gives insights into what a description might have left out
or made unclear. To actually know an algorithm means making it work in
software, but the knowledge you obtain through the process need not be
written in C.
You can bet your boots that if anything is considered which threatens the
export regs, you might hear some reasons of why you should not do it. The
quickest way to find out these things, so we thought, was to simply
violate some reg or 'nother, but then the ole stall techniques come into
play if the government figures that it might lose the case.
--
All's fair in love, war, and crypto. ERACE
------------------------------
From: Philemon <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c++
Subject: Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . .
Date: Thu, 19 Aug 1999 00:50:49 +0600
Phlip wrote:
> Douglas A. Gwyn wrote:
> > fungus wrote:
> > > Why would that be then? Why couldn't it be the "Microsoft
> > > documentation viewer"...?
> >
> > In fact the Help system used to be a special Microsoft format.
> > They are changing over to HTML for fairly obvious reasons.
>
> At the risk of dragging this thread to its final conclusion, that
> system was called Rich Text Format, and it was MS's attempt at an
And to that I can add that whatever the format of help, they didn't need
to force everyone to install such a *huge* piece as IE is. They could
very well ship the necessary component that can display HTML'ed help.
After all, they used to ship same help in a different format and the IDE
could display it w/o having to plop additional 300 Meg onto every
machine. It's pretty clear why it works the way it does.
Now we can close this thread <g>...
--
len
if you must email, reply to:
len bel at world net dot att dot net (no spaces, ats2@, dots2.)
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: VEA - Video Encryption Algorithm
Date: Wed, 18 Aug 1999 23:09:29 -0600
In article <7pe81n$pe1$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> This algorithm probably uses the same principle as the lock on your
> door: it was designed to keep honest people out. If you really want it,
> you will get in with this.
>From what I can see, this algorithm is less like locking the average
outside door to the house than like locking a typical bathroom door,
where opening the lock doesn't even require a real key, only a piece
of wire...
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: The Future of Cryptology - is happening now. (Re: Future Cryptology)
Date: Wed, 18 Aug 1999 23:34:02 -0700
Reply-To: [EMAIL PROTECTED]
The Future of Cryptology - is happening now. (Re: Future Cryptology)
Encryption that uses no mathematical equations.
Unlimited bit encryption.
Extreme compactness.
Very fast.
Based upon Ciphile Software's Original Absolute Privacy - Level3
encryption method, in the coming weeks the future of encryption will
have arrived:
("E" notation means that a number expressed as 5E6 = 5 x 10^6 or
5,000,000.)
For example, with only 2920 data bytes you can generate 9.2E15 random
numbers from 0 - 255 with a security level equivalent to 2000 bits;
or with only 4600 data bytes you can generate 2.3E17 random numbers
from 0 - 255 with a security level equivalent to 10,000 bits;
or with only 1,271,000 data bytes (fits on one floppy) you can
generate 1.3E36 random numbers from 0 - 255 with a security level
equivalent to 100,000 bits.
or more AND more.
These random numbers are then used to logically XOR original data files
thus encrypting them. (Encryption ON the fly.)
The first example has a ratio of random numbers output to stored bytes
of input of 3.15E12.
The second example has a ratio of random numbers output to stored bytes
of input of 5E13.
The third example has a ratio of random numbers output to stored bytes
of input of 1E30.
The future is upon us.
http://www.ciphile.com
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Europe and USA encryption export restrictions
Date: Mon, 16 Aug 1999 23:25:59 -0700
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
> Sundial Services wrote:
> >
> > Douglas A. Gwyn wrote:
> > >
> > > Nils Zonneveld wrote:
> > >
> > > Indeed, there is no reason why the 128-bit-keyed encryption modules
> > > couldn't be provided by some source not located within the US.
> > >
> > > The whole business is sickeningly stupid, made worse by politicians
> > > who don't understand what they're trying to regulate.
> >
> > Weeellll.... it may sound silly, except that those same politicians will
> > never forget that they essentially won a number of wars based on their
> > ability to intercept and decrypt enemy codes. Who knows but that some
> > of those people -exist- because their fathers survived the war because
> > some U-boat or I-boat message was decrypted at exactly the right time?
> > "War, after all, *is* hell."
> >
> > I still remember a poster I saw at the Cryptologic Museum at Fort Mead.
> > It showed a WW2 poster "Loose Lips Sink Ships" and added, "The Message
> > Is Still The Same." Good point. :-/
>
> This is the critical point. To counter "loose lips" we should create
> and distribute the strongest possible cryptographic systems possible,
> and _require_ people to use them in their daily activities.
>
> This is what the Belgians found a couple years a go, and what the French
> figured out just recently. It will probably take the Uniter States a
> while longer because they are supposed to be the best in the business.
>
> Consider the FBI's forensics lab, the ATF inventory of firearms, etc ad
> nauseum.
>
> >
> > Anyhow... the good news is that even this export-control law is not
> > considered sacrosanct within the US Government. It's being debated
> > rather hotly now. One day it will be changed. How or when, I can't
> > hazard a guess. It must be tough to reconcile the "Loose Lips" view,
> > which of course is valid, against the "E-commerce" and European views,
> > which of course are valid too.
> >
> > Damn tough problem, actually ... especially when you are setting policy
> > for an entire nation of however-million people. Very difficult to
> > debug. I wouldn't want to be, so to speak, the developer of THAT one.
Let me add: I don't think you can compare WWII events with regard to
encryption with the situation today. There is no world power in
existence
that will challenge the US in war. And as each day passes this is even
more
true because the US is simply offering every country in the world an
offer
they can't refuse: cooperate or else, on many many different fronts:
military, economic, political, social, etc. The old carrot and stick.
The real competition is over markets and the biggest market share goes
to
those who have the best products. So you don't want your products
stolen
because some criminal hacker stole your designs, etc. and sold them to
your
competitors. You can prevent this by having the strongest encryption.
This
is the real situation of concern.
How did the governments encryption restriction policy stop the Chinese
from
stealing all our nuclear secrets and sending them back to Beijing?
The encryption restriction policies are for political control here at
home.
It's that simple.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Q. a hash of a hash ...
Date: 19 Aug 1999 01:11:39 -0700
In article <[EMAIL PROTECTED]>,
Alwyn Allan <[EMAIL PROTECTED]> wrote:
>
> Nice discussion. I have a related question. Consider
>
> H2(x) = H(x) ^ x
>
> where ^ is XOR and H:S->S is a good hash. How does H2 compare to H in
> terms of collision resistance, non-invertability, and randomness?
This construction might actually make the hash _worse_.
In particular, there's no reason to expect H2 to be collision resistant
if we assume only that H is.
Consider the following counterexample:
H(x) = SHA1(x_2,..,x_n) + (x_1,0,0,..,0)
where x_j means the j-th bit of x and `+' stands for xor.
H is likely to be collision resistant, under standard assumptions,
yet H2 is not: letting y = x + (1,0,0,..,0), we see that
H2(y) = H(y) + y
= SHA1(x_2,..,x_n) + (y_1,0,0,..,0) + y
= SHA1(x_2,..,x_n) + (1+x_1,0,0,..,0) + x + (1,0,0,..,0)
= SHA1(x_2,..,x_n) + (x_1,0,0,..,0) + x
= H(x) + x
= H2(x)
so x,y form an easy collision for H2.
Similarly, this construction might ruin the invertability.
Let H(x) = 000..00 || SHA1(x), where 000..00 denotes thousands of
zero bits, and || denotes concatenation. H is one-way if SHA1 is,
yet H2 is clearly not one-way for inputs shorter than a thousand
bits long.
------------------------------
From: Maciej Maciejonek <[EMAIL PROTECTED]>
Subject: LFSRs in a5
Date: Thu, 19 Aug 1999 10:34:28 +0200
I'm looking for any information about LFSRs used in a5.
I know that this binary stream cipher consist of three short Fibonacci
LFSRs of sizes 19,22 and 23 respectively.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Cipher-Feedback Mode
Date: 19 Aug 1999 09:41:37 GMT
Reply-To: [EMAIL PROTECTED]
Scott Fluhrer <[EMAIL PROTECTED]> wrote:
> 3) You can encrypt a block of an arbitary length without any
> ciphertext expansion
And, in general, there's no latency on transmitting small gobs of data.
For CBC and ECB, you have to wait for a complete block to arrive (or do
ciphertext stealing, which for some reason seems unpopular) before you
can run the cipher on it.
-- [mdw]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Thu, 19 Aug 1999 12:03:04 +0200
SCOTT19U.ZIP_GUY wrote:
>
> >> I don't write well and I think the code speaks for itself. I mean your
> >> can test it and look at a series of dumps. But basically it some times
> >> does not write out the last bits and the decompression routine knows what
> >> the droped bits are. But some times it adds extra bits to pad the byte out
> >> when its is short. But the fact that I limit the 1's to a max of 8 in huffman
> >> tables and the all 0's to a min of 8. But I feel the C code is more important
> >
> >May I repeat:
> >Let's simplify matters by not considering the case of needing any
> >padding. Then if the last symbol output consists of 9 bits (this
> >does not necessarily contradict your above limitations) and I delete
> >the last byte, then in the 'wrong' file thus obtained the last bit
> >cannot be decoded, because it needs some more bits following it in
> >order to be a valid output symbol on the compressed file side and
> >hence properly decoded to a symbol on the uncompressed file side.
> >
> Then I will make it simple for you the 9 bit symbol in question is
> as below and starts on a byte boundary so that in this particual case
> it does not depend on previous symbol and my code for the 2 examples
> I am giving in one case the 9 become 8 in the next the nine become 16.
> symbol is 001100111 this is bits what goes out is 00110011 notice bit dropped
> symbol is 001100110 when out it is 0011001100000000 this is for this
> case only.
Sorry, I can't understand what you wrote. My argument till now is that
at the time point when your program comes to the first bit of the
9 bits (1) it will have no problem of proceeding further if the file to
be operated upon is the original file (with the remaining 8 bits) but
(2) it will not know what to do if the file to be operated upon is the
'wrong' file (without the 8 bits). Does the program pause there,
waiting infinitely for the 8 bits that it will never get, or output an
error message and stop, or simply break down? Any other possibilities???
This clearly shows your previous claim that even a 'wrong' file will
be decompressed without some abnormality (which could give clue to
the analyst) doesn't hold. (Note in the above the operations done in
(1) and (2) are exactly the same up to the time point when the first
bit of the 9 bits is encountered. Thereafter, (1) terminates correctly
as expected, while the outcome of (2) has to wait your explanation.)
M. K. Shen
------------------------------
From: Anssi Bragge <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: 19 Aug 1999 12:11:58 +0200
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
> Many people like the last writter are to dam lazy or stupid to follow code
> that compiles and works. Just because you don't handfeed them and burp
> them they get upset when they can't follow the code.
You may have all the time in the world to follow all the code
in the world. Business people don't. They like to rely on formal
specifications, or even on other people's opinions.
abe
--
Anssi Bragge
UBS AG http://www.ubs.com/
Bahnhofstrasse 45, CH-8045 Zuerich, Switzerland
Tel: +41 1 236 0485 / Fax: +41-1-236 41 41 / GSM: +41-76-388 7722
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Thu, 19 Aug 1999 12:15:49 +0200
John Savard wrote:
>
> For example, in compressing English text with word spacing, it is
> better not to include a symbol for the space character in the same
> Huffman code as the letters of the alphabet. Instead, have one Huffman
> code for the alphabet, and a separate one based on the distribution of
> the lengths of words, and alternate between the two codes.
Could you explain a bit? Suppose I have the string 'ab cde', what will
be output, if H(a) is the Huffman code of a?
M. K. Shen
------------------------------
** 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
******************************
