Cryptography-Digest Digest #76, Volume #10 Thu, 19 Aug 99 14:13:04 EDT
Contents:
Re: rsa in other fields (Bob Silverman)
Re: CRYPTO DESIGN MY VIEW (SCOTT19U.ZIP_GUY)
Re: CRYPTO DESIGN MY VIEW (SCOTT19U.ZIP_GUY)
Re: New encryption algorithm (SCOTT19U.ZIP_GUY)
Re: Definition of cracked? (Tom St Denis)
Re: NIST AES FInalists are.... (Tom St Denis)
PRNG Stream cipher questions (James Andrews)
Re: CRYPTO DESIGN MY VIEW (SCOTT19U.ZIP_GUY)
Re: Where to find (SCOTT19U.ZIP_GUY)
Re: Triple DES (168bit) -- Triple DES (112bit) (Anton Stiglic)
Re: PRNG Stream cipher questions ([EMAIL PROTECTED])
Re: Do Window Apps using CryptAPI exist? (wtshaw)
Re: I HOPE AM WRONG (Greg)
Re: Angewandte Kryptographie von Bruce Schneier (Paul Rubin)
----------------------------------------------------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: rsa in other fields
Date: Thu, 19 Aug 1999 14:36:26 GMT
In article <[EMAIL PROTECTED]>,
Anton Stiglic <[EMAIL PROTECTED]> wrote:
> Yes yes, it was a stupid remark of mine....
>
> So what you guys are saying is that the group in wich we operate,
> cannot fit in a Field. Does it fit in a Ring,? Is it not at all an abelian
> group?
>
> Anton
You seem to have some very fundamental misconceptions.
May I suggest that you take a course in basic abstract algebra?
Your use of the terms 'fit in a field' or 'fit in a ring" suggests that you
lack basic knowledge of abstract algebra.
I *never* said that the group on an elliptic curve couldn't 'fit' it
a field. The correct trm is embed, BTW. Do you know what it means to
embed a group in a field or a ring? The set of points on a elliptic curve
over a finite field forms a cyclic or bicyclic (Abelian) group. There is
a difference between a set and an operation forming a group but not a
field and being able to embed that group in a field.
You can ALWAYS embed such a group in a field. In fact, the
Tate or Weil pairing will do exactly that for an EC. The pairing will
lift the points to Q. (but the heights of the points blow up at least
exponentially which is why you can't use the pairings as a basis for
an index calculus attack)
You really don't seem to understand the difference between a group,
a ring, and a field [no, quoting the definitions to us will not show that
you understand]. Can you explain how a finite field can be represented
as a quotient ring, for example? Or how a finite ring can be formed
from the quotient of an infinite ring and an ideal in that ring? Do
you know where the notation Z/NZ comes from and why it makes
sense? Do you know what an ideal is?
If you want to discuss this subject and be taken seriously, you need to
remedy the defficiency. You claimed you were working on a Master's
degree in crypto. You need to strengthen your math background
before finishing your degree.
This is *not* a flame. Telling anyone that their knowledge in an area
is defficient can be hurtful. But you can remedy this with some courses.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Thu, 19 Aug 1999 14:59:04 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>wtshaw wrote:
>>
>> 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.
>>
>
>I want to add that all algorithms (crypto and others) are discussed
>in science based on (abstract) descriptions not on specific (concrete)
>codes in one particular programming language. One can never be
>absolutely sure whether a programmer does not err and introduce bugs
>in a large program. Reading a large program and trying to extract
>from it the algorithm is unquestionalbly a difficult task, espetially
>if the program logic is pooly or not documented. Even if a program
>is well written, the task is comparable to reading a long novel and
>then try to tell someone in one minute what it is about. It is a
>very uneconomical way of doing things and has nothing to do with
>laziness or not as Scott would like to suggest. On the other hand,
>the normally short description of an algorithm can be looked upon and
>examined in one's mind with little difficulty. One needs only to look
>into the journals of algorithms (there are quite a few currently) in
>order to see this point. One never finds there C codes or codes in any
>other practical programming languages!!
>
IT work one time I designed code to align data from various sources.
A common tho easy to solve problem. I came up with a closed form
soultion. It was easy enough that even a lazy Phd type could follow it.
While during the documentation phase this guy who was also suspose
to be an expert in fortran was tasked with looking at my code to see if
it really followed the closed form solution. He said the program was to
short and the coding to unorganized that it could not possible do
what I said it did. I told my boss the guy was full of shit. He tried to
make up cases where it failed. He could not make it fail.
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] (SCOTT19U.ZIP_GUY)
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Thu, 19 Aug 1999 15:09:56 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>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???
You have lost it. I have stated all the files are in 8 bit multiples.
the case fully explained above was that thet last the symbol of
inout file to be compressed expanded to nine bits. The file out
if the last symbol started on a byte boundary had 9 bits then in
the examples above either 2 bytes or one byte to added to the
compressed file. When that compressed file is decompressed
the orignail file comes back.
Look use a dam hex editor. Edit or change the compressed file
anywhy your heart desires. Then decompress the file and when
compressed back you get the dam hex edited file back. Is that to
hard of concept for your brain to follow.
>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.)
As I predictived you are arguing about shit you know not. The
dam program works and you to lazy to think.
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] (SCOTT19U.ZIP_GUY)
Subject: Re: New encryption algorithm
Date: Thu, 19 Aug 1999 16:07:43 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>JPeschel wrote:
>> ... The Dobbs Journal, or something similar, ...
>
>So far as I know all major magazines pay the authors,
>although not usually very much. Besides Dr. Dobbs,
>there is at least one other C/C++ journal you can find
>on newsstands that publishes complete source code along
>with the text of the article. I've seen occasional
>articles on cryptography in these magazines. So it
>does sound like a likely outlet for David's article.
That depends are they interested in publishing my method.
Would they except C code for DGJPP. Or are they a front
for something like Boreland that pays advertising space so
that something like mine would not be shown. Also is it legal
to send them a copy of the code. Whith a short explantion.
I don't really care about the money.
Also I have afeeling that they would not publish my stuff
since the NSA may infulence which methods of encryption
get published. Oh I am sure they would use some other
excuse like the AES contest. They would want always want
just a little more.
A short story I knew of a couple that owned a jewlery store
and they wabted gun permits. She has a Phd in business
and was very good at paper BS, They followed all the rules
for the city. Paid lots of money filled lots of forms had
mental tests the whole ball of wax. But they always where
short just one more item. She finally got the word her politics
not correct and she would never get one. One day she meet
an old lady who had a permit. SHe said she got one cause
she was friends with the country sheriff. Shorlty after she
took sheriff to lunch became friends. And then she got the
permit.
What I am trying to say is I doubt if I could get it published
but I would be willing to allow any one else to do it. JUst
mention my name somewhere in the article. Also if you live
in the US it might be nice to get a newer version of scott16u
or at least change the dimetnsion staements like I showed
so it would be easier to put on other machines.
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: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Definition of cracked?
Date: Thu, 19 Aug 1999 14:25:37 GMT
In article <7pgt7m$o5o$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Speaking of SEAL, do you know where I can find more information on it?
> I looked at IBM and found nothing.
>
I have the SEAL 3.0 paper, ask for it in private email I will send it.
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Thu, 19 Aug 1999 14:33:59 GMT
In article <[EMAIL PROTECTED]>,
Volker Hetzer <[EMAIL PROTECTED]> wrote:
> > Ok assuming you can get 1 billion chips working...
> You don't need to get them ALL working.
> With this kind of farm you can use timeouts and give the work to
> those that are ok.
> Using a hierarchical system of monitoring the chips, the requirements
> of the communications network are minimal.
Still on a billion chips, each running a million a second just makes 80-
bit keys weak at 17.02 years/avg per 80-bit key.....
Assuming that much power can be drivin up....oh well anyways AES is 128
to 256 bit keys anyways.
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: James Andrews <[EMAIL PROTECTED]>
Subject: PRNG Stream cipher questions
Date: Thu, 19 Aug 1999 14:43:47 +0000
Reply-To: [EMAIL PROTECTED]
Have there been any ciphers which rearrange the order of the data? I
know theoretically this is improbable in a stream cihper as you wouldnt
necessarily know the length of a stream, but in practise you usually do
know the size of the data to be encrypted and even if you don't it is
trivial to buffer the information and obtain a size. It could be quite
a slow method of encryption, but I have a feeling it'd be very effective
too. With a pseudo random change of the byte order in the file, only
the right seed value would allow a simple(?!) reversal of the process.
Obviously this would be complemented by a more standard PRNG stream
cipher on the actual data before (or after, or both?) the order
dispersion. I'll write a c++ implementation of this hopefully within
the week if I have time to see if its any good. Any thoughts, am I
barking up the wrong tree, has this been tried and failed many times
before? Also, it would obviously be more efficient, but also more
complex to implement the order dispersion on bit boundaries rather than
byte. With simple shifting and masking it probably wouldnt be too slow
or difficult, but would it have a worthwhile effect on the resultant
encryption strength? I'm not sure if there has been any research into
this area as I am admittedly not particularly well read in cryptology.
My thoughts are that surely by expanding the range of possible changes,
you increase the volume of possible paths back to the plaintext and thus
make a considerable amount more work necessary to break the enryption.
If anyone has any knowledge in this area, or spots any flaws, please
tell me before I waste time trying it. Thanks,
James
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Thu, 19 Aug 1999 15:26:31 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>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
I know you did not want this but you at least you where kind enough to
give John an example. In my adaptive huffman coding method.
the "a" since one of 256 bit unknowns. would be 8 bits in length.
the next letter the "b" could be represented by 8 to 9 bits. It
all depends on where the symbol ends up in the huffman tree.
If it ended up with eight bits it would be the next byte out. In which
case it is the same size. If it ends up being nine bits in lenght and the
last bit is a "one" only the first 8 bits are written out. If is nine bits
and the last bit is a 0 then 2 bytes written out. So to sum this up
for a 2 characters input file my code would output 2 or 3 bytes for
the compressed file. However if you use a hex editor and change
that 2 or 3 byte file to anything. And then decompress it. No matter
what file you get call it "X". When you recompress "X" you get back
the hex edited file exactly as you left it changed.
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] (SCOTT19U.ZIP_GUY)
Subject: Re: Where to find
Date: Thu, 19 Aug 1999 17:45:01 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Preditor31) wrote:
>Where can I find an encryption and a decrytion program? Also how would I go
>about learning how to break encryption?
>
>
> Thomas
While I would suggest you go to my site. But your sure to get much
asdvice as to why you should not.
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: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Triple DES (168bit) -- Triple DES (112bit)
Date: Thu, 19 Aug 1999 09:45:09 -0400
thanks for the ref, I look forward to reading it!
Anton
Stefan Lucks wrote:
>
>
> You can do a little bit better than that, i.e. reduce the complexity down
> to 2^108. See
>
> http://th.informatik.uni-mannheim.de/People/Lucks/papers/3des.ps.gz
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: PRNG Stream cipher questions
Date: Thu, 19 Aug 1999 15:45:20 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Have there been any ciphers which rearrange the order of the data? I
> know theoretically this is improbable in a stream cihper as you
wouldnt
> necessarily know the length of a stream, but in practise you usually
do
> know the size of the data to be encrypted and even if you don't it is
> trivial to buffer the information and obtain a size. It could be
quite
> a slow method of encryption, but I have a feeling it'd be very
effective
> too. With a pseudo random change of the byte order in the file, only
> the right seed value would allow a simple(?!) reversal of the process.
> Obviously this would be complemented by a more standard PRNG stream
> cipher on the actual data before (or after, or both?) the order
> dispersion. I'll write a c++ implementation of this hopefully within
> the week if I have time to see if its any good. Any thoughts, am I
> barking up the wrong tree, has this been tried and failed many times
> before? Also, it would obviously be more efficient, but also more
> complex to implement the order dispersion on bit boundaries rather
than
> byte. With simple shifting and masking it probably wouldnt be too
slow
> or difficult, but would it have a worthwhile effect on the resultant
> encryption strength? I'm not sure if there has been any research into
> this area as I am admittedly not particularly well read in cryptology.
> My thoughts are that surely by expanding the range of possible
changes,
> you increase the volume of possible paths back to the plaintext and
thus
> make a considerable amount more work necessary to break the enryption.
> If anyone has any knowledge in this area, or spots any flaws, please
> tell me before I waste time trying it. Thanks,
>
> James
>
Sounds like you're reinventing the transposition cipher. They way it
worked was you would break up the text into n character strings and line
them up in rows, something like this:
abcdef
ghijkl
mn opq
The key is used to reorder the columns. In our example, if the key was
253641, the ciphertext would look like this:
becfda
hkiljg
np qom
You would then concatenate the rows so it looks like garbled text. This
is an old manual encryption method that was used. As far as I know, no
modern encryption algorithm does this in any form, but I could be wrong.
Casey
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Do Window Apps using CryptAPI exist?
Date: Thu, 05 Aug 1999 23:36:28 -0600
In article <7od3qq$2ke$[EMAIL PROTECTED]>, Greg <[EMAIL PROTECTED]> wrote:
> Other than Microsoft Outlook Express, and probably other Microsoft
> products, I don't know of any applications that use Microsoft's
> CryptAPI archictecture. Can anyone tell me of such apps by third
> parties?
>
Considering their source, it might be hard to find even many second parties.
--
Sometimes you have to punt, and hope for the best.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: I HOPE AM WRONG
Date: Thu, 19 Aug 1999 16:44:34 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> Come on, Greg, David is a lot more civil than he used to be.
> Occasionally one of his posts results in some fairly interesting
> discussion.
> Try to ignore the "dark side" of David and encourage the light.
I suppose you are correct. I suppose the fact that he used words like
sucks, crap, and bullshit, along with character assassination and
misinformation when replying to "My Web Site Is Up" simply demonstrates
that he himself recognizes someone has done far better than he ever
hopes to in life.
I wonder where I can go to a "professional" forum where people like
David are not welcomed and are denied access. Do you know of any?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Angewandte Kryptographie von Bruce Schneier
Date: 19 Aug 1999 09:50:56 -0700
"Buchinger Reinhold" <[EMAIL PROTECTED]> writes:
> Ich w�rde dringend das Buch "Angewandte Kryptographie. Protokolle,
> Algorithmen und Sourcecode in C." von Bruce Schneier (ISBN: 3893198547)
> ben�tigen. Da es aber nicht gerade billig ist, w�rde ich mir es zuerst gerne
> ausleihen. Nur leider wei� ich nicht ob und wo das in �sterreich (Wien)
> m�glich ist.
> Falls jemand das Buch besitzt und nicht mehr ben�tigt, w�rde ich es auch
> gerne zu einem fairen Preis kaufen.
> Vielen Dank f�r Hinweise schon im Voraus !
> cu
> Reinhold Buchinger
Probiert
http://www.amazon.de/exec/obidos/ASIN/3893198547
Preis: DM 119,90 / EUR 61,30.
------------------------------
** 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
******************************
