Cryptography-Digest Digest #356, Volume #11 Fri, 17 Mar 00 18:13:02 EST
Contents:
Re: Quantum crypto flawed agains Mallory? ([EMAIL PROTECTED])
Re: The Breaking of Cyber Patrol� 4 ("seifried")
Re: KDC + secret key == public key? (Doug Stell)
Re: new/old encryption technique (Samuel Paik)
Re: my toy cipher ([EMAIL PROTECTED])
Re: Maybe public key is more secure (Mok-Kong Shen)
Re: how to introduce hs students to cryptography (wtshaw)
Re: 64-bit Permutations (wtshaw)
Re: 64-bit Permutations (John Savard)
Re: linux's /dev/random (Kevin Buhr)
Re: Universal Language (drickel)
Re: Maybe public key is more secure ([EMAIL PROTECTED])
Re: Maybe public key is more secure ([EMAIL PROTECTED])
Re: Cipher Contest ("Kasper Pedersen")
Re: Cipher Contest ("Kasper Pedersen")
Re: Cipher Contest (SCOTT19U.ZIP_GUY)
Re: EOF in cipher??? (Jerry Coffin)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Quantum crypto flawed agains Mallory?
Date: Fri, 17 Mar 2000 20:56:10 GMT
> This 4 page paper describes a quantum
> authentication protocol:
> http://arXiv.org/abs/quant-ph/0001046
Well, the paper is really academical and I lack the required
training to understand it without studing it very well. I got some bits
of information, maybe you could help me and comment my conclusions.
Isn't this paper based in the QKD, which has been proven insecure
(as stated in Mitra's paper) ?
> Mitra has devised a novel method for ensuring
> the "absolute security of classical and
> quantum keys":
> http://arXiv.org/abs/quant-ph/9912074
>From what I understood, Mitra's technique requires a shared key
between the legitimate users. How could we exchange this shared key
securely?
Daniel.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "seifried" <[EMAIL PROTECTED]>
Subject: Re: The Breaking of Cyber Patrol� 4
Date: Fri, 17 Mar 2000 21:13:24 GMT
"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
news:8au48v$55q$[EMAIL PROTECTED]...
> In article <HUnA4.8402$[EMAIL PROTECTED]>,
> seifried <[EMAIL PROTECTED]> wrote:
> >ftp://ftp.cryptoarchive.net/pub/cryptoarchive/censorware/CyberPatrol/
> >
> >cp4break.zip
> >cp4break.html
>
> Why don't you put these files on an http server instead of an ftp
> server. That way people can download through the many anonymizing
> proxy servers on the net, e.g. www.anonymizer.com.
Those proxies are mostly useless IMNHO, if you want REALLY ANONYMOUS (TM)
Internet access with "badass" (I prefer that over "military strength" =)
crypto then use Freedom net (www.freedom.net, disclaimer, I got nothing to
do with them except I like the product and have meet Ian Goldberg in person
and he seems ok).
Back to the topic at hand, why didn't I make it available on the web? Well
it was 3am or so and it slipped my mind.
http://www.cryptoarchive.net/pub/cryptoarchive/censorware/CyberPatrol/
We aim to please. If anyone else has any CryptoArchive comments/requests,
please, let me know.
--
Kurt Seifried - Senior Analyst
[EMAIL PROTECTED]
http://www.securityportal.com/
http://www.cryptoarchive.net/
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: KDC + secret key == public key?
Date: Fri, 17 Mar 2000 20:57:37 GMT
On 17 Mar 2000 20:12:39 GMT, [EMAIL PROTECTED] (James F.
Hranicky) wrote:
>It dawned on me that if you allow user A to ask the KDC to perform
>encryption with B's secret key, you essentially have a PK-like
>interface for Kerberos. To send an encrypted message to B, I send
>the message and B's address to the KDC, and the KDC can return the
>message to me encrypted in B's key. To check B's signature in a
>message, I take the hash of a messgage from B and B's encrypted hash,
>send them to the KDC, then the KDC would tell me whether it was a good
>or bad signature.
I don't think you know what the Key Distribution Center does. Also,
sending a file in the clear to the KDC would compromise the file.
A shares a key, Kak, with the KDC. B shares a different key, Kbk, with
the KDC. A and B do not share a key with each other. If A wants to
talk securely to B, the following happens. This is a simplified,
nutshell description, i.e., basic Needham and Schroeder.
1. A asks the KDC for permission to talk to B, protected under Kak.
2. KDC generates Kab and encrypts it under Kak and Kbk.
3. KDC sends both copies to A
4. A uses Kak to extract Kab.
5. A sends the other secure copy to B.
6. B uses Kbk to extract Kab.
7. A and B communicate, protected under Kab.
Kerberos started out as the basic N&S scheme, but has become more
enhanced with version 5. Also, weaknesses were found in the basic
protocol and changes were made.
I built a N&S product, as described above, before Kerberos was
conceived. Then I began my love affair with public key technology.
> a Only people in the same Kerberos realm can securely encrypt
> and verify messages -- anyone outside the realm would have
> use plaintext to communicate with the user's KDC.
Realm KDCs can intercommunicate to provide secure communication
between realms.
>For all I know, this has all been hashed out before. I thought it was
>interesting that a symmetric key + a KDC seemed to be equivalent
>to a public/private keypair.
They aren't equivalent, which is why I am ignoring signature in my
response. Symmetric keys and KDCs were around long before people
trusted public key technology enough. Also, public key computation
take a lot longer than symmetric key en/decryptions and this use to be
significant. In today's world, the scheme may be history. Another
approach would be to have a hybrid system that uses the faster
symmetric cryptography for intra-realm encyrption and public key for
inter-realm and signature purposes. Each technology has its place and
hybrid schemes often combine the best of technologies and use each
where it is most appropriate.
------------------------------
From: Samuel Paik <[EMAIL PROTECTED]>
Subject: Re: new/old encryption technique
Date: Fri, 17 Mar 2000 21:16:36 GMT
JimD wrote:
> On Fri, 17 Mar 2000 09:17:05 GMT, Samuel Paik <[EMAIL PROTECTED]> wrote:
> >Can we stop calling synchronous stream ciphers "one time pads" please.
>
> Well, they probably are if the cryptovariables are changed before
> they start to repeat.
No they are not.
Here is a trivial example: take two LFSR with maximal period of different
lengths and add them bitwise: the sum bit is the keystream and the carry
bit is carried in to the next bit addition. (this silly cipher is
being used in a consumer device that has sold millions of units...)
The period of this stream cipher is the product of the periods of its
component LFSRs, however, it only requires as many known plaintext bits
(maybe one more) as the sum of the bits of state (+1 more if the known
plaintext is not at the start...).
--
Samuel S. Paik | http://www.webnexus.com/users/paik/
3D and multimedia, architecture and implementation
You dont know enough about X86 or kernel architectures to argue with me.
- <38b2dc12$0$[EMAIL PROTECTED]> "Leon Trotsky" to Terje Mathisen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: my toy cipher
Date: Fri, 17 Mar 2000 21:09:44 GMT
Mr. Greenly,
I decided to have a crack at your sea64. As a goal, I wanted to find
one serious weakness. I tried differential cryptanalysis but was foiled
by the 64 rounds.
I did find a serious related key attack however. As other's pointed out
the key schedule is linear in nature. The downside of this is that if
one round key is found the key schedule can be reversed. So to break the
cipher, I will try to gain one round key.
If the difference(-) of two keys,K1 and K2, is your d1 and d2, then the
round keys will be off by 1. The first round key of K1 will equal the
second round key of K2.
The upshot of this is that the ciphertext of two such keys is partially
equal. The right half of the K1 ciphertext will equal the left half of
the K2 ciphertext. The XOR of the left of K1 and the right of K2 yields
the f(CK1,K1[0],K1[1]). We can expect such a pair to occur in 1 pair of
of 2^16 or 2^17 with chosen plaintext. Several pairs may be needed to
weed out wrong pairs.
Now given the input and output of the F function the two keys must be in
a set of 2^32. Via the equation
out = in <<<23 + a ^ b
If 'b' is assumed then 'a' is the only unknown and thus can be solved
for. Once the 64 round key is known, simple subtraction yields the
63,62,etc.
Several pairs can be tried or the 2^32 can be bruted against a known
plain text.
Here is an example
K1 = {223456789,999999 };
K2[0] = K1-d1;
K2[1] = K2-d2;
m={0xd5eec2a,0}; // randomly try pair in order to get a collision
n={0,0};
encrypt(m,K1); // cipher text is 0xC42B23F4 0x3DFDF1F3
encrypt(n,K2); // cipher text is 0x3DFDF1F3 0x32D4D746
// (0xC42B23F4^0x32D4D746) = f(0x3DFDF1F3,K1[64][0],K1[64][1])
This is an example of the related key slide attack. David Wagner wrote
a very interesting paper about slide attack. Bruce Schneier and friends
have written extensively about related key attacks.
--Matthew
In article <rkbA4.619$[EMAIL PROTECTED]>,
"Michael A. Greenly" <[EMAIL PROTECTED]> wrote:
> Anyone looking for a little crypto-anylysis fun is welcome to take a
crack
> at my little homebrew cipher. I suspect that nothing about this cipher
is
> secure but I had fun throwing it together and intend to have more fun
trying
> to take it apart.
...
>
> The code can be found here:
http://www.pinenet.com/~mgreenly/sea64.cpp.html
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Maybe public key is more secure
Date: Fri, 17 Mar 2000 22:29:11 +0100
Tim Tyler wrote:
>
> I'm under the impression many algorithms will be unaffected, and
> that moderate increases in key sizes will result in many public-key
> systems becoming usable again. I don't think it's as bad as all that.
There is still some room for the chip technology to further develop,
so that, by the time quantum computing becomes practical, the
transition to the new techniques might not be terribly sensational.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: how to introduce hs students to cryptography
Date: Fri, 17 Mar 2000 14:29:40 -0600
In article <8arbl4$141$[EMAIL PROTECTED]>, Bob Silverman <[EMAIL PROTECTED]> wrote:
>
> No. They key is to segregate students by *ability* and not to place
> honor students in the same class with students who struggle to
> achieve a C. [Yes, I know. This is politically non-correct and
> elitist. But one of the reasons U.S. education is doing a lousy job
> (IMO) is that it is trying to be too egalitarian. Stop trying to teach
> everything to everyone. ]
To be poopular, the smart kids let the dumb ones copy their work. With the
smart ones gone, and the trick removed, you can get a bad scene. I had
enough of let Robbie do it in one class I taught.
>
> Another key is to *enforce* pre-requisites. A pre-requisite for
> teaching crypto to high school students should be that they are
> all honors math students with at least two years of high school
> algebra (or even 1 year for the best students). Teaching the elementary
> number theory needed for crypto should not be difficult for this set
> of students.
>
The crypto bug hits most offen in 7th or 8th grade. These are the people
you want to encourage first, or there will be nothing but overtrained and
undercompetent engineers in charged. Feed the overachievers and the
intensely curious.
....
>
> Not all material is going to be fun. Expecting it to be is wishful
> thinking. Sometimes one has to suck in the gut and learn stuff
> that isn't fun or iteresting simply because the job or a professional
> work ethic requires it. Sometimes one must get self-motivated to
> learn stuff that is *difficult*. This is part of being an adult and
> a professional.
>
Those into the goal in the result do not rise or fall with the fun that
might be of the moment. Learning to get through discouragement by finding
the obstacle and breaching it is rewarding in itself. Life is too short
to have to take abuse, which is how too many try to motivate others.
--
Imagine an internet on an up and up basis, where there are no subversive techniques to
rob a person of their privacy or computer
functionality, no hidden schemes used to defraud anyone. :>)
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: 64-bit Permutations
Date: Fri, 17 Mar 2000 14:45:18 -0600
In article <[EMAIL PROTECTED]>, Stephen Houchen
<[EMAIL PROTECTED]> wrote:
> Imagine a cipher where you took plaintext in 64-bit blocks.
> The bits in each block are simply permuted in the same
> fashion for each block. The key, then would be the bit-
> mapping.
>
> My gut feeling is that this is so simple that it's probably not
> very hard to break.
>
> So cryptanalysts, how would you break it?
>
Mere, and only, simple transpositon is broken by comparing several blocks.
In spite of the key space for N=64 permutations being 296 bits in size, if
you know an expected bit pattern and unlikely ones, you compare the
parallel results of trial manipulations in the several blocks.
--
To see the results of GW Bush's shaddow, visit the Valley;
notice the miserable conditions he allows to fester.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: 64-bit Permutations
Date: Fri, 17 Mar 2000 14:40:42 GMT
[EMAIL PROTECTED] wrote, in part:
>I hope you do realize that the look up table for such a permutation would
>have a size of 137438953472 giga byte.
That's why it's never implemented that way.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Kevin Buhr)
Subject: Re: linux's /dev/random
Date: 17 Mar 2000 15:40:54 -0600
Eric Lee Green <[EMAIL PROTECTED]> writes:
>
> There is very good information at the top of the the random.c file in the
> Linux kernel. Just grab the Linux kernel sources from ftp.at.kernel.org
> (substitute your country code for the 'at'), and look in
> linux/drivers/char/random.c for the full skinny on the implementation.
For those who are interested in the documentation in Linux's
"random.c" but don't want to download a whole kernel source tree to
look at it, I've put a copy of "random.c" from Linux 2.2.14 (the
latest stable release) at:
ftp://mozart.stat.wisc.edu/pub/misc/linux-2.2.14-random.c
ftp://mozart.stat.wisc.edu/pub/misc/linux-2.2.14-random.c.gz
Kevin <[EMAIL PROTECTED]>
------------------------------
Subject: Re: Universal Language
From: drickel <[EMAIL PROTECTED]>
Date: Fri, 17 Mar 2000 14:04:17 -0800
In article <8arms3$8d7$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mike Mccarty Sr) wrote:
>The answer is "yes, but don't ask me to give you an example,
it's been
>too long!" IIRC, the vocative for god is BOGA while the
nominative is
>BOG. (Hopefully obvious transliteration being used.)
>
>Mike
That was my recollection--that it basically only existed in a few
common rote phrases (somewhat analagous to "By Jove"). Again,
it was too long ago to trust this, but _Bozhe moi_ might be an
example of the vocative; if so, it is probably far and away the
most common example (i've got a vague recollection of another
grammatical oddity concerning a phrase involving the devil--i've
forgotten whether it was an unusual declension or an example of
the vocative).
david rickel
* 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]
Subject: Re: Maybe public key is more secure
Date: Fri, 17 Mar 2000 22:00:46 GMT
> > I'm under the impression many algorithms will be unaffected, and
> > that moderate increases in key sizes will result in many public-key
> > systems becoming usable again. I don't think it's as bad as all
that.
>
> There is still some room for the chip technology to further develop,
> so that, by the time quantum computing becomes practical, the
> transition to the new techniques might not be terribly sensational.
I don't think chip technology could evolve to tackle any key-size...
Ordinary computers compute sequentially (or paralely in a finite number
of processors), so increasing the key size will make computations not
practical. Quantum computers, at least in theory, tries all the
combinations at the same time, so key length is really not an issue.
Daniel.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Maybe public key is more secure
Date: Fri, 17 Mar 2000 21:57:09 GMT
> The second channel is used to provide authentication.
>
> The resulting security is quite different from transmitting a message
over
> multiple channels with conventional encryption.
Anyway, we just use another channel for authentication because the
quantum is not adequate for it. We could authenticate users in other
channels in other protocols too.
My statement is that multiple channels add security (and complexity
too) for many protocols besides quantum cryptography.
> You don't need a secure line. In practice lack of security of the line
> could be used to jam it, but that's about all - eavsdropping on its
> contents tells you very little.
Sure. I just said that we would need to secure the line to avoid
Mallory in quantum cryptography.
> I'm under the impression many algorithms will be unaffected, and
> that moderate increases in key sizes will result in many public-key
> systems becoming usable again. I don't think it's as bad as all that.
Any algorithm that can be broken by brute force would be affected..
For example, would a algorithm like Enigma be broken by brute force in
a Cyphertext only attack? But with the majority of public key
algorithms (if not all), I think it would.
Daniel.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Kasper Pedersen" <[EMAIL PROTECTED]>
Subject: Re: Cipher Contest
Date: Fri, 17 Mar 2000 22:05:33 GMT
"Adam Durana" <[EMAIL PROTECTED]> wrote in message
news:55vA4.72$[EMAIL PROTECTED]...
>... Also we would need some sort of speed or
> maximum rounds requirement, so people could not submit ciphers with 1024
> rounds. Maybe we could set the maximum rounds to 16? Or should there be
a
> speed requirement? I think a speed requirement would be much more
difficult
> to decide on, so I say there should be a maximum rounds requirement.
>
...
> The "reasonable resource requirements" is needed so people can't submit
> ciphers that use huge amounts of memory, disk etc. I think it would be
> unfair to allow people to submit ciphers were the resource requirements
are
> unreasonable. This will have to be done on a case to case basis unless we
> want to set a maximum memory requirement.
Reasonable, but it would proper to allow exceptions, providing that there
was a reason to do so, and that they are explained: Such as if someone
submitted a cipher that would run under really extreme size constraints,
he/she should be allowed to use a large number of rounds if he can tell why.
(that's the category I'd be targeting. There are plenty of high performance
ciphers, but they are all BIG when space is tight.)
But - it would be nice to provide a way to test ciphers.
For C it could be done by #include'ing the file with the cipher, provided it
defined a few things
#define cipher_keybits 56
#define cipher_blocksize 64
void cipher_key(char *p)
void cipher_e(char *buffer)
void cipher_d(char *buffer)
that would fit almost anything (like DES for the above), and a few tools
could be found/fitted/written to help everybody.
/Kasper
------------------------------
From: "Kasper Pedersen" <[EMAIL PROTECTED]>
Subject: Re: Cipher Contest
Date: Fri, 17 Mar 2000 22:05:34 GMT
"Adam Durana" <[EMAIL PROTECTED]> wrote in message
news:55vA4.72$[EMAIL PROTECTED]...
>... Also we would need some sort of speed or
> maximum rounds requirement, so people could not submit ciphers with 1024
> rounds. Maybe we could set the maximum rounds to 16? Or should there be
a
> speed requirement? I think a speed requirement would be much more
difficult
> to decide on, so I say there should be a maximum rounds requirement.
>
...
> The "reasonable resource requirements" is needed so people can't submit
> ciphers that use huge amounts of memory, disk etc. I think it would be
> unfair to allow people to submit ciphers were the resource requirements
are
> unreasonable. This will have to be done on a case to case basis unless we
> want to set a maximum memory requirement.
Reasonable, but it would proper to allow exceptions, providing that there
was a reason to do so, and that they are explained: Such as if someone
submitted a cipher that would run under really extreme size constraints,
he/she should be allowed to use a large number of rounds if (s)he can tell
why.
(that's the category I'd be targeting. There are plenty of high performance
ciphers, but they are all BIG when space is tight.)
But - it would be nice to provide a way to test ciphers.
For C it could be done by #include'ing the file with the cipher, provided it
defined a few things
#define cipher_keybits 56
#define cipher_blocksize 64
void cipher_key(char *p)
void cipher_e(char *buffer)
void cipher_d(char *buffer)
that would fit almost anything (like DES for the above), and a few tools
could be found/fitted/written to help everybody.
/Kasper
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Cipher Contest
Date: Fri, 17 Mar 2000 23:41:38 GMT
In article <N_xA4.12245$[EMAIL PROTECTED]>, "Kasper Pedersen"
<[EMAIL PROTECTED]> wrote:
>
>"Adam Durana" <[EMAIL PROTECTED]> wrote in message
>news:55vA4.72$[EMAIL PROTECTED]...
>>... Also we would need some sort of speed or
>> maximum rounds requirement, so people could not submit ciphers with 1024
>> rounds. Maybe we could set the maximum rounds to 16? Or should there be
>a
>> speed requirement? I think a speed requirement would be much more
>difficult
>> to decide on, so I say there should be a maximum rounds requirement.
>>
>....
>> The "reasonable resource requirements" is needed so people can't submit
>> ciphers that use huge amounts of memory, disk etc. I think it would be
>> unfair to allow people to submit ciphers were the resource requirements
>are
>> unreasonable. This will have to be done on a case to case basis unless we
>> want to set a maximum memory requirement.
>
>Reasonable, but it would proper to allow exceptions, providing that there
>was a reason to do so, and that they are explained: Such as if someone
>submitted a cipher that would run under really extreme size constraints,
>he/she should be allowed to use a large number of rounds if he can tell why.
>
>(that's the category I'd be targeting. There are plenty of high performance
>ciphers, but they are all BIG when space is tight.)
>
>But - it would be nice to provide a way to test ciphers.
>For C it could be done by #include'ing the file with the cipher, provided it
>defined a few things
>#define cipher_keybits 56
>#define cipher_blocksize 64
>
>void cipher_key(char *p)
>void cipher_e(char *buffer)
>void cipher_d(char *buffer)
>
>that would fit almost anything (like DES for the above), and a few tools
>could be found/fitted/written to help everybody.
>
>/Kasper
>
I think it would be fair to have a open catagorey where one is allowed
to let the block size be the size of the file to be encrypted.
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***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Fri, 17 Mar 2000 15:59:06 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Jerry Coffin wrote:
> > A strictly conforming program can't produce output that depends on
> > anything that's implementation defined, unspecified or undefined.
> > In C, anytime you write something to a file, you get results that
> > are implementation defined, so a strictly conforming program can't
> > write to a file.
>
> No. Implementation-defined behavior means that the implementor
> makes a choice from specified alternatives and documents which
> choice was made. Normal use of standard I/O facilities does not
> invoke implementation-defined behavior.
Yes it does. Anytime you write to a file, you invoke implementation
defined behavior. If you write to a text file, characters may be
added, altered or deleted. IOW, basically everything about the
output you produce is implementation defined.
If you write a binary file, an implementation-defined number of nulls
will be added to the end of what you write.
In short, there's no way to write anything to a file without
implementation-defined behavior getting involved. If you were to say
that in the case of a binary file that part that's implementation
defined doesn't matter to most people most of the time, I'd agree.
If you were to say that most of the time what happens with text files
is pretty much what people expect, I'd agree to that as well. In
both cases, however, the output produced DOES depend on
implementation-defined behavior, so no program that does either is
strictly conforming.
> (There *are* several implementation-defined aspects of I/O, but
> most programs don't depend on them.)
I'm not convinced. Rather the contrary, I don't see any way for a
program to do ANY output without using implementation-defined
behavior. Writing to any file, and reading from text files are
clearly implementation defined.
That leaves reading from a binary file as the sole possibility for
portable I/O. The problem here is that you first have to open the
binary file, and to do that you have to specify its name, and the
strings you can sucessfully pass to fopen as file names are
implementation defined.
In addition, the name has to come from somewhere: if it's a string
literal, there's an implementation-defined mapping from the source
character set to the execution character set. If you read it from
the user, that would be via stdin, a text file, so the input has been
altered in an implementation-defined manner before you see it. If
you try to use a command-line argument, the implementation may have
mapped all characters to lower-case before you saw them. If you try
to use getenv, the set of names and methods of altering the
environment are implemntation-defined. You could use tmpnam to get a
name for the file, but of course other than being different from any
existing file, the name it'll give you isn't portable (and probably
couldn't be, since the set of strings you can sucessfully pass to
fopen isn't portable).
If you're willing (for the moment) to ignore the implementation
defined number of nulls appended to a binary file, there's ONE way
you can do I/O in an otherwise strictly conforming program: you can
use tmpfile to create a file for you, and you can write stuff out to
it and later read it back in.
Even this has a problem though: it's implementation-defined whether
that file will be removed if your program ends abnormally.
Unfortunately, if your program ends normally (returns from main or
calls exit) it passes back a value that's interpreted in an
implementation-defined manner. So, you can't exit either normally or
abnormally, leaving only one option: when you're done doing other
things, you get to sit in an infinite loop, and you can't even call
sleep() in it to keep from wasting all the CPU time.
> > you can isolate the system-specific stuff by itself all right,
> > but it ends up as about 90% of the program in most cases.
>
> Funny, it ends up as practically 0% in the code I've been writing
> recently, which runs on several different hosted environments,
> DSPs, and embedded processors.
>
> > If you need a reasonably modern UI, you usually end up
> > with a LOT of non-portable code to implement it.
>
> There are portable solutions to the "every platform has its
> own GUI" issue, but if you have a substantial algorithm to
> implement, e.g. encryption, it should be developed independently
> of the GUI code anyway, for reasons of functional cohesion.
Of course. Now, consider PGP as an example of a complete system.
The last time I looked, it was a multi-megabyte download. Even when
supporting a half dozen different algorithms or so, it's hard to
imagine the encryption and decryption code exceeding a couple of
hundred kilobytes at VERY most. By my figuring that puts the core
code as a single-digit percentage of the entire system. An otherwise
vaguely similar system that didn't use PK encryption (with its
attendant big-number library) could quite conceivably end up with the
encryption being only a fraction of one percent of the whole...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
** 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
******************************
