Cryptography-Digest Digest #966, Volume #9 Sun, 1 Aug 99 18:13:03 EDT
Contents:
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
(Guenther Brunthaler)
Re: With all the talk about random... ("Trevor L. Jackson; III")
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
(Guenther Brunthaler)
Re: How Big is a Byte? (was: New Encryption Product!) ("Trevor L. Jackson; III")
Re: bits and bytes ([EMAIL PROTECTED])
Re: Intel 810 chipset security ([EMAIL PROTECTED])
Re: Another random question ([EMAIL PROTECTED])
Re: How to keep crypto DLLs Secure? (Dmitri Alperovitch)
Re: Americans abroad/Encryption rules? (JPeschel)
Re: bits and bytes
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
(John G Dobnick)
Re: Bad Test of Steve Reid's SHA1 ("Richard Parker")
Re: SCOTT19U CONTEST UPDATE (JPeschel)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Guenther Brunthaler)
Crossposted-To: alt.comp.lang.learn.c-c++,comp.lang.c++
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a
Byte?)
Date: Sun, 01 Aug 1999 20:14:48 GMT
On Sun, 01 Aug 1999 13:44:14 GMT, [EMAIL PROTECTED] wrote:
>> >C's char != byte.
>>
>> True in many cases, but not in C or C++. In both language
>specs, 'byte' means
>> 'char'.
>
>That's not true. There is no definition of 'byte' in ANSI C. sizeof()
>returns the length of 'chars' it requires to store the object.
It is. The ANSI-C specs clearly say that a 'char' has the size of
whatever an implementation considers to be a "byte".
However, I do not have access to the original ANSI-C specification,
and so my book on the subject may contain errors, as many books do.
But there are two arguments why a byte must not necessarily be 8 bits,
besides the others I have stated:
1. If it was that clear, no further discussion on the subject would
have been necessary.
2. Why do all the comm guys speak of "octets" rather than bytes, if it
really and undoubtedly were the same thing?
Greetings,
Guenther
--
Note: the 'From'-address shown in the header is an Anti-Spam
fake-address. Please remove 'nospam.' from the address in order
to get my real email address.
In order to get my public RSA PGP-key, send mail with blank body
to: [EMAIL PROTECTED]
Subject: get 0x2D2F0683
Key ID: 2D2F0683, 1024 bit, created 1993/02/05
Fingerprint: 11 71 47 2F AF 2F CD F4 E6 78 D5 E5 3E DD 07 B5
------------------------------
Date: Mon, 02 Aug 1999 15:55:56 -0400
From: "Trevor L. Jackson; III" <[EMAIL PROTECTED]>
Subject: Re: With all the talk about random...
Robert C. Paulsen, Jr. wrote:
> Herman Rubin wrote:
> >
>
> >
> > There are stochastic effects, due to imperfections and thermal
> > noise, which increase the lack of determinacy. If we roll the
> > die far enough, quantum indeterminacy in the actions of other
> > objects will introduce randomness.
> >
>
> That seems like a natural explanation to me too, but when I made
> such a suggestion in another thread a few weeks back several people
> replied saying essentially that ...
>
> a) There was no quantum indeterminacy involved in dice rolling, and
> b) quantum indeterminacy was not required to get true randomness
> from rolling dice.
>
> As far as I know, the only behavior in the universe known to
> involve true randomness is is from quantum effects.
>
> Other stochastic effects, chaos, complexity, etc. are just ways of
> describing or dealing with situations where we lack enough
> information to make predictions based on the underlying determinacy,
> even though this information is obtainable in principle.
This claim amounts to assuming the universe is newtonian. In fact there
is a limit to the amount of information about particle position and
momentum available to an observer. Beyond that limit you cannot, in
principle, measure.
A device that amplified below-the-limit effects, polarization for
example, to above the limit phenomena can be classed as random.
>
>
> It is not unheard of for quantum randomness to make itself known on
> a macroscopic scale -- a Geiger counter is the obvious example.
> Perhaps rolling dice is another example. I really don't know if the
> results of dice rolling actually is effected by quantum
> indeterminacy but it would be interesting to see a "proof" one
> way or the other.
>
> --
> ____________________________________________________________________
> Robert Paulsen http://paulsen.home.texas.net
------------------------------
From: [EMAIL PROTECTED] (Guenther Brunthaler)
Crossposted-To: alt.comp.lang.learn.c-c++,comp.lang.c++
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a
Byte?)
Date: Sun, 01 Aug 1999 20:14:49 GMT
On Sun, 01 Aug 1999 12:27:58 -0400, Martin Ambuhl
<[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>
>> That's not true. There is no definition of 'byte' in ANSI C. sizeof()
>> returns the length of 'chars' it requires to store the object.
>
>To avoid appearing a fool, it helps to not make flat statements that are
>completely untrue. They indicate not only a lack of knowledge but a
>reckless disregard for the truth. From the standard (ISO 9899:1990) we
>find the following definition that you just assured us does not exist:
>...
Thanks a lot, Martin!
This was just exactly the piece of information I was missing!
Greetings,
Guenther
--
Note: the 'From'-address shown in the header is an Anti-Spam
fake-address. Please remove 'nospam.' from the address in order
to get my real email address.
In order to get my public RSA PGP-key, send mail with blank body
to: [EMAIL PROTECTED]
Subject: get 0x2D2F0683
Key ID: 2D2F0683, 1024 bit, created 1993/02/05
Fingerprint: 11 71 47 2F AF 2F CD F4 E6 78 D5 E5 3E DD 07 B5
------------------------------
Date: Mon, 02 Aug 1999 15:46:51 -0400
From: "Trevor L. Jackson; III" <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Douglas A. Gwyn wrote:
> "Trevor L. Jackson; III" wrote:
> > Douglas A. Gwyn wrote:
> > > The real lack in C array indexing is a way to specify arbitrary
> > > upper/lower bounds, stride, etc. and let the compiler do the
> > > work to index storage efficiently. (One can do this with macros
> > > but why should we have to?) There is a new kind of array in C9x
> > > that better supports this stuff.
> > Why do you find arbitrary lower bounds unacceptable? It's simply
> > an offset to the index, or in C an offset to the base of the array.
> > Rather than have the compiler add the base offset to every index
> > expression why not simply subtract the offset value from the arrary
> > address?
>
> (1) I don't find arbitrary lower bounds unacceptable. I said that
> traditional C lacks a way to specify that.
>
> (2) Adding an offset to the base address (actually should be,
> subtracting the lower bound) creates undefined behavior when the
> result is not a pointer into the declared array nor the location
> just past the last element. "Numerical Recipes in C" made that
> horrible mistake, at least in the first edition, in an attempt
> to use C arrays as if they were FORTRAN arrays.
Thanks for the info. I guess this is an instance of Dickson's expert v
scholar. An expert knows everything about a topic that is worth knowing,
while a scholar knows everything that there is to know.
I ran into this problem, early validity checking, first on Burroughs
machines. It is still with us on x86 machines in the form of the segment
register validity checking when the register is loaded rather than when
it is used. I consider it a pain and strongly prefer deferred binding
and deferred consistency validation.
I suppose there's also the problem of partial address arithmetic where,
on a segmented machine, the compiler neglects to perform full address
arithmetic knowing, by way of a "memory model" that only intra-segment
calculations are necessary.
Good point.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: bits and bytes
Date: Sun, 01 Aug 1999 19:51:48 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> But char is not byte. Char is something different. Isn't it strange
to talk
> about byte and then use char as an example?
>
> And nobody sells stuff by Megaoctets. Or gigaoctets. And I haven't
seen
> anyone talking about kilooctet files.
>
> And still given the problems figuring out how much is one Megabyte I
still
> believe that the assumption that byte = 8 works better.
I agree. One poster said that 'byte' was invented by IBM in the 60's
(way before my time) so I will agree there. For the few people who
cling to byte = 12 bits or whatever... go for it. But in the rest of
the world ...
byte = 8 bits is pretty much understood by everyone. Even in
encyclopedias they list a byte as 8 bits. Anyways as my original post
said this is OT so if anyone has good sense please stop posting about
this.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Intel 810 chipset security
Date: Sun, 01 Aug 1999 19:53:35 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I would like to know what the thoughts on using of intel 810 chipset
for
> random number generator ? Will AMD be able to take part of this ?
>
They are closed door about the PRNG so I would leave it at that. It's
not worthy to use if no one else cna use it.
I think INTEL will keep a closed door on it (providing only binaries)
until they know they got a handle on it.
I would lone to see analysis of that and the PIII ID thingy. has
anyone written software yet to emulate the instructions and fake ids
yet?
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Another random question
Date: Sun, 01 Aug 1999 19:56:23 GMT
In article <7o1k35$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Herman Rubin) wrote:
> This may or may not work. It often depends on how the time is
> accessed and stored.
>
> In my opinion, a decent PRNG needs at least thousands of bits
> for its initialization, although it is possible that some very
> expensive ones might do well with a few hundred. This is not
> going to be found in the "random" part of the clock reading,
> or even in the entire clock reading, as there are less than
> 2^17 seconds in a day.
Most seeds using time-of-day are the 'srand(time(NULL))' which is tbe
number of seconds from 1970 (sometime). Like you said it's highly non
random.
BTW you can get by with say 80 bits of state if your generator is non-
linear enough (i.e it takes at least 2^80 steps to learn the seed).
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Dmitri Alperovitch)
Subject: Re: How to keep crypto DLLs Secure?
Date: Sun, 01 Aug 1999 20:46:45 GMT
>I have found many location offer strong crypto libraries, ofter in DLL
>format, for which I am very grateful. However I wonder about the
>prosibility of some someone who shouldn't get access actually getting
>access throught the weakness built into MS DLLs.
Obviously any machine code can be disassembled (whether it's
DLL, EXE, or other executable code) and your encryption routines can be
disabled. But that doesn't compromise the security of your encryption
algorithm. The attacker still will not be able to decrypt encrypted text
without access to encryption keys. It simply means that this particular
program that was "cracked" will not encrypt anything, but so what? The only
person who is going to suffer from this is the cracker and anyone who he
distributes it to (but you should already know better than download programs
from someone you don't trust).
Regards,
Dmitri Alperovitch
[EMAIL PROTECTED]
http://www.cdc.net/~dmitri/
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Americans abroad/Encryption rules?
Date: 01 Aug 1999 20:47:06 GMT
> [EMAIL PROTECTED] (Dmitri Alperovitch) writes:
>I'm not a lawyer, but it seems to me that if they let you export the
>software out of U.S. like that, they would have no legal power to stop
>you from distributing that software to anyone you wish to give it there
>(assuming that the program is freeware, of course)
I think the phrase "personal use" suggests that the US citizen doesn't intend
to distribute
the program, but only use it while abroad. You need an export license
to distribute crypto -- that's covered by the rest of EAR.
Why would anyone want to push their luck -- just to be rebellious?
Anyhow, the rule has been in affect since mid-Feb. of 1996.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: bits and bytes
Date: 1 Aug 99 20:09:03 GMT
Thomas Pornin ([EMAIL PROTECTED]) wrote:
: According to Douglas A. Gwyn <[EMAIL PROTECTED]>:
: > "char" type must be able to accurately represent EITHER 0..255 OR
: > -127..127
: I would like to insist on that point: the range is -127..127, not
: -128..127. This is for computers that store signed types with a sign
: bit and the absolute value; this was the case for the PDP-11 (I think,
: correct me if I am wrong).
The PDP-11 uses two's complement arithmetic like nearly all modern
computers, hence a signed char would contain numbers from -128 to 127.
The IBM 7090 is an example of a computer with a separate sign bit, but its
characters are only 6 bits long.
John Savard
------------------------------
From: [EMAIL PROTECTED] (John G Dobnick)
Crossposted-To:
alt.folklore.computers,alt.comp.lang.learn.c-c++,comp.lang.c++,microsoft.public.vc.language
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a
Byte?)
Date: 1 Aug 1999 21:42:14 GMT
Reply-To: [EMAIL PROTECTED]
>From article <[EMAIL PROTECTED]>, by [EMAIL PROTECTED] (Mr.
>Leo Yanki):
> [EMAIL PROTECTED] (Guenther Brunthaler) wrote:
>
>>... "byte" ... can have ANY number of bits
>
> A byte has exactly eight bits and can have 256 different values. A general
WRONG!
> term for any size collection of bits is "binary number". Please don't
> attempt to confuse people by trying to spread your personal redefinitions
> of commonly used technical terms.
> --
UNIVAC 1100 machines (and their successors, Unisys 2200's) have a
number of _different_ "byte sizes". Choose bit-widths of 6, 9, 12,
18, or 36. (36-bits being the _word_ length of the machine -- and
this _is_ a _word_ machine.) Probably the most common "byte size"
used now is 9-bit bytes (with 512 distinct values), since this is the
smallest natural machine-addressable quantity that will hold an ASCII
character.
The term "character" is pretty much interchangeable with "byte"
in this environment.
Repeat after me: "A byte is NOT (necessarily) 8-bits!"
--
John G Dobnick "Knowing how things work is the basis
Information & Media Technologies for appreciation, and is thus a
University of Wisconsin - Milwaukee source of civilized delight."
[EMAIL PROTECTED] ATTnet: (414) 229-5727 -- William Safire
------------------------------
From: "Richard Parker" <[EMAIL PROTECTED]>
Subject: Re: Bad Test of Steve Reid's SHA1
Date: Sun, 01 Aug 1999 21:31:57 GMT
> So far no-one has told me what LITTLE_ENDIAN does. Does it refer to
> one of the alternate methods referred to as 7. and 8. on the NTIS site
> (thanks to Jerry Coffin for that URL)? I would assume not since, as D.
> L. Keever mentions, you do need to define LITTLE_ENDIAN to get the
> right digest. Or does it refer to the "technical correction" that
> generated SHA-1 (FIPS 180) in the first place? Something else? Just
> curious.
big-endian vs. little-endian
Big-endian and little-endian are terms that describe the order in
which a sequence is stored. Big-endian is an order in which the
"big end" (most significant value in the sequence) is stored first.
Little-endian is an order in which the "little end" (least
significant value in the sequence) is stored first. Consider a
sequence of bytes with increasing memory addresses ABCD, to be
interpreted as a 32-bit word with numerical value N. In
little-endian, the byte with the lowest memory address (A) is the
least significant byte: N = (2^24)D + (2^16)C + (2^8)B + A.
In big-endian, the byte with the lowest address (A) is the most
significant byte: N = (2^24)A + (2^16)B + (2^8)C + D.
IBM's 370 computers, most RISC processors, and Motorola
microprocessors use the big-endian byte ordering. On the other
hand, Intel processors and DEC Alphas are little-endian.
Big-endian byte ordering is the byte ordering used in TCP/IP,
the protocol suite that forms the basis of the Internet, therefore
you sometimes see big-endian byte ordering called "network byte
order."
Note that within both big-endian and little-endian byte orders, the
bits within each byte are big-endian. That is, there is no attempt
to be big- or little-endian about the entire bit stream represented
by a given number of stored bytes. While it is possible to be
big-endian or little-endian about the bit order, CPUs are almost
always designed for a big-endian bit order. In data transmission,
however, it is possible to have either bit order.
The names big-endian and little-endian are drawn from the fued
between the two mythical islands Lilliput and Blefescu in Jonathan
Swift's novel "Gulliver's Travels." In the novel the two islands
disagree over the correct end (big or little) at which to crack an
egg.
-Richard
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: SCOTT19U CONTEST UPDATE
Date: 01 Aug 1999 21:16:33 GMT
>[EMAIL PROTECTED]
>For those who lack the ablility to solve hard problems the Gloat
>contest is down to 40 bits even Dave or Little Tommy boy ought
>to be able to handle it by know by just doing a boring search.
>
I know, I know -- gee, I sound like some of my students...
Anyway, Dave, and interested others, I've updated my page
to include this month's "gloat" clue, too.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
** 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
******************************
