Cryptography-Digest Digest #560, Volume #10 Fri, 12 Nov 99 22:13:03 EST
Contents:
Re: ENCRYPTOR 4.0 crack DEMO -error ([EMAIL PROTECTED])
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Nicolas Bray)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("james d. hunter")
Re: Public Key w/o RSA? (DJohn37050)
Re: smartcard idea? (Mok-Kong Shen)
Re: Build your own one-on-one compressor (SCOTT19U.ZIP_GUY)
Re: Build your own one-on-one compressor (SCOTT19U.ZIP_GUY)
Re: Public Key w/o RSA? (David A Molnar)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ENCRYPTOR 4.0 crack DEMO -error
Date: Fri, 12 Nov 1999 21:25:52 GMT
> a.txt.enc (ciphertext) :
>
> B5 88 CA 91 9F B4 E5 74 9F 25 EB AD F0 94 64 8F
> A9 D6 C1 91 A0 B0 82 83 79 C3 D8 A1 64 5A AC 35
> 2C 9D
>
> I XOR this ciphertext with the output of the stream cipher,
> it gives :
>
> This is j test message RYRYRYRY
>
I said I XOR the ciphertext ...
it's wrong i wanted to said I SUBSTRACT the ciphertext with the output
of the stream cipher
Alexander
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Nicolas Bray <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Fri, 12 Nov 1999 13:54:56 -0800
On Thu, 11 Nov 1999, james d. hunter wrote:
> > He's some sort of engineer with a scientist complex.
>
> No reason to get insulting. If I had "scientist" complex
> I won't know anything probabilty theory. But since I'm
> an engineer, I do something about probabilty and statistics.
Well, John Baez is a well respected mathematical physicist. You called
him an idiot. I'd say you most definitely have a scientist complex.
------------------------------
From: "james d. hunter" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Fri, 12 Nov 1999 17:30:04 -0500
Reply-To: [EMAIL PROTECTED]
Coen Visser wrote:
>
> "james d. hunter" wrote:
>
> > > And you have to consider the limits of computers if you want
> > > your model to behave correctly.
>
> > What makes you that computers have limits?
>
> Does "Halting problem" ring a bell?
No. Because the "Halting problem" is a mathematical problem,
it's not a computer problem, it never was.
> > The fact that "scientists" sometimes misuse the concept
> > of limit. That's just philosophy that gets plowed under
> > as technology advances.
>
> I'd really love to see them plow under the "Year 2000 problem" with
> technological advances. A typical example of non-existing limits;
> just add some memory, that will solve it. After that one is gone they
> may
The legal profession plowed that baby about five years ago,
where've you been?
> plow under the software crisis, with its 25-50% failed software
> projects. Using just faster computers software will finally be
> delivered on time and on budget. Let's tackle long range weather
> forecasting and climate modelling. Even the tiniest difference between
> our model and the real world and the two will diverge before
> you can say: "we need infinite precision so we can calculate
> with *real* real numbers."
No you don't need infinite precision. Somebody decided
2000 years ago that it would be convenient if really, really, really,
real numbers existed, and humans have been imagining that really,
really
really, real and really, really, really imaginary numbers existed ever
since.
>
> > > I take it you are not a (theoretical) computer scientist.
>
> > Yes, that's correct. Theoretical computer scientists are
> > mostly philosophers also, since very little of what they
> > do concerns computers or science.
>
> I see. Shall we quit this thread?
Yes.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Public Key w/o RSA?
Date: 12 Nov 1999 23:03:00 GMT
ECC can be used to provide encrytion and does so in ANSI X9.63 and is in IEEE
P1363a draft. The methods there are based on ECIES formatting by Bellare and
Rogaway.
It is true that the "natural" function for ECC is key agreement and the
"natural" function for RSA is encryption, but that does not mean ECC cannot be
used to do encryption or that RSA cannot be used to do key agreement. In some
sense they both have equal public key magic.
RSA sig ver is only fast if the public exponent is low, there are some
indications that using a low exponent may not be equivalent to factoring. See
Dan Boneh's web page for a paper on this.
Don Johnson
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: smartcard idea?
Date: Fri, 12 Nov 1999 23:24:26 +0100
Craig Inglis schrieb:
>
> I wonder what it would cost to design a credit card sized smartcard
> with a numeric keypad, a little LCD display, and a processor
> powerful enough to a 2048bit modular exponentiation?
>
> Then, a user could use this (or any other card) to authenticate
> interactive transactions utilising a small shared secret, without
> any need for a PKI.
>
> The user would tap in a few details on the card...
>
> Account: 12345678
> Amount: 123.45
> PIN: *******
>
> Then place the card in a suitable docking receptacle connected
> to the phone network (or internet, or WAP, or whatever) which
> allows the card to communicate with a remote authentication
> server.
>
> It then authenticates using a mechanism like SPEKE, SRP,
> SNAKE, or whatever, and on success provides some form
> of transaction identifier... which could be verified by the
> docking station, and 'claimed' by its owner.
>
> The card to come with a large random number set at the
> factory which it could use to generate different pseudo
> random numbers for each authentication.
>
> Does anyone have any links to non-PKI based identification
> schemes??
>
> ta
>
> Craig.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Sat, 13 Nov 1999 00:09:33 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>> Actually you still can make one to one compress if you redefine a byte to
>> be 16 bits. That way all files of your english text when tokenized would
>> be a mulitply of 16bits. THe huffman compression could be based on a larger
>> tree than I am presently using. But the resulting file would still be one to
>> one. Since even if a wrong key used for then decryption the file would
>> decompress back to a file that is a multiply of 16 bits. THen that would
>> map to the english or whatever words. Note this has nothing to do with
>> weather the english file is an odd or even number of bytes.
>
>This is what I have understood till now from Don Taylor. English
>words can be of any number of bytes, but numbers are always 16 bits.
>Hence 1-1, if the dictionary is full. What I am yet missing is
>the treatment of plurals and past participles and capitalizing
>(the last using a prefix number?).
>
>M. K. Shen
One way if you really wanted to use english is to tokenize this file
to an intermediate file that might be larger. I do think Tims method
we lead to smaller files if we force all to use words only found
in a fixed dictionary.
But in the intermediate format you tokenize the file in a way
that funny strings of symbols start with a specail token call
it the "swap" token. then you could follow this by the set of
special tokens only. At end of string you add the "swap"
token only if more text that is to follow that is like the
normal thing.
What I don't want you to confuse at this point is that the
swap token is not a real token that will be compressed but
is a partail token for linking 2 tree together when we get
to the adaptive huffman compression part. Yes the intermediate
file is not 1-1 since the swap token is not a real token in the
final compressed file this file does not have to be 1-1 with anything.
When the adaptive huffman compressor runs when it reads the
intermedate token it does not write a token out for it since
it is only the path that leads to the other tree. Once there
the trees are swapped. I know this is confusing but it will
seem obvious once we start the project.
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***
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Fri, 12 Nov 1999 23:56:05 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>In sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>: Tim Tyler wrote:
>
>:> Will the 65536 words in your dictionary contain all the words I used?
>
>: [...] My humble opinion about that issue is: (1)
>: One has to be a very learned man to write ordinary texts that
>: contains plenty of words outside a dictionary of that size.
>
>I don't know. This very message contains the number 65536. *That*
>won't be in the dictionary. Nor will 'phone numbers, email addresses,
>URLs, or many proper names...
I think either method is doable. Also I am thinking that one could actaully
mix the two methods. Where adaptive huffman compression would be the
last stage. The starting can either be the set of all files. Or the set of
special Ascii files. The point being that it will not be hard to make a
1-1 compressor so that any file from the target set will compress to
the space of finite 8-bit binary files. And such that any random
binary file (odd or even number of bytes makes no difference) will
map make to target set of files such that for any file X
in the target set you compress to a Y = Comp( X) in the 8-bit
binary set. and for any file Z an 8-bit binary file will map
to file in the target set called Q = Decomp( Z) and
Comp( Decomp(Z))=Z and Decomp(Comp(X))=X
This really is not as hard as it looks.
>
>: (2) If words outside the dictionary are rare, then the effect on
>: compression of these is negligible (one uses a verbatim copying
>: method for these words).
>
>I have a problem with this point.
>
>So far the only 1-1 scheme I have seen involves mapping every symbol to a
>corresponding 16-bit word.
>
>No scheme has been presented that uses this 16-bit scheme, and allows for
>verbatim copying of text without doubling its size, while retaining the 1-1
>property.
If one is using an adaptive huffman compressor there are some funny
games one can play with the trees that let you get away with things that
at first don't seem one-to/on-one.
One neat trick is to think of two seperate trees where one tree is on
top of the other tree. That way one is using one tree a lot it becomes
very lean. But there is a path in that tree to top of other tree and then
down to it leaves. When one starts to encode a number the first path
is very long. But you then swap the whole tree so know your special
numbers or whatever are on the top tree and the other tree is on the
bottom of the new current tree. That way you can code things that
are special to the file in a more efficent way. For example if coding
words that are not in main tree diectionary the first letter would have
a longer strech of bits than normal but the rest of letters would be based
on the adaptive huffman method when in that configuration. At end
either the file is over or the trees get swapped after the next long
path through the tree to the next tokenized word.
>
>My original system allows vertabim copying of text - but this involves
>restrictions being placed on the allowed dictionary entries.
Try thing of several seperate dictionaries when compressing do A
then B the C.
When decompressing do C then B then A.
>
>:> I think the scheme you are proposing can compress English texts. I doubt it
>:> will be as good as methods allowing variable-length symbols, and schemes
> like
>:> arithmetic coding which allow symbols which are not an integral number of
> bits
>:> in length.
>
>: Of course, without some extensive experiments neither your doubt
>: nor my claim can be ascertained.
>
>Hopefully some experimentation will reveal how practical the scheme is.
When do you want to start?
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***
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Public Key w/o RSA?
Date: 12 Nov 1999 23:48:03 GMT
Brian Greskamp <[EMAIL PROTECTED]> wrote:
> How many public-key crypto algorithms are there? I'm new to this, and I
> keep hearing about RSA, but are there others?
Yes. _Many_ others. If you look at the proceedings of any CRYPTO or
Eurocrypt, you will often find
* a paper introducing a new public key scheme
or * a paper breaking a new public key scheme introduced at the
previous conference.
These schemes differ in their speed, how amenable they are to
preprocessing, their suitability for various architectures and settings,
and various other ways. Those differences are part of what motivate people
to go out and find new schemes in the first place. Another factor is that
some newer schemes solve problems like "What happens if my adversary has
adaptive access to my computer when I'm not looking", or "What if I want
to create temporary secondary keys on a regular basis for use at my
terminal?"
It may be more instructive to ask what hard problems these schemes are
based on, however. This is because many of them reduce to the same
underlying problem, so if that problem is ever shown to be "easy", then
that entire class is done for. As far as I can tell, many are based on :
* Integer factorization
Rabin, RSA,
and variants (since RSA is not equivalent to factoring,
and neither are its several mutant offspring)
* Discrete Logs and Diffie Hellman (again, DH not known to
be equivalent to discrete logs. Also, many schemes seem
to rely on the "Decision" Diffie Hellman assumption;
Dan Boneh has a great paper on this explaining what the
DDH is and why it is useful...if you can show that the
DDH is false, you also get an extra credit point in his class)
* Elliptic curves - usually discrete logs over elliptic curves
I'll defer to Don Johnson and certicom.com white
papers on this.
If you look at the IEEE P1363 standard, you'll notice that these are the
three families explicitly mentioned. They are the best studied
public key problems, if by "best studied" we mean sheer amount written
on and about them.
There are other cryptosystems which are based on what look like different
assumptions. Someone already mentioned NTRU in this thread; I've also
heard of systems which use algebraic/group theoretic constructs to get a
hard problem. The only class of these that I know even a little about are
the ones based on "lattice problems", and in that case the systems did
not turn out to be secure at practical key lengths. These systems are fun
to look at, but seem to have a nasty tendency to be broken
four or five years after publication.
> And if so, then why is RSA in
> particular so popular?
Name recognition. Ease of explanation. Ease of prototype implementation.
PGP used RSA. There's an entire company dedicated to commercializing RSA.
That kind of thing, I'd expect.
-David
------------------------------
** 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
******************************
