Cryptography-Digest Digest #965, Volume #9 Sun, 1 Aug 99 16:13:04 EDT
Contents:
Re: Americans abroad/Encryption rules? (Dmitri Alperovitch)
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
(Martin Ambuhl)
Re: With all the talk about random... (Herman Rubin)
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
(Guenther Brunthaler)
Help please (WWI/WWII ciphers) ("Mike Blais")
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
(Daniel W. Johnson)
Re: With all the talk about random... ([EMAIL PROTECTED])
How to keep crypto DLLs Secure? (James Thye)
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
(Peter Seebach)
Re: bits and bytes (Gergo Barany)
Re: Math ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Dmitri Alperovitch)
Subject: Re: Americans abroad/Encryption rules?
Date: Sun, 01 Aug 1999 17:39:05 GMT
>Bill, that's strange. When was the "personal use exemption" taken off the
>books?
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)
Regards,
Dmitri
------------------------------
From: Martin Ambuhl <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers,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 12:27:58 -0400
[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:
3 Definititions and conventions
3.4 byte. The unit of data storage large enough to hold any member of
the basic character set of the execution environment. It shall be
possible to express the address of each individual byte of an object
uniquely. A byte is composed of a contiguous sequence of bits, the
number of which is implementation-defined. The least significant bit is
called the low-order bit; the most significant bit is called the
high-order bit.
--
Martin Ambuhl [EMAIL PROTECTED]
__________________________________________________________
Fight spam now!
Get your free anti-spam service: http://www.brightmail.com
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: With all the talk about random...
Date: 1 Aug 1999 13:53:36 -0500
In article <[EMAIL PROTECTED]>,
Robert C. Paulsen, Jr. <[EMAIL PROTECTED]> 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.
>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.
I have no idea how complicated the quantum-mechanical interactions
of a die rolling would be, or even the classical situation going
down to the atomic level, but it would certainly require major
simplifications to get anything which could be analyzed.
I was once told by a physicist that if one dropped a perfectly
elastic steel ball on another identical one from its height, the
expected number of bounces before it fell off would be about 3.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: [EMAIL PROTECTED] (Guenther Brunthaler)
Crossposted-To: 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: Sun, 01 Aug 1999 18:08:12 GMT
On Sat, 31 Jul 1999 06:33:24 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>Guenther Brunthaler wrote:
>> Well, "byte" is simply short for "binary term" ...
>
>What documentation do you have for that? I've been in computing
>for a *long* time, and have never before encountered that.
Really, no idea - perhaps in school? But let's try Alta Vista:
byte near "binary term"
Hmm, 36 matches. "http://teamcia.com/webworkshop98/terms.htm" looks
promising. And there it is: "byte n. Abbreviated B. Short for binary
term. A unit of data, today almost always consisting of 8 bits..."
God, I love search machines!
>As one of the authors of the specification for <inttypes.h> and its
It then is a HONOUR and relief for me to be able to congratulate you -
and the other members of the committee - for trying to establish such
a fine and useful piece of work as a public standard! Always go on
like this!
>subset <stdint.h>, I need to say that
What, there is also another such fine header file? I would really like
to see!!! Where can I get a copy?
>it is an exaggeration to claim
>that it solves *all* such problems.
Mostly depends on how narrow one defines "such".
The most prominent problem not touched by inttypes.h undoubtedly is
endianness.
>And if your C implementation does not (yet) provide
Unfortunately. (Visual C.)
>these headers, they are not hard to concoct yourself.
As I did. However, there are some things I did not understand fully. I
hope you don't mind if I take the opportunity and ask you right here:
1. my copy of inttypes.h does NOT define constants such as
UINT_LEAST8_MAX. Is this correct?
2. Definitions such as UINT_FAST8_C() are also missing?
3. (Unrelated to inttypes.h) The ANSI-C standard requires modulo-2
arithmetic on integers and that an 'int' has at least 16 bits. Does
the standard also include a mandatory 2's complement representation of
negative integers, and does it require that the value 65535 can be
represented in an 'int' (i. e. all 16 bits are also available for the
value to be stored)?
>> It also defines integers of a given minimum size or the fastest
>> integer types that can contain at least a specific number of bits.
>
>Not precisely -- the "fast" types aren't always the fastest, just
>a good stab at picking such types for general use. One might get
>faster execution with some other type, depending on the architecture
>and application.
Ummmm. But it at least my general assumption correct, that processing
should be done with the "fast" types unless memory requirements do
matter, in which cases the "least" types should be preferred?
>We also decided that the "exact" types such as int16_t shall use
>twos-complement representation and contain no padding bits.
Which undoubtedly increases the usefulness of such types for all
practical purposes I can think of! Bravo!
>an implementation doesn't provide such a type, that's okay; if
>your code depends on these properties then it should test a macro
>to detect when the type is not supported.)
That's exactly the way I used to interpret it.
>You probably meant (a+b)&0xFFFF.
Yes, and it's exactly the same, because "+" has a higher operator
precedence than "&", and so the parentheses are not really necessary
in this case.
>I would expect a 16-bit
>implementation to optimize away the unnecessary mask.
>There is no need for a macro, although it might be helpful
>simply to give a name to the masking operation (and to
>centralize its definition).
This is one reason. Also, it may help compilers that are too dumb to
optimize such expressions. Unfortunately, not all compilers optimize
to the same extent as programmers might assume.
But thanks to the power of inttypes.h, macros like the sample macro
can be defined easily at any time if required!
>> And if you happen to know someone who is a member of the ANSI/ISO or
>> other standards committee involved in standardizing C/C++, please
>> encourage him or her to consider suggesting inttypes.h for inclusion
>> into the standard!
>
>We have already done that.
Thanks a lot for doing that!
And - did they say anything? Is Microsoft also a member of those
committees?
I would really like to experience a windows.h file one day that uses
inttypes.h-style definitions in the primary API definitions
OH, DO I LONG FOR THAT DAY TO COME!
(Especially in expectation of Win64! And who knows that 64 bit
processors are the ceiling? Perhaps 128 or even 256 bit word machines
will be common one day.)
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
------------------------------
From: "Mike Blais" <[EMAIL PROTECTED]>
Subject: Help please (WWI/WWII ciphers)
Date: Sun, 01 Aug 1999 18:53:30 GMT
If anyone can help me with this it would truly be appreciated, by me and my
girlfriend have spent far too much time on this and are ready to give
up(this isn't really our type of stuff).
We have a package (newsletter) that has a code hidden in it, and our only
hint was that it was a code stolen from the Germans in the war(don't know
which war). Unless the code is actually hidden in the text this is what we
believe is the code: 223,172,926 paragraph 2 section (b) and a
page later
89,254,167 section (b) paragraph (iii)
We don't know if the section/paragraph numbers mean anything but I figured
they should be included.
So what I have is this 223 172 926 89 254 167 and the answer key is like
this
---- ------- ---------- --- ----
As far as I found on the web the only number for letter cipher was the
Zimmerman Telegraph, but the key I found was in German. Also there are more
answer spaces than numbers and the only numbers in the rest of the package
are telephone numbers(all real)
Any tips from whether we're on the right track to a solution would be great.
Mike Blais
Kirsten Johnston
[EMAIL PROTECTED]
Port Coquitlam BC
------------------------------
Crossposted-To: alt.folklore.computers,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?)
From: [EMAIL PROTECTED] (Daniel W. Johnson)
Date: Sun, 1 Aug 1999 13:48:05 -0500
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > ... A megabyte is 2^20 bytes so megabyte is not always 2^23 bits?
>
> "Megabyte" is ambiguous even if you mean 8-bit bytes. Some people
> mean 2^23 bits, while others mean 2^9*5^6 bits.
And some mean 2^16*5^3. (1.44 megabyte floppy, anyone?)
--
Daniel W. Johnson
[EMAIL PROTECTED]
http://members.iquest.net/~panoptes/
039 53 36 N / 086 11 55 W
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: With all the talk about random...
Date: Sun, 01 Aug 1999 19:48:04 GMT
In article <[EMAIL PROTECTED]>,
"Robert C. Paulsen, Jr." <[EMAIL PROTECTED]> wrote:
> 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.
>
> 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.
Nothing is truly random though. Why do you think we have laws of
physics and developing laws of quantum mechanics? Just cuz you can't
explain something doesn't mean it's random.
I think there is a misconception. A truly random number just occurs.
Nothing dictates what it will be or when it will be (such as counting
or detecting alpha particles). A unpredictable number (such as the
various methods on real life sources) is just that but not really
random.
If you could look at a piece of amercium and see alpha particles leave
you could predict what your counter will produce, but since that's
believed to be difficult we assume it's 'random'. Simple as that.
I am no phyisic person so if some of my facts are off please note. But
the idea still remains. Nothing is truly random.
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] (James Thye)
Subject: How to keep crypto DLLs Secure?
Date: Sun, 1 Aug 1999 15:47:00 -0400
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.
There are utilities out there (Dumpbin is provided with windows) to give
the user (usally a programmer) information on the internal information of
a dll. Namely, what function names are in the Dll, what arguments do
they take, and what do they pass back to the caller.
So it should be easy for some hacker (term loosely used) to peek at the
dll, decide that it is crypto, and find his/her favorite compiler and
generate those functions which do as little as possible, or nothing.
Put more simply, I want to call three crypto Dll functions, CryptoSetKey,
CryptoEncrypt, and CryptoDecrypt, all of which take and return the
obvious arguments. The hacker discovers these three functions and
rewrites CryptoEncrypt and CryptoDecrypt to simply return the passed
parameter. Alternatively, the hacker could write into Dll code that
states "Take the info about to be encrypted, and write that plaintext
info in some remote part of the hard drive" (Especially it we are
encrypting credit cards). Hacker comes back in a couple of weeks, finds
the text file, and is very happy.
Currently I am countering this by encrypting the data first with a
rotating xor string (yes I know the problems of OTPs), then encrypting
that with a stream cipher, *then* I send it to be seriously encrypted by
the DLL, and encrypt it one again with a different stream cipher (and
different key) the result passed back by the stream cipher.
There are problems with this also. The ciphers I am using are a lot less
powerful than the DLL functions (or I wouldn't be using the DLL in the
first place). This is still vulnerable to the attack stated above, with
the addition that now the hacker has to do a little bit of cryptanalysis.
Therefore still not very secure.
I realize that only 1 user in a 100 will turn out to be an active/passive
attacker of the crypto. That 1 person in a hundred however can cause a
huge amount of trouble once let loose with proprietary inforation.
Otherwise, why are password files always encrypted (since hardly anyone
ever looks at them)?
The only sure way to have moderate crypto security is to have the crypto
directly inside the compiled EXE, and not within the DLL. I would
appreciate comments.
Thanks
[EMAIL PROTECTED]
------------------------------
Crossposted-To: alt.folklore.computers,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?)
From: [EMAIL PROTECTED] (Peter Seebach)
Date: Sun, 01 Aug 1999 19:12:49 GMT
In article <7o1ivd$sd6$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>In article <6bMo3.168$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Peter Seebach) wrote:
>> In article <7o027o$u61$[EMAIL PROTECTED]>, <[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.
I can't remember whether ISO 9899:1990, Section 3, was in the original ANSI
spec, but as soon as ISO issued that spec, ANSI re-adopted it, and since then,
you've been wrong. 3.4 defines the term "byte".
-s
--
Copyright 1999, All rights reserved. Peter Seebach / [EMAIL PROTECTED]
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Will work for interesting hardware. http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
------------------------------
From: [EMAIL PROTECTED] (Gergo Barany)
Subject: Re: bits and bytes
Date: 1 Aug 1999 20:06:31 GMT
On Sun, 01 Aug 1999 15:44:52 GMT, Lincoln Yeoh
<[EMAIL PROTECTED]> wrote:
>On Sat, 31 Jul 1999 19:50:14 GMT, [EMAIL PROTECTED] wrote:
>>In C there are no standard bit sizes for any types. They must only
>>hold the required data ranges. A 'char' must hold at least -127 to 128
>>(or vice versa?), an int must hold at least -32767 to 32768, etc...
>>etc...
>
>But char is not byte. Char is something different. Isn't it strange to talk
>about byte and then use char as an example?
In C (and I assume C++, too), char *is* a byte. If someone has the
Standard handy, they can quote it; basically, it says that a byte is
sizeof char, and the sizes of all other types are integral numbers of
bytes. So if you use a 16 bit character set, a char and a byte are both
16 bits, at least in the context of C programming (even if the operating
system says otherwise).
Gergo
--
If you want to see useful Perl examples, we can certainly arrange to have
comp.lang.misc flooded with them, but I don't think that would help the
advance of civilization. :-)
-- Larry Wall in <[EMAIL PROTECTED]>
GU d- s:+ a--- C++>$ UL+++ P>++ L+++ E>++ W+ N++ o? K- w--- !O !M !V
PS+ PE+ Y+ PGP+ t* 5+ X- R>+ tv++ b+>+++ DI+ D+ G>++ e* h! !r !y+
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Math
Date: Sun, 01 Aug 1999 19:58:34 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (=?ISO-8859-1?Q?Jacques_Th=E9riault?=) wrote:
> In Bruce Schneier's 'Applied Cryptoghrapgy' second edition, third
> printing, he talk about RC4 complexity on page 398 first paragraph...
>
> "... RC4 can be in avout 2^1700 (256!x256^2) possiblestates: an
> enormous number. ..."
>
> The calculator that I have comes up with 5.62 E 511 for the above
> equation in parentheses.
>
> Even if you take into factor the bits of that 256 array it only comes
up
> to 3.23 E 616 2^2048 ( ie 2 ^ ( 256 * 8 ) ).
>
> Am I missing something here???
Yes you are. The RC4 sbox must form a permutation of 0..255 which
means it can be in 256! (2^1684) possible states. That is where you
are missing some numbers...
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.
------------------------------
** 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
******************************
