Cryptography-Digest Digest #382, Volume #9 Tue, 13 Apr 99 01:13:02 EDT
Contents:
Re: 3rd attempt => SNAKE ([EMAIL PROTECTED])
Re: True Randomness & The Law Of Large Numbers (R. Knauer)
UBE98 Version 2.1 Still Unbreakable... (JPeschel)
Re: True Randomness & The Law Of Large Numbers (Dave Knapp)
Re: Identification ([EMAIL PROTECTED])
Re: True Randomness & The Law Of Large Numbers (Patrick Juola)
Re: 4th attempt => SNAKE (with less oil :-) (Thomas Wu)
PKC2000 CFP - 2000 International Workshop on Practice and Theory in Public Key
Cryptography (PKC2000) (PKC2K conference)
Re: PGP Time Zone (Paul Koning)
Re: Security of LFSR on noisy channel.
Re: 3rd attempt => SNAKE (Thomas Wu)
a simple sequence that stays near zero ([EMAIL PROTECTED])
Re: Encrypting Fields in Microsoft Access Database
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 3rd attempt => SNAKE
Date: Tue, 13 Apr 1999 02:04:48 GMT
In article <[EMAIL PROTECTED]>,
Peter Gunn <[EMAIL PROTECTED]> wrote:
> Ok, thanks to everyone who commented by email or posting,
> here is my third (and hopefully final :-) attempt.
>
> I've decided to give it a name, and Ive settled on "Simple
> Network Authenticating Key Exchange" (SNAKE :-) ...
>
> x1 is a random number (<p-1)
> x2 is a random number (<p-1)
> g is an agreed 'generator'
> A is the Client.
> B is the Server.
> H() is a one way crypto hash function (SHA or similar)
> p a fixed large safe prime
> key is the resulting shared key
> U is the userid (short, probably <=8 chars)
> P is the user's password (short, probably <=8 chars)
>
> [ NOTE: ^ means to-the-power-of, % means mod ]
>
> 1) A->B: y1=(g^x1)%p, U
> 2) B->A: y2=(g^x2)%p, H((y1^x2)%p)
> 3) B: key=H(P,(y1^x2)%p)
> 4) A: key=H(P,(y2^x1)%p)
>
> What happens is...
>
> 1) The Client sends the server its public DH value y1=(2^x1)%p, plus a
> user identifier.
> 2) The Server identifies the user by looking up its list keyed by user
> identifier, and disconnects the Client if its not recognised.
> Otherwise, its sends its DH public value y2=(2^x2)%p, and
> H((y1^x2)%p) back to the Client.
> 3) Server computes key=H(password,(y1^x2)%p).
> 4) Client works out key=H(password,(y2^x1)%p), and checks that
> H((y2^x1)%p) matches the value supplied by the server, breaking
> the connection if it isnt.
>
> Now, both Client & Server have the same key since
> (y1^x2)%p == (y2^x1)%p and both Client & Server know the
> password so H(password,(y1^x2)%p) == H(password,(y2^x1)%p)
>
> Some observations...
>
> * Short usernames and passwords are OK.
>
> * It really is just a standard Diffie-Hellman with a hash,
> so no patent, copyright, or crypto export issues. (AFAIK
> you can use this for whatever you want :-)
>
> * Avoids the man in the middle.
>
> * If you dont want to advertise the username you could
> use a hash of this value instead.
>
> * It trivially simple.
>
> Is this Snake Oil? Im not qualified to judge :-)
I'd say yes. I suppose you could add "only it's lousy" to
the name :)
Whichever side uses the key first, an adversary can spoof the
other and as long as the key is used on recognizable plaintext
he'll get enough for an off-line exhaustive search attack on
P.
Suppose the next message is from B->A, and uses the key in such
a way that a guess at the correct key is testable. Our attacker,
call him Max, can find U by listening to one session. Then he
spoofs A,
1) M->B: y1=(g^x1)%p, U
B thinks the message might be from A, and returns,
2) B->M: y2=(g^x2)%p, H((y1^x2)%p)
Now B sends some message to Max, encrypted under the key. Max
can now search for P by generating candidates P' and testing,
whether the candidate key
key' = H(P',(y2^x1)%p)
successfully decrypts the message. If so, P' is P with very high
probability.
How about this: assume g is a generator for a sub-group of large
prime order (as is normally used in D-H these days).
A->B (g^H(P))^x1 mod p
B->A (g^H(P))^x2 mod p
Now both can compute key = (g^P)^(x1*x2).
--Bryan
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Wed, 07 Apr 1999 09:20:31 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 06 Apr 1999 13:44:51 -0500, Jim Felling
<[EMAIL PROTECTED]> wrote:
>Null Hypothesis: A particular RNG is not random
>Alternative hypothesis 1: This RNG is not random, but in a way that test X or
>set of tests Y cannot detect.
Then how can you know that those tests are conclusive in the null
hypothesis. IOW, the fact that they are not conclusive in Alt Hyp 1
tells me they are defective in some way, and possibly in the null
hypothesis.
I do not believe that you can have statistical tests for
non-randomness that are reliable in any case.
Here are two samples of sequences, S1 and S2, sufficiently large to
instill high significance for any standard statistical test you care
to use. One of those samples is truly random and the other was
generated algorithmically in a very non-random fashion. Which is
which?
If you apply statistical tests to those samples, you find one passes
and one fails. But how do you know which one is which without knowing
the processes which generated them?
What if they both pass or they both fail? What if they are identical
in every way, which is possible albeit highly unlikely?
Even with high significance levels, which is driven by sample size,
your tests on an infinitesimally small sample do not instill much
confidence.
>Thus we can only use these methods to discard non-random candidate RNG's and
>cannot use these methods to declare a set random.
If you can't then I conclude that the tests are not even capable of
discarding non-random candidate RNGs. They might serve as a diagnostic
aid, but that is all.
I will ask you the same questions I have put to others here. Is true
randomness a property of the distribution or is it a property of the
sample selection process? When one speaks of a "random sample", does
he mean that the sample is random by virtue of the population
distribution or by virtue of the sample selection process? What does
it mean to speak of a population distribution of random numbers per
se? Isn't the term only applicable to the way the sample was obtained,
and has nothing to do with the population distribution?
Bob Knauer
Signature files traditionally present comments from a population with an IQ over 100.
I thought it would be appropriate to present comments from the other half of the
population,
namely the one with an IQ under 100. After all, they do make up 50% of the human
condition.
Never mind that they also tend to become politicians. Here is a representative example:
"People blame me because these water mains break, but I ask you, if the water mains
didn't break, would it be my responsibility to fix them then? WOULD IT!?!"
- Marion Barry, Mayor of Washington DC
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: UBE98 Version 2.1 Still Unbreakable...
Date: 13 Apr 1999 02:56:10 GMT
...or at least as unbreakable as previous incarnations
of this snake-oil. An essay by Castork on breaking
UBE's conventional and self-extracting encrypted files
will soon appear on my web site.
It appears that the company refused to take the advice
given in this newsgroup some months ago.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Dave Knapp <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Tue, 13 Apr 1999 03:06:47 GMT
"R. Knauer" wrote:
>
> On 12 Apr 1999 12:23:00 -0500, [EMAIL PROTECTED] (Herman
> Rubin) wrote:
>
> >I would not accept the stated standards as adequate for statistical
> >purposes.
>
> I smell a consensus beginning to form here, sports fans.
>
> Are the rest of you taking notes - or are you going to accuse me again
> of having fabricated the consensus once it emerges?
We'll accuse you of fabricating it, since your position (that
statistical tests are of no use in determining whether a RNG is "good
enough") is very different from Herman's (that the specific FIPS tests
are not enough for him).
That doesn't smell anything at all like a consensus. Herman is still
firmly in the camp that believes that statistical tests are indeed
valuable in testing RNG's, while (unless you've admitted you were
completely wrong and I missed it) you are not.
-- Dave
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Identification
Date: Tue, 13 Apr 1999 02:42:46 GMT
[EMAIL PROTECTED] wrote:
>
> Bob and Alice both pick a LFSR register state (say 127 bits...), and both pick
> a large prime 'B' (512 to 1024 bits...), Then to verfify they perform this
> interactive protocol...
I gather that the LFSR state and B are shared secrets.
> 1. They both generate 64 bits using the LFSR, then another 8 bits. The
> larger number is called 'A' and the smaller 'B'. Then they calculate:
>
> ((A ^ B) mod N) mod P
>
> Where N 2^(twice the number of bits in P) (i.e 1024 or 2048 in this case).
>
> This is done such that the intermitent result (while calculating A^B is not
> truncated too prematurely).
>
> 2. Then one person (Bob in the first round, Alice in the second, etc...)
> actually communicates this number.
>
> 3. If it matches they peform another round and go back to 1.
>
> I really don't think anything of the LFSR's or P will be leaked in this
> process..
It will fall quickly. There are only 256 possible Bs.
> I want to write a school (I am in grade 11) paper on the subject, and I would
> like any feedback.
I'd suggest you should have a clear purpose for any project.
Identification given a large shared secret is already well
understood; proposing a new method that is inferior to
existing methods is not really useful. In sci.crypt many
people propose protocols and algorithms that are beyond
their understanding to attack, which seems pointless even as
a learning exercise.
In the 11'th grade, you don't have to do brain surgery to get
an A in biology. Worthwhile original reseach in Cryptology
will require quite a bit more background than you have at this
point. A simple survey paper on a few existing authentication
methods would be a fine accomplishement, and also put you above
the sci.crypt median.
--Bryan
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: 12 Apr 1999 15:52:24 -0400
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On 12 Apr 1999 12:23:00 -0500, [EMAIL PROTECTED] (Herman
>Rubin) wrote:
>
>>If one does not believe in physical probability, one does not believe
>>in physical probability.
>
>Can I quote you on that. :-)
>
>>Einstein claimed, "God does not play dice with the universe."
>
>And Big Al was wrong, too. The Universe is just one big crap shoot at
>the quantum level when it comes to measurement. There are no hidden
>variables. Locality is not observed. Systems do become entangled over
>super-luminal distances.
Must be really convenient to have All The Answers when none of the
real, Ph.D. equipped, physicists have that kind of confidence.
-kitten
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: 4th attempt => SNAKE (with less oil :-)
Date: 12 Apr 1999 20:46:04 -0700
Peter Gunn <[EMAIL PROTECTED]> writes:
>
> IMHO the main lesson here is that crypto is far more
> difficult than it looks, and if you're looking for
> something to use in a non-trivial real world application
> always try and get something thats been designed and
> scrutinized by experienced people (which basically means
> use SPEKE or SRP-3 in this case). However, that
> having been said, application development is becoming
> more and more of an integration oriented task these
> days, and if you're gonna mess with crypto, sooner or
> later you're going to have to combine hashes, key
> exchanges, symmetric & asymmetric encryption and so on,
> and I think experimenting is the only effective
> way of doing this... the hard bit is trying not to
> add extra confusion to an already obfuscate subject
> by getting carried away :-)
If only more people thought the way you did. :-) If you
check DejaNews, you'll see quite a few people who have tried
to create general-purpose authentication protocols, only to
have all their grand designs shot down. Although they end
up using one of the well-established protocols like the ones
created by B&M, Jablon, or my own, they at least gain a
healthy appreciation for how tricky this is - more so than
just reading about it, at least.
> SNAKE => Simple Non-Authenticating Key Exchange
>
> x1 is a random number (<p-1)
> x2 is a random number (<p-1)
> g is an agreed 'generator' (<p-1)
> A is the Client.
> B is the Server.
> H() is a one way crypto hash function (SHA or similar)
> p a fixed large safe prime
> key is the resulting shared key
> U is the userid (short, probably <=8 chars)
> P is the user's password (short, probably <=8 chars)
>
> [ NOTE: ^ means to-the-power-of, % means mod ]
>
> 1) A->B: y1=(g^x1)%p, U
> 2) B->A: y2=(g^x2)%p
> 3) B: key=H(P,(y1^x2)%p)
> 4) A: key=H(P,(y2^x1)%p)
I don't know if this is a part of your threat model or not, but
a person-in-the-middle gets a dictionary attack against the password
as soon as either A or B uses the resulting key to encrypt verifiable
plaintext.
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: PKC2K conference <[EMAIL PROTECTED]>
Subject: PKC2000 CFP - 2000 International Workshop on Practice and Theory in Public
Key Cryptography (PKC2000)
Date: 13 Apr 1999 04:16:42 GMT
****************************************************************
CALL FOR PAPERS
2000 International Workshop on Practice and
Theory in Public Key Cryptography (PKC2000)
18-20 January 2000, Melbourne, Australia
PKC2000, the third conference in the international workshop
series on the practice and theory in public key cryptography,
will be held in Melbourne, 18-20 January 2000. Original research
papers pertaining to all aspects of public key encryption and
digital signature, as well as associated issues in privacy and
security, are solicited. Submissions may present theory,
techniques, applications and practical experience on topics
including, but not limited to:
certification and time-stamping
cryptanalysis
comparison and assessment
discrete logarithm
electronic cash/payments
elliptic curve cryptography
encryption data formats
encryption schemes
fast implementation
identification and authentication
integer factorization
international standards
lattice reduction
message/key recovery
provable security
public key infrastructure
secure electronic commerce
signature data formats
signature schemes
signcryption schemes
smart devices
PROCEEDINGS:
Following the tradition established for PKC'98 and PKC'99 whose proceedings
have appeared as Volumes 1431 and 1560 in Springer Verlag's Lecture Notes
in Computer Science (see http://www.springer.de/comp/lncs/), the proceedings
of PKC2000 will be published by Springer Verlag in the same Lecture Notes
series. For an accepted paper to be included in the proceedings, the authors
of the paper must guarantee that at least one of the co-authors will attend
the workshop and deliver the talk. To facilitate the production of the
proceedings, the final version of an accepted paper must conform to the
guidelines set out in Springer Verlag's Authors Instructions
(http://www.springer.de/comp/lncs/authors.html).
IMPORTANT DATES:
Submission deadline: 27 August 1999 (Friday)
Acceptance notification: 8 October 1999 (Friday)
Proceedings version: 22 October 1999 (Friday)
Workshop: 18-20 January 2000 (Tuesday-Friday)
INSTRUCTIONS FOR AUTHORS:
The program committee invites original contributions in the broad area of
applications and theory of public key cryptography. Correspondences,
including submissions, will be made entirely through email. All submissions
will be blind refereed. In lodging a submission, please send two separate
email messages to
[EMAIL PROTECTED]
The first message must be in ASCII format. It should include information on
1. the title of the submission.
2. the names and affiliations of authors.
3. the email, telephone and facsimile numbers of the contact author.
The second message should contain the submission itself:
1. The submission must be prepared in a way suitable for blind
refereeing --- the first page should contain the title of the submission,
but must not contain the names or affiliations of the authors.
2. The submission should be prepared using 11-point font or larger,
with at most 15 A4/US-letter pages including bibliographies
and appendices. (Authors are strongly encouraged to use LaTeX2e
in preparing submissions, which would facilitate the production of
the final proceedings, especially the electronic version of
the proceedings.)
3. The preferred page format for submissions is PostScript (obtained using
such converters as "dvips").
4. The file may be compressed using "compress", "gzip" or "zip", and then
encoded using "uuencode".
WORKSHOP VENUE
Auditorium, Level 2, Melbourne Exhibition Centre (http://www.mecc.aust.com/)
2 Clarendon Street, Southbank, Melbourne.
LOCAL HOST:
Peninsula Campus, and Faculty of Information Technology, Monash University
PROGRAM COMMITTEE:
Hideki Imai, Co-Chair (Uni of Tokyo, Japan)
Yuliang Zheng, Co-Chair (Monash Uni, Australia)
Chin-Chen Chang (Nat Chung Cheng Uni, Taiwan)
Claude Crepeau (McGill Uni, Canada)
Ed Dawson (QUT, Australia)
Yvo Desmedt (Uni of Wisconsin-Milwaukee, USA)
Markus Jakobsson (Bell Labs, USA)
Kwangjo Kim (Info and Comm Uni, Korea)
Arjen Lenstra (Citibank, USA)
Tsutomu Matsumoto (Yokohama Nat Uni, Japan)
David Naccache (Gemplus, France)
Eiji Okamoto (JAIST, Japan)
Tatsuaki Okamoto (NTT Labs, Japan)
Josef Pieprzyk (Uni of Wollongong, Australia)
Jean-Jacques Quisquater (UCL, Belgium)
Nigel Smart (HP Labs Bristol, UK)
Vijay Varadharajan (UWS, Australia)
Serge Vaudenay (ENS, France)
Moti Yung (CertCo, USA)
WORKSHOP CONTACT ADDRESS, EMAIL AND URL:
Yuliang Zheng, Co-Chair PKC2000
Peninsula School of Computing and Information Technology
Monash University
McMahons Road, Frankston, Victoria 3199, Australia
Telephone: +61 3 9904 4287
Facsimile: +61 3 9904 4124
Email: [EMAIL PROTECTED]
URL: http://www.pscit.monash.edu.au/pkc2k/
The WWW homepage of PKC2000 contains general information related to
the workshop, including venue, weather, transport, accommodation,
registration, and so on. Please direct all inquiries to the workshop
email address.
DEMONSTRATION/EXHIBITION:
There will be ample space for the demonstration/exhibition of
products/services related to data security. For further information,
please contact the workshop Co-Chair at the address indicated above.
**********************************************************************
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: PGP Time Zone
Date: Mon, 12 Apr 1999 14:23:41 -0400
[EMAIL PROTECTED] wrote:
>
> Hi,
>
> I would like to know how could I change the time zone of PGP.
> Actually I am in GMT tine zone. How could I change it to EDT time zone.
It's in the manual.
paul
------------------------------
From: <[EMAIL PROTECTED]>
Subject: Re: Security of LFSR on noisy channel.
Date: 13 Apr 1999 00:51:20 -0500
Chris Monico <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>,
: <[EMAIL PROTECTED]> wrote:
:>If I have a long (64 bit+) LFSR, and you want to read it, but
:>can only read the bits with lots of noise, so that you can only
:>get a little better than random chance (say 501 guesses out of 1000).
:>
:>Is there a way of doing this?
:>Does anyone know of any upper, or lower bounds on the complexity of
: this?
:>
:>
: Oh, wait a second. If a Binary Symmetric Channel (BSC) is a good model
: of your channel, there is little hope. The capacity of a BSC
: approaches zero as the crossover probability approaches 1/2.
: (Measurably) Higher or lower than 1/2, you're ok, but at (or this
: close to) 1/2, the channel capacity is quite low. See the papers by
: Shannon.
I've meant to look those up for a while now.
Will do.
That is, if the library has them.
stir.ac.uk library, is somewhat patchy, I hunted up a list of 80 papers
or so, on rhodium based dyes, for el-cheapo solar cells, but only
found the two in nature. Seems the spiraling cost of journals, combined
with the shrinkage of the physics and chemistry departments have caused
a lot of things to go.
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: 3rd attempt => SNAKE
Date: 12 Apr 1999 20:32:56 -0700
[EMAIL PROTECTED] writes:
>
> I'd say yes. I suppose you could add "only it's lousy" to
> the name :)
>
> Whichever side uses the key first, an adversary can spoof the
> other and as long as the key is used on recognizable plaintext
> he'll get enough for an off-line exhaustive search attack on
> P.
>
> Suppose the next message is from B->A, and uses the key in such
> a way that a guess at the correct key is testable. Our attacker,
> call him Max, can find U by listening to one session. Then he
> spoofs A,
>
> 1) M->B: y1=(g^x1)%p, U
>
> B thinks the message might be from A, and returns,
>
> 2) B->M: y2=(g^x2)%p, H((y1^x2)%p)
>
> Now B sends some message to Max, encrypted under the key. Max
> can now search for P by generating candidates P' and testing,
> whether the candidate key
> key' = H(P',(y2^x1)%p)
> successfully decrypts the message. If so, P' is P with very high
> probability.
>
>
> How about this: assume g is a generator for a sub-group of large
> prime order (as is normally used in D-H these days).
>
> A->B (g^H(P))^x1 mod p
> B->A (g^H(P))^x2 mod p
>
> Now both can compute key = (g^P)^(x1*x2).
This is susceptible to the same attack you just described against SNAKE.
Whichever party sends the next message is vulnerable to off-line dictionary
attack. For example, if the next message is from B, and B uses the
shared key g^(P*x1*x2) to encrypt verifiable plaintext, then a malicious
client A could do the following:
A->B: g^x1 [uses x1 instead of P*x1]
B->A: g^(P*x2)
B: key = (message from A)^x2 = g^(x1*x2)
B->A: M = verifiable message encrypted with key
Client A generates password candidates P' and computes:
key' = [g^(P*x2)] ^ (x1*P'^-1)
If key' decrypts M, then P' == P with high probability. (This works
because if P' == P, key' works out to g^(x1*x2), which equals B's key.)
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: [EMAIL PROTECTED]
Subject: a simple sequence that stays near zero
Date: Tue, 13 Apr 1999 04:49:39 GMT
The sequence
a_i := (1+2Q)*a_(i-1) - (1+2Q)*a_(i-2) + a_(i-3)
with a_0 := 0, a_1 := 1, and a_2 := 2Q forms a sine wave with
period 2pi/arccos(Q) and some amplitude that I don't know how to
quantify. It looks like a delayed Fibonacci sequence, except
those all need a modulo to keep within range. This stays near
zero all on its own. I learned about it yesterday.
It's definitely old, and it isn't cryptography, but it does seem
like a useful trick to know about for anyone trying to design
pseudorandom real number generators. It's got something to
do with "generating functions", and the roots of the polynomial
(1, -(1+2Q), (1+2Q), -1)
being
1, Q + sqrt(QQ-1), and Q - sqrt(QQ-1),
which are complex numbers of amplitude 1 when QQ-1 is negative.
That and the fact that powers of complex numbers of amplitude 1
are all themselves complex numbers of amplitude 1.
- Bob Jenkins
[EMAIL PROTECTED]
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: <[EMAIL PROTECTED]>
Subject: Re: Encrypting Fields in Microsoft Access Database
Date: 13 Apr 1999 00:51:33 -0500
Derek Lyons <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] wrote:
:>If you want to do encryption, you will need to use C. VB lacks powerful
:>bit-bashing operators (AFAIK it doesn't have bit shifting) and forces
:>you to use signed operators.
: You can bit bash in BASIC.... You XOR with 1,2,4,8,16,255 etc to pull
: each bit out and make an 8 byte string, manipulating the string, then
: XOR from the string back into the byte.
: It's a b---h and a hack, and slow as dirt, but it works.
I once wrote a number handling system, for a language, with no numeric
types, only strings, and then only three or so string operators.
To read a number, it was "read leftmost digit, covert to binary with
lookup table, multiply n by 10, add binary for this digit, and loop,
till the end of the string.
Adding worked by interleaving the two binary numbers, ala
1111 + 0001 = 10 10 10 11, then use search/replace, to give 1 1 1 2, then
repeated search-replaces, to gain 1 0 0 0 0
I gave up eventally, as I found the language (mutt-lite, a mud client, in 32K
for windows) diddn't support recursion to the required depth.
------------------------------
** 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
******************************
