Cryptography-Digest Digest #978, Volume #9 Tue, 3 Aug 99 12:13:03 EDT
Contents:
Re: [Q] Why is pub key cert. secure & free from spoofing? ("Lyal Collins")
Storing keys (Atle Sandvold)
Re: bits and bytes ("Brian Gladman")
Re: Traffic flow confidentiality (Gabriel Belingueres)
Re: Help please (WWI/WWII ciphers) ("Dr Dude")
Re: CFB mode with same initialization vector ([EMAIL PROTECTED])
Re: Virtual Matrix Encryption ([EMAIL PROTECTED])
Re: the defintion of Entropy (Patrick Juola)
Re: [Q] Why is pub key cert. secure & free from spoofing? (Patrick Juola)
Re: Americans abroad/Encryption rules? (SCOTT19U.ZIP_GUY)
Re: Blowfish x86 assembler ([EMAIL PROTECTED])
Re: How to keep crypto DLLs Secure? ([EMAIL PROTECTED])
NORTON Diskreet Decrypt Help me ("Vasiliy Khalak")
Re: [Q] Why is pub key cert. secure & free from spoofing? (fungus)
DES crypt(3) ([EMAIL PROTECTED])
Re: Infallible authentication scheme ([EMAIL PROTECTED])
Re: Americans abroad/Encryption rules? (John McDonald, Jr.)
Re: PC Encrypt (fungus)
Re: With all the talk about random... (fungus)
Re: How to keep crypto DLLs Secure? (John McDonald, Jr.)
Re: the defintion of Entropy ("Tony T. Warnock")
Re: With all the talk about random... ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: "Lyal Collins" <[EMAIL PROTECTED]>
Subject: Re: [Q] Why is pub key cert. secure & free from spoofing?
Date: Tue, 3 Aug 1999 21:46:42 +1000
No reason oat all.
This is why you need identification and Public key to be presented to the CA
in person, though not necessarily at the same time, if a well designed
process.
If not, the certificates are real, but the names in them may not be, and in
some cases, definitely won't be.
The end result is that digital certificates today are mostly a waste of
time - unless some spends of LOT of money issuing certificates - around $40
in face to face counter time.
Jerome Mrozak wrote in message <[EMAIL PROTECTED]>...
>I'm a rank newbie, passing thru security issues for the 1st time. I've
>been exposed to the public key method, and an explanation showing
>host-spoofing:
>
>A --> Spy --> B,
>
>where B believes the public key it received is from A when it is really
>from Spy.
>
>My text claims that use of a public key certificate authority (CA) will
>keep the spy at bay. My question is: if the Spy can insert itself
>between A & B, why not between A & CA, or B & CA?
>
>Jerome.
------------------------------
From: Atle Sandvold <[EMAIL PROTECTED]>
Subject: Storing keys
Date: Tue, 03 Aug 1999 11:48:44 +0000
Hi!
What is the best way of storing keys for a symmetric algorithm?
If for instance users homedirs should be encrypted, and all the
encryption keys should be stored in one safe place. The key to one
particular homedir should be released when the user logs in.
If the key database is encrypted, some sort of master key would have to
be used to decrypt them. How should one store the master key?
Are there some documents that describe how these keys should be stored?
Thanks
-Atle
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: bits and bytes
Date: Tue, 3 Aug 1999 12:48:28 +0100
Thomas Pornin <[EMAIL PROTECTED]> wrote in message
news:7o1ct8$sqk$[EMAIL PROTECTED]...
> To sum up: if you want portable code, do not even try to guess how
> integer variables are represented in memory, and what are their sizes.
> A portable code can be fast and yet readable. If you require absolute
> speed (I mean, something like twice faster than portable code), then you
> may produce a second version, that makes any hack you want, but this
> version will never be a good sample code. And even then, the endianness
> inherent to the algorithm is irrelevant (I insist on this because
> some of the AES candidates use the little endian representation since
> "it will be faster on the PC"; but this implies some sort of mental
> gymnastic that gives me headaches -- I really prefer big endian, as far
> as human reading is concerned).
The issue of how to define the AES algorithm interface has certainly been a
problem for AES and several papers have been published on the issues
involved.
For the 15 AES algorithms (soon to be reduced to 5 or so) the 128, 192 and
256 bit blocks used have been defined by the various design teams in a wide
variety of ways: 8-bit byte arrays, 32-bit word arrays, 64-bit word arrays
and as 128, 192 and 256 bit words. This has complicated speed comparisons
because there are overheads that are, in effect, completely arbitrary
because they can be 'defined away' by using particular definitions at the
interface.
IMHO the sensible approach is to define the 128, 192 and 256 bit blocks as
just arrays of bits numbered 0..127, 0..191 and 0..255 respectively. But
since bits are hard to deal with efficiently in software we can reasonably
combine bits into 8-bit bytes by defining the blocks as byte arrays of 16,
24 and 32 bytes. In practice this is almost endian neutral since nearly all
(all?) modern processors allow byte addressing in memory and we only have to
worry about the order of bits in bytes. While bit order within bytes is
still an AES problem, in practice it is reasonably easy to deal with.
If the interface is defined at a higher semantic level than arrays of 8-bit
bytes - ints, words, characters etc. - then all sorts of nasty semantics
have to be taken into account and I doubt that this makes much sense. So
IMHO arrays of 8-bit bytes - viewed only as containers for 8 bits (i.e.
without semantics) - make most sense for the AES algorithm interface.
Brian Gladman
------------------------------
From: Gabriel Belingueres <[EMAIL PROTECTED]>
Subject: Re: Traffic flow confidentiality
Date: Tue, 03 Aug 1999 11:50:44 GMT
In my last message I wrote:
> But now arises another question: If TLS 1.0 is able to add a longer
> padding than 255 bytes (lets say, for example, 4096 bytes), is this
> worthwhile the overhead of this extra padding for providing
clickstream
> privacy?
Maybe yes, maybe not. Maybe clickstream privacy could be provided if TLS
would use a random-length fragmentation of records, instead of a
random-length padding in both block and stream cipher, like we were
discussing.
If TLS would provide this kind of fragmentation, then the messages
coming from the higher level protocols (ie Handshake Protocol,
Application Protocol, Alert Protocol) would have to include their
message length (not a bad idea at all).
This reasoning is correct?
Gabriel
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Dr Dude" <[EMAIL PROTECTED]>
Subject: Re: Help please (WWI/WWII ciphers)
Date: Tue, 3 Aug 1999 07:13:40 -0500
Reply-To: "Dr Dude" <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote in message
news:7o2ggc$fj0$[EMAIL PROTECTED]...
| In article <KI0p3.1871$[EMAIL PROTECTED]>,
| "Mike Blais" <[EMAIL PROTECTED]> wrote:
| > 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).
|
| No one is perfect :)
|
| > 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.
The "paragraph" and "section" words possibly suggest lawbooks. The only
thing missing is title and chapter of USC (aasuming it would be unfair to
use state laws). You might try giving us the entire content of a page.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: CFB mode with same initialization vector
Date: Tue, 03 Aug 1999 12:29:20 GMT
In article <[EMAIL PROTECTED]>,
Peter Pearson <[EMAIL PROTECTED]> wrote:
> Daniel Vogelheim wrote:
> >
> > why is encryption in CFB mode insecure, if you use the same
> > initialization vector multiple times?
>
> The danger is that you might encrypt plaintexts whose
> beginnings are identical, thereby producing ciphertexts
> whose beginnings are identical. It is not respectable
> for an encryption system to reveal the fact that messages
> X and Y have the same beginning, even if the system doesn't
> reveal what that beginning is.
>
> If some convention in your plaintext guarantees that
> the first block of plaintext will be different every
> time, the system is as strong as the underlying block
> cipher, even with fixed IV. (Corrections, you other guys?)
Not quite. If the first two plaintext (resp. ciphertext) blocks
of two different messages are P1 and P1' (resp. C1 and C1') then
with the same IV used you'll get C1 XOR C1' = P1 XOR P1' thus
leaking lots of info about the first plaintext blocks.
i.e. if you already know P1 then you can trivially compute P1'.
If you have an implementation that uses CFB mode with a fixed IV
(and I seem to recall that there is a widespread little crypto
program that does just this) then you should really consider the
first blocks of everything you encrypt with it as being in the clear!
(Unless of course you use a different key each time you invoke it).
Paul(o)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Virtual Matrix Encryption
Date: Tue, 03 Aug 1999 13:20:30 GMT
In article <7ns97p$p60$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> A lot of idiots demand proof. When in reality none of the methods in
> current use have been proven secure except the OTP. So to anwser
> your quetion again " NONE OF THE METHODS IN PGP" have been
> proven secure. To anwser in another way you might be able to
> understand. "ALL THE ALGORITHMS in PGP" have not been
> proven secure.
>
It's not a matter of 'idiots demanding proof' it's that people say an
algorithm is completely secure when it's a conjecture that the
algorithm is secure.
DES for example was thought to provide 56-bit key strength until
differential analysis broke all 16 rounds ...
Basically I think it's how people say things. Like VME uses 'otp'
quality encryption but uses fixed size keys (or an infinite sized
matrix ... ?)...
Now to burst your balloon. Scottu methods have not been proven to be
secure either. And posting a 'this is my binary crack it' is just as
hard as posting a 'this is my blowfish binary' but we all know that
blowfish (reduced rounds) can be broken.
Attack a cipher (except maybe stream ciphers) is rarely a matter of
looking only at ciphertexts. If a chosen/known attack requires say 1KB
of pairs then it could be a bad protocal lets you do that and you can
find the key ...
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] (Patrick Juola)
Subject: Re: the defintion of Entropy
Date: 3 Aug 1999 09:48:12 -0400
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>> The period of the output is infinite however (otherwise it's not
>> truly random).
>
>What makes you think that "period" is well-defined for more than
>a negligible subset of infinitely long bit sequences?
Aren't you two discussing the same sequences in different terminology?
If he wants to call an aperiodic sequence a sequence of infinite
period, why not let him?
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: [Q] Why is pub key cert. secure & free from spoofing?
Date: 3 Aug 1999 09:42:12 -0400
In article <[EMAIL PROTECTED]>,
Jerome Mrozak <[EMAIL PROTECTED]> wrote:
>I'm a rank newbie, passing thru security issues for the 1st time. I've
>been exposed to the public key method, and an explanation showing
>host-spoofing:
>
>A --> Spy --> B,
>
>where B believes the public key it received is from A when it is really
>from Spy.
>
>My text claims that use of a public key certificate authority (CA) will
>keep the spy at bay. My question is: if the Spy can insert itself
>between A & B, why not between A & CA, or B & CA?
The certificate authority is a publically-known entity, and as such
is a lot harder to impersonate. For example, as a private citizen,
you don't really know what I look like, how my voice sounds, or what
my signature looks like -- on the other hand, you know at least two
of those for President Clinton. If a five-foot two latina woman were to
show up at your house with an accent straight out of a Cheech and Chong
film and claim to be Clinton, you *might* get suspicious.
In a cryptographic context, the certifying authority of course certifies
itself as well, ideally with a lot of very public, very broad sources
of information -- distributing its certificate freely, providing 1-800-
hot lines to confirm its validity, and so forth. As a real-life example,
I don't think that anyone could impersonate Phil Zimmerman as his public
key is distributed with every copy of PGP out there. If I have any doubt
about the validity of a key for which Phil vouches, I can easily check
his purported signature against the publically-known one.
-kitten
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Americans abroad/Encryption rules?
Date: Tue, 03 Aug 1999 13:53:38 GMT
In article <wgu20.933676949@riemann>, [EMAIL PROTECTED] (W.G. Unruh)
wrote:
>[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
>
>>if your off us soil and you send encryption to any one you can"t be accussed
>>of exporting from the us since your exporting from some where else.
>
>that is true, unless you brought the crypto out with you, inwhich case you did
>export it. However, if you as a US citizen supplied Ben lauden(?) with crypto,
>even if you had gotten it off a Finnish server, I suspect you would find
> yourself
>in trouble.
>
IF you where a small bit player in world politics so that you would not be
missed and you supplied Ben Lauden with crypto that the NSA could not
break. You would not have to worry about any laws since the U.S. government
would have you killed. They would reather kill you as a small fry than risk a
court battle.
Second I thought some of the RSA people were moving operations to New Zealand
so they can write some "export free" crypto. I assume it is hard to give up
ones citizen ship. What does citizenship give you other than the right to
vote. What does one lose if anything when you move abroad. I know that
there are foreigners who worked in the US that get social security. Could
a retired person leave the US for good dump his citizenship and still get
his US retirement.
Are there retirement checks from Uncle Sam going to Cuba for example.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Blowfish x86 assembler
Date: Tue, 03 Aug 1999 13:37:14 GMT
In article <Yhvp3.25$[EMAIL PROTECTED]>,
"Kasper Pedersen" <[EMAIL PROTECTED]> wrote:
> I got hold of the Blowfish implementation from Eric Young's SSL
> implementation (pointed to as reference by counterpane), and found it
a
> little slow on Celeron/P-2/P-3/K6-2.
> On counterpane.com it is listed as being able to do encryptions at 18
> clocks/byte. This is 144 clocks pr. 16 rounds /9 clocks per round.
Now, on
> the K6-2 the asm code from 'SSLey' required 16 clocks, and on the P-3
24 (!)
> clocks.
> After K6 optimization and pure chance on the P-x, I have got it down
to 11
> on K6-2 and 12 on P-3.
> (The P2/P-3 might drop a clock or two when I get the time and a P-2
PC)
>
> Was the Pentium (-1) just better at this, or is there a really smart
way?
> Does anyone have some even faster code that I can learn from?
Well I dunno about the fastest code but I think the pentiums were the
last cpu to handle 8-bit data well. That might be why. Also I don't
think their is alot of parallelism in blowfish.
> So far, on a K6-2-350 I get
> Blowfish: 1.95 MHz (179 clk)
> DES+schedule increment: 1,19/1.02 MHz (293/343 clk without/with
> schedule)
> As always, if anyone wants this code, I'll happily mail it, provided
that
> you tell me if you make it faster (and how)..
That's wierd cause I write 'blowfish variants' all the time and get
around 24 cycles/byte. It's not hard either, even fully unoptimize RC6
code runs at 70 cycles/byte (hehe oops :) ).
If you could send the file(s) to '[EMAIL PROTECTED]' I wouldn't
mind checking it out. no guarantees though. I promise I won't 'run
off' with your code though.
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: How to keep crypto DLLs Secure?
Date: Tue, 03 Aug 1999 13:23:52 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Basically any software can be infected by worms or viruses.
>
> You assume several things, including:
> (1) The network uses insecure protocols.
> (2) The OS uses insecure mechanisms.
> While those are true of Windows on old-IP,
> they would be much less so for something
> like Plan 9 on IL (a cryptographically
> authenticated protocol).
>
> Some day it will be "obvious" to everyone how
> stupid we were to place so much reliance on
> such shitty systems and protocols.
>
I run win98 and am on the net quite a bit. I assume that people can
get access to my computer. I do my private work on a disconnected
second computer. Simple as that. If you want to blow up my hd or
steal quake from me goahead. I have no real work to lose here...
That's my view of win98/95 with internet connections. Even though I
don't run a FTP or HTTP server windows my have some 'features' I don't
know about.
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: "Vasiliy Khalak" <[EMAIL PROTECTED]>
Subject: NORTON Diskreet Decrypt Help me
Date: Tue, 3 Aug 1999 17:03:04 +0300
Hello!
I need decrypt of Diskreet's disk.
Can you help me? I search all information about this but I can't find the
compiled program which do it self.
Thank for your time & your help.
Basil ([EMAIL PROTECTED])
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: [Q] Why is pub key cert. secure & free from spoofing?
Date: Tue, 03 Aug 1999 16:40:18 +0200
Jerome Mrozak <[EMAIL PROTECTED]> wrote:
> I'm a rank newbie, passing thru security issues for the 1st time.
> I've been exposed to the public key method, and an explanation showing
> host-spoofing:
>
> A --> Spy --> B,
>
> where B believes the public key it received is from A when it is
> really from Spy.
>
> My text claims that use of a public key certificate authority (CA)
> will keep the spy at bay. My question is: if the Spy can insert
> itself between A & B, why not between A & CA, or B & CA?
>
Presumably the public key of the CA is widely known. If the CA
signs A's key, then you can verify the signature using the CA's
widely known key.
A spy would have a hard time getting around this. If more than
one CA is involved then the task becomes practically impossible.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED]
Subject: DES crypt(3)
Date: Tue, 03 Aug 1999 14:53:42 GMT
Plans are underway to design and build hardware to crack DES crypt(3)
encoded passwords by brute force using 100MHz Xilix FPGAs in parallel.
The task is mearly as a "science project" to see just how many possible
keys we can eliminate / sec. Could someone provide me with the concise
algorithm for crypt(3). Thanks
Brent
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Infallible authentication scheme
Date: Tue, 03 Aug 1999 13:55:28 GMT
<snip>
I have no clue where you are getting those ideas from but your scheme as
A is the private seed shared, I = 0 (zero)
1. Make a random R, I = I + 1
2. Send R and H(A||R||I)
3. repeat as required
4. store I in a file (so it's used over again)
For identity prove will work if H is a strong hash function. Even if
you know 159 bits of the 160 bits input you shouldn't be able to guess
the last bit with a probability p != 1/2. Otherwise the hash function
is not strong.
So even if you know R and I, but not A (say A is 160 bits, R is 128 and
I is 64). You can't learn anything about A from R or I. The only
method left to attack would be to guess A. A replay attack would not
work since you have the counter. Both sides would share (A, I)
(privately) and R can be generated anyway they want (as long as it's a
good quality PRNG).
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (John McDonald, Jr.)
Subject: Re: Americans abroad/Encryption rules?
Date: Tue, 03 Aug 1999 14:13:41 GMT
On 2 Aug 99 17:13:37 GMT, [EMAIL PROTECTED] (W.G. Unruh)
wrote:
>Oh yes you are. A US citizen is bound by the laws of the USA wherever in the
>world that person is located.
Apologies, but this is simply NOT true. A citizen of the USA is no
more bound to the laws when he leaves the country than he is protected
by them.
Just as an example, its the LAW in the US that I drive my automobile
on the right side of the road. If I were to follow this law in say,
Japan, or Hong Kong, I would certainly be involved in numerous traffic
accidents.
Its the law in the US that we cannot solicit prostitutes, or use
Marijuana. However, if I go to Amsterdam's Red Light district, these
activities are perfectly okay. I can engage in them without fear of
prosecution.
Its the law in the US that we observe copyright laws. However, if I
travel to Singapore, (or was it Taiwan, or HK?) no such laws exist. I
can copy all the software I want, and its totally legal.
In the case of the last law, if I bring the "pirated" materials home,
I can get in trouble here, but this does not change the fact that your
statement is false.
The only time US laws apply to US citizens abroad is when they are
technically on "US Soil" at a military base abroad or an embassy.
Peace!
[-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-]
John K. McDonald, Jr. Alcatel, USA
[EMAIL PROTECTED]
please remove -delete- for responses.
--
"I speak for me and not this company"
TO SPAMMERS:
Please view the definitions for
"telephone facsimile machine,"
"unsolicted advertisement," and the
prohibition and penalty for sending
unsolicited faxes before sending Un-
solicited Commercial E-mail to the
above address. Violators WILL BE
PROSECUTED. These can be found
in:
The Telephone Consumer Protection Act
of 1991, Title 47, Chapter 5,
Subchapter II, Section 227.
[=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=]
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: PC Encrypt
Date: Tue, 03 Aug 1999 16:47:36 +0200
ALF wrote:
>
> I offer secret forwarding of encrypted mail as part of my service.
>
Should we tell you customers about http://www.hushmail.com/
> I just purchased PC Encrypt. PC Encrypt - Is public-key encryption that
> lets you communicate securely with people you've never met, with no
> secure channels needed for prior exchange of keys. Much easier to use
> than PGP.
>
> Question: How many have tried it, and do you think it is a strong
> as PGP or stronger?
>
You "purchased" it without knowing how strong it was...???? ;-)
Seriously, there's no rocket science involved in doing this and
the site isn't making any unreasonable claims (unlike some programs
we could mention).
It could be ok.
We're all paranoid around here and don't trust anything we don't
have the source code to and that we compiled ourselves, but that
doesn't mean that commercial software can't work....
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: With all the talk about random...
Date: Tue, 03 Aug 1999 16:50:04 +0200
"Douglas A. Gwyn" wrote:
>
> Try *defining* fairly rigorously the meaning of "random" and *then*
> the issue might be resolvable.
Oh, goody, we're going to restart the "random number" thread.....
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (John McDonald, Jr.)
Subject: Re: How to keep crypto DLLs Secure?
Date: Tue, 03 Aug 1999 14:00:42 GMT
Begging everyone else who replied to your comments' pardons, but from
a programming standpoint, the solution to this is VERY simply...
Have you ever heard of "Checksum"s?
If you haven't allow me to explain. (If you have, read the explanation
anyways, because this will allow you a little more peace of mind.) A
Checksum is a file summation tool. It allows a user to compare to
files quickly without having to do a binary comparison. A Checksum on
two files that are supposed to be the same, but have minute
differences will come out with different Checksums. It is FAR more
likely that two files that are different will come out with similar
sums. At anyrate, here's what you do.
Build your .DLL. Run a checksum on it. Generate your own CheckSum
algorithm if you want. Store the value that is returned as a constant
in your .EXE that is to call the DLL. Then, add code to Checksum the
DLL in the future, and compare your constant to the value you get
back. If someone has replaced your .DLL, you WILL be aware of it.
Hope this helps.
[-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-]
John K. McDonald, Jr. Alcatel, USA
[EMAIL PROTECTED]
please remove -delete- for responses.
--
"I speak for me and not this company"
TO SPAMMERS:
Please view the definitions for
"telephone facsimile machine,"
"unsolicted advertisement," and the
prohibition and penalty for sending
unsolicited faxes before sending Un-
solicited Commercial E-mail to the
above address. Violators WILL BE
PROSECUTED. These can be found
in:
The Telephone Consumer Protection Act
of 1991, Title 47, Chapter 5,
Subchapter II, Section 227.
[=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=]
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: the defintion of Entropy
Date: Tue, 03 Aug 1999 08:23:19 -0600
Reply-To: [EMAIL PROTECTED]
"Douglas A. Gwyn" wrote:
> "Tony T. Warnock" wrote:
> > ... all k-bit combinations occur with the proper frequency.
>
> I don't know what you mean by "proper frequency", but almost all
> (in a measure-theoretic sense) k-bit combinations do not occur at
> all in the sequence I gave the first several bits of.
Perhaps I didn't read your sequence properly. I thought you wrote
(commas inserted for clarity):
0,1,10,11,100,101,110,110,111,1000,1001,... concatenated.
In this sequence, for any block of k-bits, the asymptotic frequency of
occurence is 1/2^k. However there is an excess of 1's in the sequence.
Frequencies (strong law of large numbers) is rather weak.
Tony
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: With all the talk about random...
Date: Tue, 3 Aug 1999 14:59:18 GMT
fungus wrote:
> "Douglas A. Gwyn" wrote:
> > Try *defining* fairly rigorously the meaning of "random" and *then*
> > the issue might be resolvable.
> Oh, goody, we're going to restart the "random number" thread.....
The thread already is under weigh, but it's pointless when
its key term doesn't have a well-defined meaning.
------------------------------
** 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
******************************
