Cryptography-Digest Digest #685, Volume #12 Fri, 15 Sep 00 10:13:01 EDT
Contents:
Re: IDEA - PGP (Runu Knips)
Re: "Secrets and Lies" at 50% off (Tim Tyler)
Extremely slow in DES software implementation ("P.C. Teo")
Music Industry Offers US$10K for cracking their encryption system
([EMAIL PROTECTED])
proposal for pen-and-paper RC4 system (Patrick Schultz)
Re: Extremely slow in DES software implementation (Anders Thulin)
Proposed Mixmaster Protocol (Rudolph Weiss)
Re: Intel's 1.13 MHZ chip (Guy Macon)
Re: CRC's as MAC's (Zulfikar Ramzan)
Re: Kryptcon ("Sam Simpson")
Re: Lossless compression defeats watermarks (Tim Tyler)
Re: RSA Questions (Future Beacon)
Re: Intel's 1.13 MHZ chip (Mok-Kong Shen)
Re: 20 suggestions for cryptographic algorithm designers (John Savard)
Re: Lossless compression defeats watermarks (John Savard)
Re: 20 suggestions for cryptographic algorithm designers (John Savard)
Re: 20 suggestions for cryptographic algorithm designers (John Savard)
Re: 20 suggestions for cryptographic algorithm designers (John Savard)
Re: RSA Questions (DJohn37050)
Re: Fresh Meat: New Crypto Algorithms Announced (David A Molnar)
Re: 20 suggestions for cryptographic algorithm designers (Future Beacon)
----------------------------------------------------------------------------
Date: Fri, 15 Sep 2000 10:25:40 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: IDEA - PGP
John Myre wrote:
> Johnny Bravo wrote:
> > On 10 Sep 2000 17:55:21 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote:
> > >RC4 is not the right thing to use here as it demands a separate password
> > >for each file encrypted, which is not of great use for you I suspect.
> > You can safely reuse the password if you use a seperate IV for each
> > message (not much of a problem).
> That's technically not true. That is, RC4 (well, alleged RC4) does
> not define the use of an IV at all.
I've yet to see an algorithm which defines the use of an IV explicitly.
Of course there always has to be one if the implementation isn't crap,
but for stream ciphers it means they have to allow long keys so an
reasonably long IV can be appended to the key.
In the case of RC4/Arcfour, it has been suggested that one should
use the hash of the key with the IV as input to the cipher, and
drop the first few douzens of bytes of output of the cipher.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: "Secrets and Lies" at 50% off
Reply-To: [EMAIL PROTECTED]
Date: Fri, 15 Sep 2000 08:55:10 GMT
In sci.crypt Ornie Makly <[EMAIL PROTECTED]> wrote:
: [...] Watch out for word-wrap:
:
:http://x52.deja.com/threadmsg_ct.xp?AN=655426930.1&mhitnum=0&CONTEXT=968982183.296747036
For future reference - and if anyone cares - you can generally truncate
Deja URLs after the "AN=" digits without any great loss - i.e. the
following URL leads to the same spot:
http://x52.deja.com/threadmsg_ct.xp?AN=655426930.1
You can miss off the ".1" as well if you like:
http://x52.deja.com/threadmsg_ct.xp?AN=655426930
I do this when posting URLs - but it's also useful to know if you're
reduced to copying and pasting them from (e.g.) pine or tin.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Destroy Microsoft.
------------------------------
From: "P.C. Teo" <[EMAIL PROTECTED]>
Subject: Extremely slow in DES software implementation
Date: Fri, 15 Sep 2000 17:40:40 +0800
I am implementing a standard DES software (Downloaded from Internet) in my
project. I found that it takes around 25+ seconds to encrypt a 1MB file but
PGP takes less than 4 seconds.
What is the secret behind PGP. In my opinion, if we follow the DES exactly
it will really take computer much time to go through all the step in the
algorithm. Unless PGP doesn't follow the DES standard.
Remark: I did make sure PGP encrypt using 3DES with selecting 3DES option
only.
------------------------------
From: [EMAIL PROTECTED]
Subject: Music Industry Offers US$10K for cracking their encryption system
Date: Fri, 15 Sep 2000 10:00:36 GMT
http://www.msnbc.com/news/460310.asp?cp1=1
------------------------------
From: Patrick Schultz <[EMAIL PROTECTED]>
Subject: proposal for pen-and-paper RC4 system
Date: Fri, 15 Sep 2000 03:06:11 -0700
I have seen many proposals for various ways to execute RC4 by hand, and
this is yet another one. But this one isn't a scaled down
implementation of RC4, it uses the full 256 byte state array. This is
also faster to perform by hand than any others I have seen so far,
especially for people who have trouble doing arithmetic in their heads.
First, make a 16 x 16 matrix (either drawn on paper, or built). Label
the rows and columns like this:
0 1 2 3 4 5 6 7 8 -7 -6 -5 -4 -3 -2 -1
I used the negative numbers because counting backwards one is much
easier than counting forward 15.
To initialize the state array, simply write each space's coordinates
(row, column) in the space. This entire system is based on four bit
words, rather than 8 bits. It shouldn't affect security in any way,
because it still has the full 256 byte array; the only difference is
that it breaks up all byte values into 4 bit chunks. I did this for two
reasons: one, because it is easier to work with in your head; and two,
because it just fits so perfectly with the 16 x 16 matrix.
So now you should have something like this:
0 1 2 ... -1
0 0,0 0,1 0,2 0,-1
1 1,0 1,1 1,2 1,-1
2 2,0 2,1 2,2 2,-1
...
-1 -1,0 -1,1 -1,2 -1,-1
Now you can start the state array setup. But first, there is one last
part of this system that requires explaining. Because this is meant to
be a pen-and-pencil system, there is no need for 256 possible
characters. This is the third reason why I split everything into 4 bit
chunks. But 4 bits is 16 possible characters, not enough, so I used a
straddling checkerboad for the substitution from letters to numbers.
While this is considered a cipher in and of itself, I doubt if it adds
any security to this system. I only included it as a simple form of
text compression. Here are two possible configurations you could use,
depending upon how many possible characters you want:
0 1 2 3 4 5 6 7 8 -7 -6 -5 -4 -3 -2 -1
_ T O I S L C U D H R N A E
-3 P W V . 0 1 2 / ( ! 5 6 7 , G M
3 F B Q J Z 3 4 - ) ? " 8 9 X K Y
0 1 2 3 4 5 6 7 8 -7 -6 -5 -4 -3 -2 -1
_ T O I S L C P U D H R N A E
3 F W B V Q J . , " ? Z X K G Y M
(_ is a blank space)
I designed both of these so that the most common letters are with the
lowest numbers, making encryption faster. For those of you who are not
familiar with the straddling checkerboard, characters in the top row are
substituted with the single number above them. Other characters are
substituted with a pair of numbers: row column. You will notice that
the numbers used for rows do not represent characters in the first row,
so that when decrypting, there is no ambiguity.
Everything else is simply following the RC4 algorithm. Just encode your
message first with the straddling checkerboard, and group the numbers
into pairs (all of that can be done in your head very easily while doing
RC4), then add a pair of numbers generated by RC4 to each pair of
numbers in your message to encode. You will need a pair of place
markers (this can be just about any small object), call them A and B.
The steps for encryption are as follows:
Move the A marker forward one space. If it reaches the end of a row,
move it to the 0 column of the next row (ex. 4,-1 to 5,0)
Move the B marker by the numbers under the A marker. For example, if
the A marker is pointing to a space with (-5,7), then move the B marker
5 spaces up and 7 to the right. If you ever hit the edge of the grid,
just wrap around.
Swap the values of the spaces under the two markers. If you are doing
this with pencil and paper, this requires erasing. The whole system can
be made even faster by using slips of paper or tiles with the coordinate
pairs writen on them, where you would only need to swith the two tiles.
Add the two values of the two markers. This can be done without doing
any mental arithmetic by using the matrix. Point to the top left space,
then move by the numbers under marker A (e.g., 2,-4 means move down 2
and left 4), then staying where you are, do the same with the numbers
under marker B. The space you are now pointing at contains the values
generated by this step. Add that number pair to the next number pair in
the message. This can also be facilitated by the matrix the same way as
above, only when you are pointing at the final space, don't use the
numbers writen in the space, use the coordinates of the space. These
numbers, in the order (row,column), are the next two numbers in the
encrypted text.
Repeat.
This message is getting rather long, so I won't describe the state array
setup routine. I'll just say that, if you already know how RC4 works,
then this will follow logically from everything I've already described,
just "encode" your passphrase with the straddling checkerboard before
you begin.
This should be significantly faster than Solitaire, and probably more
secure too. The only disadvantage being that you have to draw out a
large grid, whereas Solitaire only needs a deck of cards. So they both
probably have uses under different circumstances, but Solitaire
definately still has the "coolness" factor.
I would really like to hear any feedback people have to this system; and
if you see a mistake or a possible improvement, I would like to hear
that as well.
-Patrick Schultz
------------------------------
From: Anders Thulin <[EMAIL PROTECTED]>
Subject: Re: Extremely slow in DES software implementation
Date: Fri, 15 Sep 2000 10:13:21 GMT
"P.C. Teo" wrote:
> I am implementing a standard DES software (Downloaded from Internet) in my
> project. I found that it takes around 25+ seconds to encrypt a 1MB file but
> PGP takes less than 4 seconds.
You don't say which implementation you've selected -- but it's probably
not one written for speed. Nor do you say what language you've implemented
it in, or what plattform it runs on: it's difficult to suggest improvements
without that information.
On the assumption that you're using C, I suggest you take a look at fcrypt
or ufcrypt. You may also want to cast an eye over
http://www.cs.cmu.edu/People/dkindred/des/bitslice.html
for some ideas for speedups.
--
Anders Thulin [EMAIL PROTECTED] 040-10 50 63
Telia Prosoft AB, Box 85, S-201 20 Malmö, Sweden
------------------------------
Date: 15 Sep 2000 10:23:22 -0000
From: Rudolph Weiss <[EMAIL PROTECTED]>
Subject: Proposed Mixmaster Protocol
Crossposted-To: alt.privacy
proposed protocol for "new" Mixmaster 3.0
http://www.eskimo.com/~rowdenw/crypt/Mix/draft-moeller-v3-
01.txt
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Intel's 1.13 MHZ chip
Date: 15 Sep 2000 10:41:46 GMT
Mok-Kong Shen wrote:
>To gain impressiveness is in fact often a motivation of
>purchasing expensive exquisite things. (Ladies buy diamonds
>for that, though artificial diamonds would look almost as
>well.)
Correction: The best imitation (not the same as artificial)
diamonds are indistinguishable from real diamonds with the
naked eye.
>Right in the sixties one company in Munich had an
>IBM 360/20 (its mode of operation must be ridiculous
>for those acquanited only with today's computers) operating
>right behind its show-window so that everybody knew that
>it employed wonderful high-tech.
Don't be silly! Nobody did such a thing - I was there and
saw for myself. Companies put banks of tape drives and
operator consoles behind the big windows. The actual
computer was always put in the background.
(Exception: Connection Machines and soe Crays looked cool
enough to put up front. Not the IBM or DEC metal cabinets,
though - too boring.)
------------------------------
Date: Fri, 15 Sep 2000 06:59:06 -0400
From: Zulfikar Ramzan <[EMAIL PROTECTED]>
Subject: Re: CRC's as MAC's
Right, I agree with David's suggestion.
Universal hash function based MACs typically start by applying a universal hash
function to a message m, to get an intermediary tag t'. Then, you apply a block
cipher or some other cryptographic construct to t', to get the final message
authentication tag t.
Some good starting points are the UMAC and Square Hash papers from Crypto '99 --
and the references therein. The original idea of using universal hash functions
for message authentication is due to Wegman and Carter, though at the time, the
formal definition of MAC security had still not been developed!
There is also another paper by Halevi and Krawczyk, which proposes the MMH family
of hash functions; I believe this paper appeared at Fast Software Encryption '97.
In general, there is a fundamental connection between coding theory, message
authentication, and universal hashing, and many constructions that work well in
one setting can be modified to work in the other. [in fact, I believe the first
paper to formally study the problem of message authentication was written by
Gilbert, MacWilliams, and Sloane].
Zully.
"David A. Wagner" wrote:
>
> Dido Sevilla <[EMAIL PROTECTED]> wrote:
> > The best idea I've been able to find so far is the use of a CRC
> > algorithm. The MAC would essentially be a 128-bit CRC, encrypted with a
> > block cipher, which provides our keying.
>
> Look at the literature on 2-universal hashing & message authentication.
>
> One provably secure construction is roughly similar to what you suggested;
> but the CRC polynomial must be secretly and uniformly chosen from the set
> of primitive polynomials, and there are a few other technical conditions
> you must be sure to get right.
>
> If the CRC polynomial is not secret, or not randomly chosen, then your
> suggestion is definitely not secure.
--
--Zully
=======
Zulfikar Ramzan (AKA Zully)
Laboratory for Computer Science, MIT
NE43-311, (617) 253-2345
http://theory.lcs.mit.edu/~zulfikar/homepage.html
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Kryptcon
Date: Fri, 15 Sep 2000 12:06:34 +0100
Eh? It is crap! Why don't you read ANY of the literature on
cryptography to identify why this cipher is so poor? One assumes
that, if you're a student, you have access to a semi-reasonable
library, no?
--
Sam Simpson
Comms Analyst
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
<[EMAIL PROTECTED]> wrote in message
news:8pli1s$lto$[EMAIL PROTECTED]...
> While I appreciate you taking the time to look at
> my program, I do not appreciate you being a jerk
> and telling me that it is crap. My original post
> was asking for anybody who would wish to help a
> student with his research in cryptography. If
> you can't understand that, maybe you should just
> keep your thoughts to yourself.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Lossless compression defeats watermarks
Reply-To: [EMAIL PROTECTED]
Date: Fri, 15 Sep 2000 10:54:13 GMT
Matthew Skala <[EMAIL PROTECTED]> wrote:
: The success of watermarking schemes, in a world of lossy compression,
: depends upon either the user's willingness to accept signal degradation,
: or the deficiencies of the lossy compression at removing spurious data.
...or the fact that some thieves may be unaware of the presence
of the watermark, and thus make no effort to remove it.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Future Beacon <[EMAIL PROTECTED]>
Subject: Re: RSA Questions
Date: Fri, 15 Sep 2000 07:54:34 -0400
Thank you Bill Unruh, Bryan Olson, and David Hopwood
for your very complete answers.
I have a more general question: Why is RSA regarded
(if it is) as an advance over Diffie-Hellman? The
latter is so simple, and I don't see that RSA is more
secure.
Thank you for your help.
Jim Trek
Future Beacon Technology
http://eznet.net/~progress
[EMAIL PROTECTED]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Intel's 1.13 MHZ chip
Date: Fri, 15 Sep 2000 14:32:24 +0200
Guy Macon wsrote:
>
> Mok-Kong Shen wrote:
>
> >Right in the sixties one company in Munich had an
> >IBM 360/20 (its mode of operation must be ridiculous
> >for those acquanited only with today's computers) operating
> >right behind its show-window so that everybody knew that
> >it employed wonderful high-tech.
>
> Don't be silly! Nobody did such a thing - I was there and
> saw for myself. Companies put banks of tape drives and
> operator consoles behind the big windows. The actual
> computer was always put in the background.
Were you in Munich in the sixties??
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: 20 suggestions for cryptographic algorithm designers
Date: Fri, 15 Sep 2000 13:04:14 GMT
On 14 Sep 2000 20:59:15 GMT, [EMAIL PROTECTED] (D. J. Bernstein) wrote, in
part:
>David Hopwood <[EMAIL PROTECTED]> wrote:
>> If there is a completely arbitrary choice of byte order, use big-endian.
>No. Little-endian is much more widely supported than big-endian, and is
>universally supported by new processors.
I don't want to start a religious war here, but if yoou use
big-endian, the description of your algorithm will be easier to
understand, and less likely to be ambiguous by accident.
This is because English is written from left to right, and numbers are
written with their most significant digits on the left. So
illustrations of a sequence of digits being fed into a block cipher
will be able to show the bits of a block in order - and each bit will
be in the place, and performing the function, that a reader "expects",
whether he interprets the binary bits as being a single binary number,
or as a series of 8-bit bytes in order from first to last.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Lossless compression defeats watermarks
Date: Fri, 15 Sep 2000 12:58:38 GMT
On 14 Sep 2000 19:33:03 -0700, [EMAIL PROTECTED] (Matthew
Skala) wrote, in part:
>Thus, the watermark will necessarily be in the part of the signal that is
>thrown out by the lossy compression.
>Going in the other direction, if you have a watermarking scheme that
>survives lossy compression, then that implies some deficiency in either
>the watermarking scheme or the lossy compression or both: either the
>watermark is altering the perceptible part of the signal, or the lossy
>compression is transmitting some imperceptible information.
I recently purchased a book on steganographic techniques which showed
that there were more techniques than I had imagined. One possibility
is first to compress an image with JPEG, and put the watermark in the
DCT coefficients of the compressed image!
Lossy compression schemes, since they must still retain the compressed
image with high quality, are of necessity deficient in the sense you
outline, just as no lossless compression scheme achieves the maximum
possible compression. Compression techniques deal with simple and
obvious regularities and redundancies in images, not *all*
redundancies, or all possibilities for removing extraneous detail.
However, I have to admit that I think it is rather difficult, although
the papers in the book claimed it possible, to make a watermarking
scheme whose security relies solely on its key. If you know "where"
the information is hidden, one should be able to mask it by noise. But
I have to admit that spread-spectrum noise is difficult to deal with
in that way, and that is one of the other techniques given.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: 20 suggestions for cryptographic algorithm designers
Date: Fri, 15 Sep 2000 13:08:20 GMT
On Fri, 15 Sep 2000 00:24:13 -0400, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote, in part:
>David Hopwood wrote:
>> IMHO the arguments for big-endian order are more compelling.
>Unfortunately, some of the ones you gave were bogus.
>Both camps can arrange "compelling" arguments for their choice.
>I prefer little-endian representation for multiple-precision
>applications because it is slightly more efficient on average.
>It seldom matters enough to argue about.
Inside a processor, it indeed doesn't matter. Big-endian has
advantages for compare instructions, and little-endian has advantages
for arithmetic.
But when attempting to describe a block cipher algorithm to human
beings, who are used to a language whose writing system is derived
from the Latin alphabet, and whose numeration system is based on
Hindu-Arabic numbers, big-endian ordering has significant advantages
in making a specification clear, understandable, and unambiguous.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: 20 suggestions for cryptographic algorithm designers
Date: Fri, 15 Sep 2000 13:12:24 GMT
On Thu, 14 Sep 2000 22:19:18 -0700, Roger Schlafly
<[EMAIL PROTECTED]> wrote, in part:
>"D. J. Bernstein" wrote:
>> No. Little-endian is much more widely supported than big-endian, and is
>> universally supported by new processors.
>Really? I didn't think anyone used it but the Intel Pentium and
>DEC Alpha. Sparc, MIPS, etc are big-endian. I believe even some
>of the Intel processors can be wired to run big or little endian.
The forthcoming IA-64 or Merced will have this.
However, he is correct that little-endian is more widely used. Its
popularity derives from that of the PDP-11, which was the machine that
the early versions of UNIX ran on. So, in the 8-bit generation, the
8080 and the 6502 were both little-endian, and only the 6800 was
big-endian.
The PowerPC chip supports both byte orders, although it is big-endian
by default. But the number of people using the Sun Sparc or the MIPS
chip - if you don't count the people using MIPS chips in video games!
- and Mac computers - is indeed dwarfed by the people using the
Pentium.
But that is irrelevant to the "suggestions", since the rationale for
big-endian is based on what goes on inside _people's_ heads, not
inside computers.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: 20 suggestions for cryptographic algorithm designers
Date: Fri, 15 Sep 2000 13:15:52 GMT
On Thu, 14 Sep 2000 22:28:11 -0700, Roger Schlafly
<[EMAIL PROTECTED]> wrote, in part:
>David Hopwood wrote:
>> + As pointed out in [1], little-endian architectures and protocols are
>> often not entirely consistently little-endian, whereas big-endian
>> designs tend to be consistently big-endian.
>> [1] Danny Cohen,
>> "On Holy Wars, and a Plea for Peace,"
>> IEN 137, 1 April 1980.
>> ftp://ftp.isi.edu/in-notes/ien/ien-137.txt.3
>Its complaints about the PDP 11 are not relevant anymore. Since then,
>the VAX has died, but Intel and Microsoft have made sure that people
>are going to be using little-endian for a long time. All of Microsoft's
>binary APIs use little-endian.
This is true, even though I repeated the sad story of the PDP-11,
which is the machine whose influence inflicted little-endian on the
world, in a posting only recently.
(It's a pity that IBM hasn't designed an S/390 chip that is price and
performance competitive with the Pentium, and gone after the personal
computer market with an open system based on that.)
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 15 Sep 2000 13:53:48 GMT
Subject: Re: RSA Questions
For comparing DH, RSA, and ECC, see my whitepaper on ECC, Future Resiliency and
High Security Systems at www.certicom.com. In summary,
1) RSA operates in a secret group, its natural function is encryption, public
key operations can be performance optimized by using a low exponent, and is
based on the IFP, of which the best methods to attack are GNFS.
2) DH operates in a public group, its natural function is key agreement,
private key operations can be performance optimized, and is based on the DLP of
which there are 2 attacks (A) on p (field size) best attack is GNFS (B) on q
(prime order subgroup size) best attack is Pollard rho.
3) ECDH is similar to DH, except it only has a "q" value (for other reasons
often called n, the order of the prime order generator), so the best attack is
Pollard rho.
The DLP is considered slightly harder than the IFP for same sized keys. The
ECDLP is MUCH harder than the DLP. In summary
IFP < DLP << ECDLP
Don Johnson
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Fresh Meat: New Crypto Algorithms Announced
Date: 15 Sep 2000 13:45:11 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>> Er, do they plan on *deploying* these ciphers in anything?
> What could people without money do? In the worst case
> they would die for bad nutrition.
I was thinking more of reverse engineering. of course, people in a
position to reverse engineer are unlikely to die of bad nutrition (unless
you count an overdose of diet coca-cola).
-David
------------------------------
From: Future Beacon <[EMAIL PROTECTED]>
Subject: Re: 20 suggestions for cryptographic algorithm designers
Date: Fri, 15 Sep 2000 10:06:24 -0400
Shouldn't there be customs for the communication of algorithms
that are independent of programming languages (C was mentioned)
and independent of computer hardware?
In microprocessor data books and data books for other chips,
companies like Motorola and Texas Instruments have long used
a meta language of some sort to explain things. You might have
to deal with a new controller every year, but English, algebra,
and a few famous characters stay the same. You might see
something like this:
A --> B
B(X) --> C
C XOR A --> Y
C + (A/Y) --> Z
It is easier to say a few things like "do what is in the
parenthesis first" than it is to get a majority following
for your favorite programming language before the discussion
begins.
Definitions of notation might allow algorithms to be expressed
generically. Anybody can explain their implementation in their
favorite platform, but where is the thing that is analogous to
music notation as opposed to the synthesizer wiring?
In my opinion, the guidelines need to start
with the most obvious meta language we can
agree on.
In this news group we see a lot of ASCII and X^Y meaning X raised
to the Y. I like that because it isn't platform specific. I notice
that subscripts are less standard among us. I like A[5] for A sub 5
because that's how HTML shows up in text; but let's talk about it.
What do you think?
Jim Trek
Future Beacon Technology
http://eznet.net/~progress
[EMAIL PROTECTED]
------------------------------
** 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
******************************
