Cryptography-Digest Digest #627, Volume #11 Tue, 25 Apr 00 12:13:02 EDT
Contents:
Re: new Echelon article (Diet NSA)
Re: quantum computation FAQ? (Diet NSA)
Re: GSM A5/1 Encryption (Guy Macon)
Re: The Illusion of Security (Guy Macon)
Re: The Illusion of Security (Guy Macon)
Re: The Illusion of Security ("Joseph Ashwood")
Re: sci.crypt think will be AES? ("Joseph Ashwood")
Re: papers on stream ciphers ("Joseph Ashwood")
Re: Question to Ritter (Terry Ritter)
Re: The Illusion of Security (Terry Ritter)
Re: factor large composite (Francois Grieu)
Re: factor large composite (David Blackman)
Re: AES Style CAST Cipher (Mark Wooding)
----------------------------------------------------------------------------
Subject: Re: new Echelon article
From: Diet NSA <[EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,alt.politics.org.nsa,alt.journalism.print,alt.journalism.newspapers
Date: Mon, 24 Apr 2000 21:08:19 -0700
In article <
[EMAIL PROTECTED]
net>, [EMAIL PROTECTED] wrote:
>If the truth is inappropriate, is lying appropriate?
It depends on the circumstances. People
often lie to children by getting them to
believe in the tooth fairy, Santa Claus,
etc. and this does not cause any serious
damage. It is only make believe (kind of
like your ability to know reality).
>the mindset going on at the CIA. Using that same defense, Tenet
and
>Hayden probably would get in trouble if they say things that
were
>inappropriate to the citizens, but that still is no excuse for
lying
How do you know that there is *no*
situation in which it would be appropriate
for Tenet or Hayden to deny, cover-up, or
otherwise lie, even if they don't want to,
for the sake of the greater good (e.g.,
national security) ?
>It's obvious that the U.S. has been using the capabilities of
Echelon
>and humint assets for years to scoop up economic information
and pass
>it along to specific U.S. corporations.
I don't think this is so obvious, because if
it were done as much as you seem to
believe then it would most likely be
better concealed.
Slick Willie just took it to a
>new level, and became very open about requesting political
>contributions in exchange for the goodies.
These would be U.S. "goodies", and not
economic intel gathered from foreign
targets. There is no need, for example, for
Bubba to offer the Chinese their own
"goodies", which they already possess.
Tenet and Hayden happen to
>be in the indelicate position of defending the running of the
op when
>someone noticed the U.S. hands in the neighbors' cookies jar.
>
If the U.S. were trying to take its
"neighbors' cookies", then why does the
U.S. give these neighbors so much
economic opportunity (e.g., trade, foreign
aid, military support which helps yield
the stability needed for long-term
economic expansion, etc.) ? Your opinion
does not make sense.
>>What if the CIA is not stealing, but is
>>instead reading info which is supposed to
>>be private? It might be wrong for a kid to
>>read his sister's diary, but this is not the
>>same as actually stealing the diary and
>>running off with it.
>
>You ought to be in government
No thanks.
if you can justify an ethic and morality
>breach that well.
It would be wrong for the U.S. government
to steal other's proprietary info to enable
the U.S. to gain unfair economic
advantage. However, in my opinion, it is
not immoral for the Gov't to secretly
view what potential tyrants or terrorists
may be up to, for the purpose of
protecting innocent people.
The fact is, the breach in this case is not
just of
>a philosophical definition of ethics and morality; it's
financial and
>the livelihood of American citizens they're screwing with.
How is the U.S. Gov't stealing info from
foreigners and then using this info to
screw with "the livelihood of American
citizens" ?
damage, but long term. Those
>buttwipes at Langley and Fort George
Your views would better serve as
"buttwipes".
Meade are more than happy to
>sacrifice others in their quest for patriotic glory because it
doesn't
>cost them if there's human collateral damage they never know
about.
It may not cost them even if they do know
about the damage.
" V hfdt afogx nfvw ufo axb (o)(o) " - Gtnjv
====================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: quantum computation FAQ?
From: Diet NSA <[EMAIL PROTECTED]>
Date: Mon, 24 Apr 2000 21:37:00 -0700
In article <
8e31nf$tca$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]>
wrote:
>
>There is a difference between searching and factoring.
>
>Factoring can be done in polytime using Shor's algorithm.
>
>Searching in the "generic" case, for which all we have is some
oracle
>which tells us "yes, that's it" or "no, that's not it" for a
given
>input, only has a quadratic speedup.
Actually, Grover's algorithm will be
exponentially better than any possible
classical algorithm if we compare worst-
case performances.
It is not polynomial in the same
>sense that Shor's algorithm is polynomial.
This is true.
>
>Also, for some reason I really hate the handwaving explanations
that
>reference "quantum parallelism." I think it's partially because
I used
>to spout something along those lines before I knew anything,
and was
>rightly made fun of for it. Not that I know enough to offer a
substitute
>now...
Basically, the potential significance of
quantum computation lies in its
algorithms which can exploit quantum
superpositions that can contain an
exponential number of different terms. A
very good introductory site is
http://www.qubit.org which contains
papers written by some of the best in the
field.
An FAQ should be written at an
introductory level with links to
additional info and references, for those
who want a more advanced treatment. It
is fine for you to assemble an FAQ
because, even though you are not an
expert, it is obvious that you are not a
quack (which cannot be said for many in
newsgroups).
" V hfdt afogx nfvw ufo axb (o)(o) " - Gtnjv
====================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: alt.dev.null
Subject: Re: GSM A5/1 Encryption
Date: 25 Apr 2000 01:47:24 EDT
In article <8dv7de$uqs$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David A. Wagner) wrote:
>
>Look, you are just speculating about whether this proposed
>change to GSM can be made to work without too much cost.
Sigh. You think that every time someone changes the content that
GSM encrypts it is a "change to GSM".
>I am skeptical, and I've tried to explain why, but it doesn't
>seem to have helped. At this point, it seems pretty unlikely
>that explaining in any further detail would be productive.
Objecting to what I actually write instead of something that you
pull out of thin air would help a lot.
>Why don't you go read the GSM specifications, study whether
>your proposal can be cheaply implemented, and post the results
>of your detailed analysis? Then maybe we can have an informed
>discussion.
How far do I have to dig into specs to prove that zero change can
be cheaply implemented? I proposed not changing one single bit of
the code. How hard is that to do?
>As it stands, I don't think this is a topic that can be
>profitably discussed in the abstract without knowing anything
>about GSM internals. (Except possibly for the point that, due
>to the fixed frame length in GSM, your proposal would naively
>appear to introduce a large bandwidth overhead, ~ 15% or so.)
Bullshit. You are either a liar or you are stupid. Or both.
You pull these dubious assertions out of your ass and ignore the
dozen or so times that I carefully explained to you what I was
proposing. You are agruing against a fantasy in your mind, not
against anything that I ever wrote. Welcome to my killfile.
***** PLONK!! *****
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: The Illusion of Security
Date: 25 Apr 2000 01:55:50 EDT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry Ritter) wrote:
>If we get a cipher executable off the net, we really have no idea what
>we get. But if we must assemble and link source code to use the
>cipher, we will be part of a remarkably small group. So these are
>also not solutions.
What do you think of the solution to this particular problem proposed at
[ http://www.ciphersaber.gurus.com ]?
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: The Illusion of Security
Date: 25 Apr 2000 02:02:00 EDT
In article <pYWM4.20784$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (ijl)
wrote:
>Actually, Kolmogorov has proven that nothing can be "proven" to be truly
>random. On the other hand, Kolmogorov also shows that almost all strings
>which could exist ARE random; yet, it is not possible to prove a string as
>random using the metric of compressibility.
Would the following statement be correct. or is my thinking off somewhere?
A true random string of bits can have any value. If your method of
generating such a string of bits makes outcomes such as 00000..., 11111....
or 010101... impossible (as opposed to rare), that alone is proof that
the string of bits is not true random.
Am I understanding this correctly?
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: The Illusion of Security
Date: Mon, 24 Apr 2000 23:02:19 -0700
> OK, I have to start from some place; what am I
> allowed to assume? For instance, the standard
> interpretation of why particle decay modes display
> a half-life (that the probability of decay in a
> given interval of time does not depend on history)
> would seem to satisfy your requirement.
To establish that you must also prove that an attacker
cannot force the randomness to disappear. And actually decay
may or may not qualify, I believe it has not been proven
that I cannot create a particle, or an environment for that
particle, that would cause it to decay in a less than random
fashion (see Nuclear Bomb for a particular example of a
special type of decay occuring in a very predictable
timeframe given correct stimulus). Remember an attacker does
not have to obey your rules, if you make an assumption, your
attacker will attempt to violate it. Basically if you assume
it, it had better be absolute fact, other than that I can
grant no assumptions, because they can be made to be false.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: sci.crypt think will be AES?
Date: Mon, 24 Apr 2000 23:21:45 -0700
Ok let's assume the best possible situation for a key
schedule, and functions.
Given a restricted output space of n.
If the key schedule function combination is applied n times,
at least two outputs of the function must be equal.
Since we wish to apply this to repeating round functions, we
do so.
There must be an occassion where a given i and j rounds
(where i < j <=n) the output of ith and jth rounds, must be
equal.
>From this one can conclude that using i rounds and j rounds
must offer equivalent security (since if one uses j rounds
to encrypt, an attacker needs only attack i rounds).
>From this I conclude that there is a very real limit of the
maximum number of useful rounds of a cipher. This limit is
very real, and to my knowledge noone has computed the limit
for any modern cipher in terms of rounds.
Joe
"David A. Wagner" <[EMAIL PROTECTED]> wrote
in message
news:8e2f83$vp3$[EMAIL PROTECTED]...
> In article <#GIeloir$GA.304@cpmsnbbsa04>,
> Joseph Ashwood <[EMAIL PROTECTED]> wrote:
> > Some people have supported using Rijndael with more
rounds,
> > which may be an option, but will slow the entire system,
and
> > has not been analyzed.
>
> What do you mean "has not been analyzed"?
> All of the published analysis against Rijndael to date
> will still apply if we increase the number of rounds.
>
> > Since it can be easily established
> > that having too many rounds actually weakens security
and
> > the maximal round number has not been determined, I do
not
> > support that option.
>
> Easily established? I'd like to challenge you to do so.
> I disagree: if the key schedule is good, adding more
rounds
> can't hurt (except -- I would contend -- in rare,
contrived
> cases primarily of academic interest). One can even prove
> some statement to this effect if one is willing to assume
> that the key schedule is sufficiently good (a pseudorandom
> generator).
>
> As far as I can see, there are no practical reasons to be
> concerned that adding rounds to Rijndael will make it less
> secure, and plenty of reasons to think that it might make
> it more secure.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: papers on stream ciphers
Date: Mon, 24 Apr 2000 23:25:46 -0700
>> For an attack XOR has several useful properties, the most
>> important of which being that if one knows the plaintext,
>> one can easily encrypt a new message to the same
recipient
>> with the same key, without determining the key.
> This is pure garbage. If my output is pure random junk
and I xor it
> against the plaintext I have a provably secure system.
First on what grounds do you consider it pure garbage?
Solely on the grounds that you can think of no other attack
on my theory? My theory has very solid backing, perhaps a
quick example:
Known plaintext: 0xDEADBEEF
Known ciphertext: 0x12345678
Pad(previously unknown):0xCC99E897
New message: 0xA38DA7ED
New Ciphertext (encrypted with the same pad so on decryption
it will make sense to the reader): 0x6F144F7A
Additionally how do you pretend to generate this "pure
random junk"? Please see the thread on randomness in Quantum
Cryptography where it is stated that Kolmogorov proved that
you cannot prove randomness.
>
> > Even if the pseudo random pad is cryptographically
secure,
> > there are various attacks on the plaintext (see the
> > dicussions on attacks on OTP). I need no further proof
to
> > state that they can be made more secure, than to state
that
> > the one that has been proven secure, still has attacks
on
> > the plaintext, while against DES we have no such attacks
> > significantly better than brute force. Against this
attack
> > even absolute security is weaker than DES (a weak
> > algorithm).
>
> You are so wrong. If your "pad" or prng is
cryptographyically secure
> then xoring it against the plaintext is all you need todo.
See above.
>
> Geez... read up some more first.
Perhaps you are the one without enough education, all of my
claims can be proven, your basic claim each time is "pure
garbage" which you haven't even supported.
Joe
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Question to Ritter
Date: Tue, 25 Apr 2000 06:39:55 GMT
On Mon, 24 Apr 2000 16:11:11 GMT, in <8e1rmf$p9n$[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] wrote:
>I think I understand what you are saying which is basically this:
>
>1. No Cipher can be gauranteed to be secure.
>2. We only know about published info on the weakness of a Cipher
>3. It could be that our opponent has secretly broken the Cipher..and we
>dont know.
>4. It all depends on our threat model...
I do not agree with 4. Items 1 through 3 are true independent of 4.
Possibly you mean that different opponents may have different
capabilities, which naturally makes cipher strength contextual and
dependent on the particular opponent involved. But in general we
can't know about that anyway.
>OK....Mr Ritter...Lets assume that our Threat Model is that which is
>based on the original message in this thread...Lets do a thought
>experiment....lets assume that his assumptions are valid regardless of
>how far fetched they are...
>
>Mr Ritter....you are invited to meet our Chairman as a consultant to our
>organisation...
>
>What is your advice..?
In practice, the Chairman probably doesn't want to hear my reasoning,
but instead wants to decide whether I am the kind of person who can
and will do what needs to be done. I might say that other companies
do "keep all their eggs in one basket" by using a single cipher, but
that in cryptography it is *impossible* to "watch that basket," so all
those other companies are risking all their information. I would
recommend placing the information "eggs" in different and sometimes
lesser baskets, knowing that we may lose one occasionally, with the
hope that most will survive. The Chairman will not like this because
he will be a conservative person who knows that new approaches often
fail. I would point out that we can use whatever cipher we would
normally use *in* *addition* to the new approach, but then he will
wonder why I would recommend that he invest more in processing than
his competitors. Then I would ask him why the hell he called me in in
the first place. Generally, that will be the end of it.
But if he really wants to improve security, and absent major financial
constraints, I would establish a group of people -- most smarter than
me -- to oversee the selection and use of ciphers and the rest of the
system. I would establish a protocol for cipher selection and start
building an accepted working-set of ciphers to be used.
>Based on the premise of the message that all public ciphers based on DES
>like design are insecure...
>
>1. Your Cipher Cascade is not going to work...because the layers will be
>peeled off like an Onion , one by one...
That does not follow: Even with an assumption that all Feistel-like
ciphers are insecure, we presumably can buy security with ciphers that
operate in other ways. So "my" cipher stacks *are* likely to work,
provided we include a variety of different non-Feistel approaches.
>2. We even have a more serious problem, because Hybrid Crypto systems
>will not work either because of the weekness of PK crypto.
If a cipher is weak, our only choice is to use another cipher. If we
must assume that no other cipher is strong, then we are pretty well
done. Since that is fairly obvious, I would suggest that this is a
strange line of questioning. That is not my approach. My approach is
that we cannot *know* that any cipher is strong, not that every cipher
is weak. If we know every cipher to be weak, we are done.
Since we do not have scientific evidence to support strength in any
cipher, we must be prepared to lose some information. We can seek to
minimize that loss by using many different ciphers, and by using a
"stack" of three "randomly" selected ciphers. Or we can use two such
ciphers, plus any particular cipher we think best. We can change
ciphers frequently to terminate any break that does occur. We also
can seek to impose new operational costs on our opponents by
continually growing the number of ciphers in use, thus reducing the
resources they have available to attack any one cipher. This may tend
to keep even new weak ciphers unbroken for some time. All this can
help, but we still must be prepared to lose some information. We hope
to buy the advantage of only losing *some*, not *all*.
>So what is your advice Mr Ritter..I have given you our threat model...
>
>
>After you give your answer..I would like you to focus on these two
>issues to see if they are practical and can be implemented or not?
>
>
>1. Is it possible to have a set of Orthoganal F functions in an S - Box
>design rather then a single one dimensional non-linear F Function...?
I guess that depends upon what you mean. Sure, we can have a set of
orthogonal functions in an S-box. But my usual approach is to fill
the box as a "random" function, using a box of sufficient size such
that it is very likely to be quite distant from linear. Since random
S-boxes can include *any* *possible* structure in data, they are
clearly *not* restricted to a "one dimensional" function. Indeed, I'm
not sure I know what that means.
>2. Is it possible to develop a hybrid PK system made out of different
>PK schemes to confuse our opponent even more? I dont mean multiple PK
>keys...but a single pair of Hybrid Keys.
My arguments for multiple ciphers are normally oriented to the data
cipher, but the same arguments could be applied to the
key-distribution cipher as well. The problem would seem to be in
having enough difference in the PK systems such that breaking one
would not break them all. I suppose you are proposing the
simultaneous use of multiple PK systems in such a way that it would be
difficult to identify and separate the few systems we do have, thus
making an attack more difficult. I don't know if that will help or
not. I do think there is some desire to keep the PK machinery
"pristine" and so perhaps limit attacks to those having a
number-theory base. In any case, while most people do assume the
presence of a PK cipher for key distribution, the multi-cipher
approach works just as well with secret keys. So if we are afraid
enough of PK weakness, we simply do not use PK.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: The Illusion of Security
Date: Tue, 25 Apr 2000 07:09:49 GMT
On 25 Apr 2000 01:55:50 EDT, in <8e3c16$[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (Guy Macon) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry Ritter) wrote:
>
>>If we get a cipher executable off the net, we really have no idea what
>>we get. But if we must assemble and link source code to use the
>>cipher, we will be part of a remarkably small group. So these are
>>also not solutions.
>
>What do you think of the solution to this particular problem proposed at
>[ http://www.ciphersaber.gurus.com ]?
It would help me to know what you think the solution was. Since I
think only a small group would even compile source, I expect it would
be an even smaller group who would actually construct the source
themselves. Many of those who could do that might disagree with the
cipher design and so not want to. That doesn't sound like a solution
for society, but some hobbyists might like it.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: factor large composite
Date: Tue, 25 Apr 2000 10:24:04 +0200
[EMAIL PROTECTED] (EP847) wrote:
> Can anyone tell me what the fastest method of factoring
> a 2048 bit RSA key is
Assuming one start from the public key only, the best currently
known algorithm is the GNFS. Currently, its (publicly known)
RSA key factoring record is against a 512 bit key. This was done
on August 22, 1999. Resources used included over 290 PCs and
workstations for over 3 month (working part time, but still over
35 CPU years); and 224 CPU hours and 2 Gbytes of central
memory on a Cray C916.
For a 2048 bit key, the expected number crunching power is over
10^14 higher, and the memory requirement over 10^7 higher.
So the problem is not: how much time does it take to factor a
2048 bit RSA key with current technology,
but rather: when will future technology be able to do it.
With a lot of assumptions, in their paper "Selecting Cryptographic
Key Sizes", Arjen K. Lenstra and Eric R. Verheul estimate factoring
a 2048 bit key in year 2023 may appear about as difficult as it
seemed to factor a 512 bit key in 1986, which was achieved 13 years
later. You figure. I won't bet the 2048 bit landmark will be
reached before year 2048, because I am one of those who expect
Moore's law won't hold for another half century.
Francois Grieu
------------------------------
From: David Blackman <[EMAIL PROTECTED]>
Subject: Re: factor large composite
Date: Tue, 25 Apr 2000 18:29:44 +1000
EP847 wrote:
>
> Can anyone tell me what the fastest method of factoring a 2048 bit RSA key is
> ( i know the time will be *very* long )
> thank you
Wait until someone invents a much better algorithm than anything we have
now, then use that.
Last time i looked was a couple of years back and the fastest methods
for large numbers were "multiple polynomial quadratic sieve", "number
field sieve", and "elliptic curve method". There was much debate over
which one was really fastest, and how they would scale to larger numbers
than the approx 500 bits that have been done so far. There used to be
web pages describing these and maybe with source code. Try a search
engine. Also try the maths and computing sections of your local
university library.
None of these methods have any hope of factorising a 2048 bit number at
all on current hardware, except maybe elliptic curve might fluke a
solution if you get incredibly lucky.
Since you have said it is a RSA key, there are various back-door ways
that might possibly be used to factor the number indirectly. If you can
get hold of the private key, for instance, it is quite easy to figure
out the factors from that. But the private key is supposed to be a very
closely guarded secret.
Or if people were careless with the random number generator they used to
generate the key, it might be possible for you to run a similar random
number generator with similar inputs and arrive at the same key,
complete with factors.
People used to worry that there might be some weakness in the RSA
protocol (not the number theory part, the part that describes in
painstaking detail what bits go on the net) that might give hints of
what the factors are. That has been studied for a long time now without
finding anything, so it's probably clean. However if the owners of the
key are using a buggy implementation of the protocol, it's just about
possible it might tell you something.
Actually the most likely attacks involve physical break-in, or bribery,
or going through the garbage looking for something that wasn't shredded
properly, etc.
Any of these attacks is illegal most places if you use it on an actual
RSA key that is used for secrecy or authentication and is not owned by
you. (But government security organisations usually have exemptions, and
criminals just don't care, so there are probably quite a few people
trying all of the above.)
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: AES Style CAST Cipher
Date: 25 Apr 2000 08:45:54 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> I have one question... If you look at my source I have the PHT then the
> key mixing... should it be the other way around? I just left it like so
> because I don't know which is better...
1. Comments on cipher structure
Block cipher design isn't really my field. That's never made me keep my
opinions to myself yet, though.
Your structure reminded me a bit of Twofish (with the PHTs to double the
Feistel block width, and the 4 8x32 S-box results XORed together). A
brief comparison of your basic cipher structure with that of Twofish is
interesting.
Twofish keeps most of its mess in its Feistel function -- there are just
a couple of rotates outside to break up the byte structure some more.
You've got your PHT and key mixing in the main cipher structure (a bit
like Blowfish, in fact). Leaving that aside -- I suspect it's not
terribly important -- the main difference I see is that Twofish treats
its initial whitening step as addition of key material and follows it
immediately with its serious diffusion step of rotation, S-box
substitution, the MDS matrix and the PHT.
By contrast, your cipher (which probably deserves a name at some
point[1]) does the input whitening, a PHT and then more key mixing. I'd
probably go as far as suggesting that you don't need input whitening in
a block cipher which does key mixing directly rather than in the Feistel
function -- see Blowfish for an example of how this works. I'd probably
do the key XOR, PHT and then the Feistel function, once for each round,
and then an output whitening step. If I were feeling paranoid, I'd put
in a one-bit rotate after the PHT, rotating each half of the output in
opposite directions, just to shunt the results of the carries around a
bit more.
2. Comments on the code
C programming really is my field.
`memcpy' is a rotten way to convert bytes to words. It's thoroughly
nonportable. Don't do it. As an example of a good, portable way to do
this, visit http://www.excessus.demon.co.uk/misc-hacks/#mLib, fetch the
latest version, and see the LOAD32 and STORE32 macros.
`clrscr' is not a C function. It may be provided by some
implementations but its use is nonportable. As an aside, clearing the
screen (as I believe is the purpose of this function) is unnecessary and
annoying.
The `main' function returns an `int', not `void'. You must return a
value from `main' -- if nothing better occurs to you, return zero.
Read the comp.lang.c FAQ for lots of good advice about writing portable
C.
[1] A quick look at Wordnet suggested the name STAMP to me for no
particularly good reason except that it was offered as a synonym for
CAST.
-- [mdw]
------------------------------
** 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
******************************
