Cryptography-Digest Digest #168, Volume #11 Sun, 20 Feb 00 11:13:01 EST
Contents:
Re: Is Phi perfect? (Frank the_root)
Re: OAP-L3 Encryption Software - Complete Help Files at web site (lordcow77)
Re: OAP-L3 Encryption Software - Complete Help Files at web site (lordcow77)
Re: NSA Linux and the GPL (John Savard)
ISIT2000 -crypto (Quisquater)
Re: NIST publishes AES source code on web (John Savard)
Re: Biggest keys needed (was Re: Does the NSA have ALL Possible PGP keys?) (David A
Molnar)
Re: Using virtually any cipher as public key system? (David Hopwood)
Re: EOF in cipher??? (David Hopwood)
Re: EOF in cipher??? (David Hopwood)
Re: EOF in cipher??? (David Hopwood)
----------------------------------------------------------------------------
From: Frank the_root <[EMAIL PROTECTED]>
Subject: Re: Is Phi perfect?
Date: Sun, 20 Feb 2000 14:24:53 GMT
Xcott Craver left in some server logs :
>
> Frank the_root <[EMAIL PROTECTED]> wrote:
> >Hi,
>
> Hi, Frank the Root,
>
> >I always thought that the Euler's Phi fonction ( Phi(n) ) was the
> >fonction that gives the number of numbers relatively prime to n and
> >smaller than n by the multiplication of each primes factors of n reduced
> >by one.
>
> That's not how Phi(n) is defined.
>
> When n is a product of distinct primes pq (as occurs in RSA,)
> it is true that Phi(n) = Phi(pq) = (p-1)(q-1). However, this
> is a special case: in general, Phi(n) is defined as
>
> Phi(n) = n * (1 - 1/p)(1 - 1/q)(...)
>
> where p,q,... are the distinct prime factors of n. So:
>
> >For exemple: Let's determine the number of numbers relatively prime to
> >125: 125 = 5³, so we can see that at each 5 numbers, 4 of them are
> >relatively prime to 125. 125 × (5/4) = 42 != (5-1)(5-1)(5-1)
>
> Phi(125) = 125*(1-1/5) = 125*(4/5) = 100.
>
> >Phi(9) (3-1)(3-1) != 6
>
> Phi(9) = 9*(1-1/3) == 6
>
> >Phi(16): (2-1)(2-1)(2-1)(2-1) != 8
>
> Phi(16) = 16*(1-1/2) == 8
>
> >Phi(49): (7-1)(7-1) != 42
>
> Phi(49) = 49*(1-1/7) == 42
>
> >Frank
> -Xcott
Thanks, your exemple is really the most "visual" one. Thanks to all.
Frank
--
Ceux qui rêvent le jour savent des choses qu'ignorent ceux qui rêvent la
nuit.
------------------------------
Subject: Re: OAP-L3 Encryption Software - Complete Help Files at web site
From: lordcow77 <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.privacy
Date: Sun, 20 Feb 2000 06:37:55 -0800
Actually, most educated people knew that the Earth was spherical
when Columbus initiated his voyage. They did underestimate the
size of the world, thus allowing the expedition to be funded in
the first place.
* 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: OAP-L3 Encryption Software - Complete Help Files at web site
From: lordcow77 <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.privacy
Date: Sun, 20 Feb 2000 06:49:35 -0800
In article <[EMAIL PROTECTED]>, Anthony Stephen
Szopa <[EMAIL PROTECTED]> wrote:
>Obviously you claim to be unimpressed with my random number
generator
>and the processing done on this output to generate the OTP
files in
>OAP-L3 encryption software.
>
True; why use your PRNG when there are others that have
withstood far more attention (ie. RC4, SEAL)?
>Are you also saying that the OTP file management used in the
software
>is also worthless?
>
>Let's say you use your own random numbers and just use OAP-L3
to
>encrypt and manage your own OTP files. Are you saying no one
should
>do this because you merely say so with no supporting arguments?
Yes. Your user interface looks like it was designed by a person
who has no conception of GUI design. It does not appear to be
event-based at all, as it is centered on a series of uni-modal
dialog boxes. There are no "wizards" for novice users and no
multi-document interface system for more advanced users.
>
>What about the utility files included with the software? You
are
>saying that it should be of no interest to anyone to have a
utility
>program to look at a random number file and provide them with a
>frequency for each random number in the file?
#include <...>
int main(void)
{
FILE *fin;
struct stat fs;
int arr[256];
int fsize;
int i;
char c;
fin=fopen("foo","rb");
stat("foo",&fs);
fsize=fs.st_size;
for(i=0;i<255;i++){arr[i]=0};
for(i=0;i<fsize;i++){
fread(&c,1,1,fin);
arr[c]++;
}
for(i=0;i<255;i++){
printf("I=%d, n=%d\n",i,arr[i]);
}
return EXIT_SUCCESS;
}
>
>Do you think no one should be interested in a utility program
that
>will read a file in binary and output the ASCII decimal
equivalent
>for each character?
#include <...>
int main(void)
{
FILE *fin;
struct stat fs;
int fsize;
int i;
char c;
fin=fopen("foo","rb");
stat("foo",&fs);
fsize=fs.st_size;
for(i=0;i<fsize;i++){
fread(&c,1,1,fin);
printf("%c",c);
}
return EXIT_SUCCESS;
}
>
>Do you also think that no one should be interested in a utility
>program that will overwrite a file completely where each BIT is
>overwritten first with one's (every byte to 11111111) and then
the
>entire file is overwritten again with zeros (every byte to
00000000)
>to effectively wipe out any trace of the original data
contained in
>the file?
#include <...>
int main(void)
{
FILE *fin;
struct stat fs;
int arr[256];
int fsize;
int i;
char c;
stat("foo",&fs);
fin=fopen("foo","wb");
fsize=fs.st_size;
c=0xff;
for(i=0;i<fsize;i++){
fwrite(&c,1,1,fin);
}
fclose(fin);
fin=fopen("foo","wb");
c=0x00;
for(i=0;i<fsize;i++){
fwrite(&c,1,1,fin);
}
fclose(fin);
return EXIT_SUCCESS;
}
>
>Damn, nearly everyone in this news group must be shaking their
heads
>in awe for your awesome mental powers to know what they should
NOT
>have and what they should think yet without offering one shred
of
>factual support for your position regarding OAP-L3.
>
I'm certainly shaking my head, but for a different reason.
>Hallelujah!
>
>
Indeed.
* 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] (John Savard)
Subject: Re: NSA Linux and the GPL
Date: Sun, 20 Feb 2000 14:43:50 GMT
On Sun, 20 Feb 2000 10:26:17 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote, in part:
>Yes: The Linux kernel doesn't have the infrastructure necessary
>to support MLS operation.
Well, one can always add things to the kernel as well.
However, MLS is very demanding, and might well benefit from hardware
features beyond those on an ordinary PC, and might well be easier to
implement by writing a new operating system from the ground up than
trying to add it to Linux.
Doubtless, one could add a sort of MLS to Linux with a few changes to
the kernel - add a security level attribute to each file, keep track
of when a file is "contaminated" by being written to by a program that
also read from one of a higher security level - but the ordinary
security mechanisms that keep users from reading each other's files in
Linux or other ordinary operating systems probably aren't strong
enough to make that more than pretending to provide MLS.
------------------------------
From: Quisquater <[EMAIL PROTECTED]>
Subject: ISIT2000 -crypto
Date: Sun, 20 Feb 2000 16:28:45 +0100
Cryptography I
A Simple and Efficiently Verifiable Characterization of the
Possibility of
Information-Theoretic Key Agreement Secure Against Active
Adversaries (310)
Stefan Wolf
The Strong Secrecy Capacity and its Equality to the
Wyner-Csiszar-Körner Secrecy
Capacity (308)
Ueli Maurer, Stefan Wolf
Information-Theoretic Analysis of Information Hiding (669)
Pierre Moulin, Joseph A. O'Sullivan
Information-Theoretically Secure Keyless Authentication (61)
Valeri Korjik, Maxim Bakin
Cryptography II : Watermarking
Identification in the Presence of Side Information with Application
to Watermarking (352)
Neri Merhav, Yossef Steinberg
Quantization Index Modulation: A Class of Probably Good Methods for
Digital
Watermarking and Information Embedding (460)
Brian Chen, Gregory W. Wornell
Relationship between Quantization and Distribution Rates of
Digitally Watermarked Data
(190)
Adrian Papamarcou, Damianos Karakos
On the Gaussian Watermarking Game (211)
Amos Lapidoth, Aaron Cohen
Cryptography III
The simple ideal cipher system (112)
Boris Ryabko
Better than "Optimum" Homophonic Substitution (558)
Valdemar C. da Rocha Jr., James L. Massey
Watermark Codes: Reliable Communication over Insertion/Deletion
Channels (245)
Matthew C. Davey, David J.C. MacKay
A Calculus of Conditional Independence and ist Applications in
Cryptography (637)
Ueli Maurer
Cryptography IV
Global Broadcast by Broadcasts Among Subsets of Players (636)
Matthias Fitzi, Ueli Maurer
Performance of a Secure Wireless Transmission Method (551)
Havish Koorapaty, Amer Hassan
A New Identity-based Conference Key Distribution Scheme (91)
Sheng-bo Xu, Henk van Tilborg
An Information Theoretic Model for Distributed Key Distribution
(171)
Carlo Blundo, Paolo D'Arco
Cryptography V
Traitor Traceable Signature Scheme (278)
Yyuji Watanabe, Hideki Imai
An Efficient Traitor Tracing Scheme for Broadcast Encryption (289)
Maki Yoshida, Toru Fujiwara
Inherently Large Traceability of Broadcast Encryption Scheme (634)
Kaoru Kurosawa, Takuya Yoshida, Yvo Desmedt
Reducing String Oblivious Transfer to Universal Oblivious Transfer
(311)
Stefan Wolf
Cryptography and Coding I
Fourier Spectrum of Optimal Boolean Functions via Kasami's
Identities (223)
Pascale Charpin, Anne Canteaut, Claude Carlet, Caroline Fontaine
A Construction of Resilient Functions with High Nonlinearity (259)
Enes Pasalic, Thomas Johansson
On the Structure and Numbers of Higher Order Correlation-Immune
Functions (58)
Yuriy Tarannikov
Large Weight Patterns Decoding in Goppa Codes and Application to
Cryptography (221)
Pierre Loidreau
Cryptography and Coding II
Theoretical Analysis of a Correlation Attack based on Convolutional
Codes (256)
Frederik Jönsson, Thomas Johansson
Compared Performance of Fast Correlation Attacks on Stream Ciphers
(222)
Anne Canteaut, Michael Trabbia
Novel Fast Correlation Attacks via Iterative Decoding of Punctured
Simplex Code (690)
Miodrag J. Mihaljevic, Marc P.C. Fossorier, Hideki Imai
Using Low Density Parity Check Codes in the McEliece Cryptosystem
(567)
Chris Monico, Joachim Rosenthal, Amin Shokrollahi
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST publishes AES source code on web
Date: Sun, 20 Feb 2000 14:55:27 GMT
On Sat, 19 Feb 2000 12:28:35 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>I must logically conclude that AES is
>in fact NOT a strong crypto.
Actually, although that might seem like a sensible conclusion to make
at first glance, it is a sufficiently unlikely conclusion that I think
one must take the time to consider other alternatives.
The AES algorithms have been freely published worldwide.
Even in Cuba, North Korea, Libya, and so on, there are people who know
how to program computers. Sure, crypto algorithms are finicky, but
they're really not all that hard to program.
Thus, if subroutines that perform strong symmetric crypto algorithms
are really a worry for the NSA, their worries are profoundly perverse
and irrational.
The alternative is that they're worried about something *else*.
That there is a certain class of cryptographic program that would be a
serious concern to the NSA were it to become commonly available...but
the NSA can't say in public exactly what that class consists of, as
doing so would
a) just encourage somebody to write one, and
b) give away some inside knowledge about the real world of crypto.
(The other possibility is that the FBI and the Justice Department are
behind all the crypto paranoia, and the NSA is just trying to quietly
be a useful government department...one might cite Stewart Baker as a
disproof of this thesis in its total form, but it may have partial
applicability.)
For example, in practice it's all very well to share a secret key that
you have exchanged in person with one friend - but for serious use of
encryption, good key management is essential. Oh, I know that
public-key encryption, combined with key certificates, seems to go a
long way towards solving this, but there may well be more to it than
that.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Biggest keys needed (was Re: Does the NSA have ALL Possible PGP keys?)
Date: 20 Feb 2000 15:20:52 GMT
[EMAIL PROTECTED] wrote:
> I thought that the impact of QC was much greater than is suggested in
> Trevor's post - that is in theory, QC factoring of *very* large
> products of primes would be close to instantaneous.
Two distinct problems, two distinct impacts of quantum computing as
currently understood :
* Factoring large products of two primes.
Peter Shor's paper showed a way to do this in a polynomial
number of steps on a quantum computer. The same paper also showed how
to find discrete logarithms for arbitrary elements quickly.
If a quantum computer is built and operates like the theory says it
will, this problem becomes easy.
Impact : RSA, Diffie-Hellman, and every public key cryptosystem
based on these problems dies a horrible death. I do not know if
elliptic curves save you, but I suspect that they do not.
Public-key cryptography starts looking for other, stranger
problems on which to base itself.
* Brute-forcing a cipher
You can cast this as a search problem. For an n bit key and a
ciphertext, you have 2^n possible keys. One of them produces the
correct plaintext. Which?
Assuming that you have some means of recognizing the plaintext,
this is an example of an NP-problem :
Checking the answer once you have it is easy.
Finding the answer is really hard.
Assuming you have no other insight (i.e. no cryptanalysis),
then you need to start trying all possible keys. On the average,
you will find the right one when you're halfway through. So
you expect to do 2^(n-1) decrypt and check operations.
Grover's algorithm on a quantum computer allows you to do the
same thing in sqrt(2^(n)) time, aka 2^(n/2) time. This is an
impressive speedup, but it can be defeated by doubling the
size of your key. For example, a 256-bit key will now require
2^(256/2) = 2^(128) time...which is still too much for most
people.
There have been papers which claim that Grover's algorithm is
optimal -- in the sense that no algorithm _without more
knowledge of the problem_ can do much better than this
sqrt(n) speedup. A quick search picked up this paper :
http://www.imada.sdu.dk/~u2pi/papers/BBHT98.ps
which in fact claims that Grover's algorithm is within %2.62
of being optimal. That sounds a little strange to me, but
I haven't read the paper yet.
Impact :
Assuming that your cipher is perfect, not much : just double
the size of the key and you will be fine. Existing ciphertext
may be a problem.
If your cipher isn't perfect, who knows? I don't know enough
about quantum computing to talk about what kinds of defects
would make it easier to analyse. Just keep in mind that
these proofs of optimality make some assumptions on what you
can and can not do with your quantum computer; assumptions which
a cryptanalyst likely won't be bound by.
------------------------------
Date: Sun, 20 Feb 2000 01:55:49 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Using virtually any cipher as public key system?
=====BEGIN PGP SIGNED MESSAGE=====
Mikko Lehtisalo wrote:
>
> Thank you, I got the picture.. Ah well, it was a nice dream :) Back to
> IDEA I guess. How much would you consider a safe keysize giving it was
> implemented right?
IDEA has a *fixed* key size: 128 bits (which I would consider safe).
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOK9JmDkCAxeYt5gVAQHdfwf/b4G3cVdX8aaE9EhlVkYRTKO6/7HXklus
eyh4JWG2o0N12Fm8Q3rpsxWo+AdU+jFhUI3SsTGxXhrjamFMeBSogrgXGSDE95om
dePD/5VDuXTBeqfR0wmJs3eKK+d8vu/v7JcBJ8/ClXLOIs21MAnsBO8VEmk4G8QQ
QP9gJe/pci5rbOkAStb/7yVN/sPnp+n6QB2lHy/emBmU0aHxdyd7sl+icFR8neQk
q/mVQjgqzT5CyktoljBBkcbmxCK+eeetut95rDWXjMm3ZXntUorHwNLjOW7qqzWZ
HJrMgDVwUl4OnWmtBCZwmXjZwdu9ZVEduKJCEDVrSdbtLVxJP+wSfQ==
=nvJ7
=====END PGP SIGNATURE=====
------------------------------
Date: Sun, 20 Feb 2000 03:14:12 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: EOF in cipher???
=====BEGIN PGP SIGNED MESSAGE=====
"Trevor Jackson, III" wrote:
> "Douglas A. Gwyn" wrote:
> > "Trevor Jackson, III" wrote:
> > > Mok-Kong Shen wrote:
> > > > I am ignorant of what the C standard specifies. Question: Does
> > > > 'binary' require the file to be multiple of words or just any
> > > > multiple of bytes will do? Thanks.
> > > Neither. The elements written to files are characters. Sometimes
> > > (usually) that means bytes.
> >
> > Wrong. Bytes are written to binary files, characters to text files.
>
> Interesting. Tell me, just how do they do that on a machine that doesn't
> _have_ bytes?
>
> Don't go so far out of your way to "correct" me that you end up asserting
> something completely stupid.
*All* machines that support C and its file I/O libraries use bytes, in the
sense that C programs running on that machine (and programs in other
languages with similar file semantics) are guaranteed to be able to write
sequences of 8-bit bytes - capable of representing integers from 0..255 -
to a file in binary mode and read them back again.
Note that this is true regardless of the size of char and unsigned char, or
the sizes of integers that can be manipulated by the processor(s), or what
character encoding(s) are supported by the C compiler and operating system.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOK9b1DkCAxeYt5gVAQEhNwf/e9guoJl0/bqW/EMnewyu3zJxMN3huMTE
dSVCMNoLDGc3/GraleeK7mN/o7Z55txSjhZfMpLmAFWZv6KsY1B3C/WgJ/WyRq9g
85BgQT5UU8zB96AEgyj7wvxETLBfd0ilaB+dqVkzOMO0By9GObcYZ4q3aSNXzqCj
CYRxi6M8/DcLZ5w1seOEaakKuOGJXdMb+A/QYa3Q1oiONHXsKMSyDRZRgycfekKk
RpoMOS55tLtuuNXOMvEMpBUv7md+fnSDIuSmCYYeHvQdSlru+vHdobDTgQCoB9Wc
u5Nn6tN2kCOfCqyBmfERR28RJRnQCWAhxvhbW8fYInp3NtugzSLVHA==
=ON7G
=====END PGP SIGNATURE=====
------------------------------
Date: Sun, 20 Feb 2000 04:26:44 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: EOF in cipher???
=====BEGIN PGP SIGNED MESSAGE=====
"Trevor Jackson, III" wrote:
> Mok-Kong Shen wrote:
> > Stephen Houchen wrote:
> >
> > > If you're programming in C, open the file as "binary" (mode "rb", for
> > > example).
> >
> > I am ignorant of what the C standard specifies. Question: Does
> > 'binary' require the file to be multiple of words or just any multiple
> > of bytes will do? Thanks.
The latter.
> Neither. The elements written to files are characters.
> Sometimes (usually) that means bytes.
The elements written to files in binary mode are required to be able
to represent the values 0..255, and are not required to be able to be
able to represent any other values. In that sense they are (always)
8-bit bytes.
Technically, it would be possible for a conforming C implementation to
map a binary file to a sequence of storage elements of size > 8 bits, but
even in that case, the specified abstraction is still a sequence of 8-bit
bytes. I.e. whenever the file is read back in binary mode by a C program
(or a program written in a language with similar file semantics, such as
C++, Java, etc.), the elements are only guaranteed to be read correctly
as 8-bit values.
This is not just a semantic issue: there are some standards which do use
sequences of characters (e-mail and Usenet messages, for example), as well
as those that use bytes (TCP/IP, ASN.1, etc.), and the differences are
quite significant.
It is implementation-defined what the maximum file length is, and whether
zero-length files exist.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOK9s8TkCAxeYt5gVAQFRLQgAwPNezg4eUX3uyZI42dlKRCvbmVwFOF4W
cqS4MqFxSpy++0G4C99Fnma1E1tSCOiYZe342HW++78M/BwuptnlyneJqrqd17Gm
mhVOgplUJU0PCV0iZb23gdF9llG2Lp0YwXVP1YjHD9UJP5mLqNFRIwzWi+3E2cIS
CQSPOAdx9exK7PINEPHDMdOBhi1WEpXtpnROE5u4pW0+HKHPFuB/lGbt8CZ51PkU
XfIiqiIjqT1BW3LQpVQByr6okRW4++THqtEnePNywso2i/tyWBZqKeauNbqzBBzp
3QTMiFnva0aHEH/n2lkaj8njgG1te1cUiOGf1DaA2uIsRZnzzd10Ng==
=P/V/
=====END PGP SIGNATURE=====
------------------------------
Date: Sun, 20 Feb 2000 04:31:29 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: EOF in cipher???
=====BEGIN PGP SIGNED MESSAGE=====
Runu Knips wrote:
> "Trevor Jackson, III" schrieb:
> > "Douglas A. Gwyn" wrote:
> > > "Trevor Jackson, III" wrote:
> > > > Runu Knips wrote:
> > > > > EOF works well, because EOF is defined to be -1, while all
> > > > > characters are returned as nonnegative values.
> > > > This is _completely_ off topic. But the last statement is
> > > > completely false. The signedness of characters is implementation
> > > > defined. Thus on some systems characters are signed.
> > >
> > > No, first of all you mean char type, not characters.
> > > Secondly, the standard I/O functions such as getc deal with
> > > the data as unsigned char. So long as sizeof(char) < sizeof(int),
> > > which is practically always the case, EOF (-1) can never result
> > > from inputting any data value, even when char is a signed type.
> > >
> > > Please stop giving bad C advice!
> >
> > You are out of line again. The original statement was that "all
> > characters are returned as nonnegative values". That statement was
> > false.
>
> That statement is true. It's exactly what the standard says.
Yes (characters returned from getc, that is).
> > And there are machines where EOf != -1 and some where sizeof(char) ==
> > sizeof(int). I've worked on them.
>
> That's both against the standard. ISO specifies that int must be at
> least 16 bit (i.e. it says short must be 16 bit, and sizeof(int) >=
> sizeof(short), which means int is also at least 16 bit). A character
> value, however, is the smallest type which has at least 7 bit.
No, this is wrong (apart from the second sentence).
unsigned char must be able to represent at least the values 0..255,
so it cannot be 7 bit. Also, the sizes of char and unsigned char could
be >= 16 bit, and equal to that of int.
However, on all machines, *it is only possible to rely on files being
able to represent sequences of unsigned 8-bit values*. Therefore, the
issue of whether putc(...) ever returns < 0 for a valid input character
would not arise in any well-designed system, regardless of the sizes
of int, char, and unsigned char, and however obscure or broken the C
implementation.
[Technically it might be possible to construct, perhaps using operating
system tools, a file containing elements that will be read from getc in
binary mode as values outside the range 0..255. However, since no sane
design would generate such files deliberately, it doesn't really matter
how this is interpreted, as long as the program doesn't do something
insecure as a result. Treating the first such element as equivalent to
end-of-file would be perfectly reasonable, as would taking the least
significant 8 bits.]
IOW, all of the following code snippets will work, regardless of the
compiler (although the first is probably the clearest in terms of style):
1. int c;
while ((c = getc(in)) != EOF) ...
2. int c;
while ((c = getc(in)) >= 0) ...
3. int c;
while ((c = getc(in)) >= 0 && c <= 255) ...
FWIW, the only other person who has consistently given sound advice and
error-free information in this subthread is Doug Gwyn. It's easy to see
how newbies could get into bad programming habits by listening to advice
given on Usenet.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOK9t7DkCAxeYt5gVAQHLhQf8DMeYnRjkF7WXa+xiSFHqFER+qIp7LN4k
YwjMcK8G14uaSrPJJAxjSNJobE+aj35hpe/yTHg46fEyanJU8OntWcPhMz0Vm++j
DAdYZ+EA1GkL8JTixq43Hd0hQxtDx7NqZZb2MeUxb7COj5PxT31K6p6jH2I2FmZ3
Orj0gQpNkw3B90TAn6ALE0iZtFNFeESU4rogw0WIuZ5UT0M3zM00y3jh/iRuus6J
FlpHR3KpmXFpXlCO4ItQiS/g/o7lftZBqJaCg6dD3FApMSMwXnf4LIGHnHV2R5Yz
d8kdX1VbPpftB/zP0FOXf0ZH8pz5MtfBERhfZ2NUTX3bqdS01shjlQ==
=Dy57
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
