Cryptography-Digest Digest #47, Volume #10 Sat, 14 Aug 99 17:13:03 EDT
Contents:
Re: How to keep crypto DLLs Secure? (Eric Lee Green)
Re: What the hell is XOR? (Xcott Craver)
Re: Newbie Question - Do you need to have the message when you have a (Eric Lee
Green)
Re: Cipher-Feedback Mode ("karl malbrain")
Honest Work from Home ("Marc Deneault")
Re: Triple DES (168bit) -- Triple DES (112bit) ("karl malbrain")
Re: Triple DES (168bit) -- Triple DES (112bit) ([EMAIL PROTECTED])
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Re: I HOPE AM WRONG (Jim Dunnett)
Re: Cipher-Feedback Mode (SCOTT19U.ZIP_GUY)
Re: Statistical occurrence of letters in english ([EMAIL PROTECTED])
Re: Please help a HS student with an independent study in crypto ("Douglas A. Gwyn")
Re: NIST AES FInalists are.... ("Douglas A. Gwyn")
Re: Smart card generating RSA keys (Peter Gutmann)
Re: IDEA in AES (Helger Lipmaa)
Re: Positive News About JAWS Technologies ([EMAIL PROTECTED])
Algorithm M Demo ([EMAIL PROTECTED])
Re: Cipher-Feedback Mode ([EMAIL PROTECTED])
Re: I HOPE AM WRONG ([EMAIL PROTECTED])
Wrapped PCBC mode ([EMAIL PROTECTED])
Re: ORB - Open Random Bit Generator (Alwyn Allan)
Re: Algorithm M Demo ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: How to keep crypto DLLs Secure?
Date: Sat, 14 Aug 1999 10:37:43 -0700
"John E. Kuslich" wrote:
> Powerful tools exist today for devining the inner workings of ccode on the PC.
> For some examples of how these tools are exploited, please visit
> http://www.crak.com
Exactly: Remember rule#1 of security:
"Any system to which the intruder has physical access is insecure."
It doesn't matter how much you encrypt something if the intruder can
just sit at the end of the decryption engine and read the plain text
over your shoulder.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: What the hell is XOR?
Date: 31 Jul 1999 21:30:08 GMT
>>#define swap(a, b) (a ^= (b ^= (a ^= b)))
>swap(i,i).
>
>Oops.
>
>Even if *you* don't do it, someone else will.
Especially considering that someone's bound to use it in a sort,
or some code in which array elements are swapped iteratively;
All it takes is a tiny bounds overrun to zero out everything.
Or an algorithm which swaps indiscriminately, such as some variants
of selection sort. Not that you'd use selection sort.
But then, there are plenty of good hacks, which I wish people
would use more. And it still matters today in this age of
fast CPUs and fast disks, because it's also an age of streaming
media. Especially especially since a lot of the people with the
knowledge of image/signal processing to do it right are more EE
than CS, and less likely to know tricks which could give them
big-time speedup.
> Steve
-Caj
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Newbie Question - Do you need to have the message when you have a
Date: Sat, 14 Aug 1999 10:44:09 -0700
Andrew Rutherford wrote:
> I want to be able to create a fixed length key or digest for a particualr
> document of any size, and send this created digest to a recipient who will
> be able to recreate EXACTLY the same message from this digest alone. I've
> put this question on the compression groups, but no answer, so I thought I'd
> try here.
Not really. A digest is a member of a group of algorithms called a
"one-way hash", for which computation is easy, but going the opposite
way would require computational capacity beyond the conceivable.
If your message was 1024 bytes long, this is 8192 bits, and thus you'd
have to try every possible permutation of those 8192 bits in order to
see which ones have the same hash as your digest. Furthermore, if you
did not even know the length of the message being sent, you'd have to
try every combination of bits for every number of bits from 8 to 8
million. I'm sure one of the mathematicians here can tell you how
computationally difficult that'd be, but needless to say the heat death
of the universe will come first.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: Cipher-Feedback Mode
Date: Sat, 14 Aug 1999 11:07:12 -0700
<[EMAIL PROTECTED]> wrote in message news:7p3t3s$ml4$[EMAIL PROTECTED]...
> Two advantages of CFB come to mind immediately:
> 1) Not needing a separate decrypt routine means shorter
> programs
> 2) The inhereht error correction of CFB means less loss
> of data in a noisy environment
1. A separate <<decrypt>> routine is not needed in any mode. Just run the
algorithm backwards.
2. CFB has inherent error RECOVERY, not correction -- the text that the
error affects is localized and the data errors are not propagated. To
obtain error correction you need data REDUNDANCY.
Karl M
------------------------------
From: "Marc Deneault" <[EMAIL PROTECTED]>
Subject: Honest Work from Home
Date: Sat, 14 Aug 1999 14:48:50 -0400
http://people.ne.mediaone.net/marcdeneault/enter.htm
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: Triple DES (168bit) -- Triple DES (112bit)
Date: Sat, 14 Aug 1999 11:12:50 -0700
Frank Piepiorra <[EMAIL PROTECTED]> wrote in message
news:7p1eib$p69$[EMAIL PROTECTED]...
> Several publications refer to Triple DES with the key size 168 bit or 112
> bit. Both seems to have Triple DES but what in detail, besides the key
> length :-) is the difference and does it have an impact on security?
> Frank
The key size never materially exceeds 64 bits with a 64 bit block cipher.
Triple DES materially extends the original 56 bit key size to 64 bits. Karl
M
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Triple DES (168bit) -- Triple DES (112bit)
Date: Sat, 14 Aug 1999 19:12:07 GMT
In article <lkit3.81$[EMAIL PROTECTED]>,
"karl malbrain" <[EMAIL PROTECTED]> wrote:
> The key size never materially exceeds 64 bits with a 64 bit block
cipher.
> Triple DES materially extends the original 56 bit key size to 64
bits. Karl
Nice myth. In fact the keysize limit for any n-bit block cipher is
(2^n)! bits.
Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Sat, 14 Aug 1999 19:17:54 GMT
In article <7p40k1$i9i$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> No I wont talk about back doors. But if you read some of
> the comments in books such as the Puzzle Palace you
> may believe as I that DES was crackable by the NSA in
> a small amount of time when it came out. However it was
> more likely crackable by a fast search. They had the abitlity
> to do it then with specialized hardware. I don't think they can
> do blind search fast enough to cover the full key lengths used
> into todays methods. But witha an intelligent searchig program
> they may easily be in reach of a combination searching and
> analyzing. I am sure they most have a host of programs to
> analyze the hell of out the methods in use.
Well as for brute force if the keyspace is flat the fastest method is
parallel linear searches. No matter what algorithm you use it will not
be faster then testing all keys sequentially (unless the keyspace is
not flat).
If for example you have a 100 byte RC5 encrypted message the fastest
method would be to search the key (the best iterative attacks requires
much more plaintext/ciphertext pairs).
In these 'weak' methods with 80+ bit keys brute force is not very
feasible, thus making the actual cipher secure (now a question towards
the system).
BTW I seriously doubt in the 70's they had the ability to search the
DES keyspace in less then a year.
Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Jim Dunnett)
Subject: Re: I HOPE AM WRONG
Date: Sat, 14 Aug 1999 18:08:30 GMT
Reply-To: Jim Dunnett
On Sat, 14 Aug 1999 01:28:03 GMT, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
wrote:
> Even know as we speak Clinton can not give a firm anwser
>to what the US would do if the main land Chinese invade Twain.
I hope they *do* invade Twain! [Taiwan]
What's all this rubbish got to do with crypto?
--
Regards, Jim. |Findhorn Community:
amadeus%netcomuk.co.uk | Developing EcoVillage
dynastic%cwcom.net | of about 350 people:
|
PGP Key: pgpkeys.mit.edu:11371 | http://www.gaia.org/findhorn/
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Cipher-Feedback Mode
Date: Sat, 14 Aug 1999 20:15:45 GMT
In article <4fit3.79$[EMAIL PROTECTED]>, "karl malbrain" <[EMAIL PROTECTED]>
wrote:
>
><[EMAIL PROTECTED]> wrote in message news:7p3t3s$ml4$[EMAIL PROTECTED]...
>> Two advantages of CFB come to mind immediately:
>> 1) Not needing a separate decrypt routine means shorter
>> programs
>> 2) The inhereht error correction of CFB means less loss
>> of data in a noisy environment
>
>1. A separate <<decrypt>> routine is not needed in any mode. Just run the
>algorithm backwards.
>2. CFB has inherent error RECOVERY, not correction -- the text that the
>error affects is localized and the data errors are not propagated. To
>obtain error correction you need data REDUNDANCY.
>
>Karl M
>
>
All the common approved blessed methods have the errorr RECOVERY
it is no big deal. Except that it makes it easer for the method to be
broken since the plaintext is in effect only diffused a very short distance.
A better chainning would be "wrapped PCBC" I think my stuff is
the only think that uses it at present.
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: Statistical occurrence of letters in english
Date: Sat, 14 Aug 1999 19:22:23 GMT
In article <7p40k0$b9f$[EMAIL PROTECTED]>,
"Seb Chevrel" <[EMAIL PROTECTED]> wrote:
> Anybody knows where I can find this
> kind of information? Is there a central
> collection of statistics for different
> languages?
Ascii text has about 1.3 bits of real information per letter. That's
all you need to know.
Most languages has biases (structures) that can be exploited.
Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Please help a HS student with an independent study in crypto
Date: Fri, 13 Aug 1999 21:33:46 GMT
Jeff Moser wrote:
> I noticed that your email address is at the arl.mil in MD too. Would you
> happen to know if the NSA has a list of non-classified publications of
> things such as the textbook you mentioned?
Except for what you can pick up at the National Cryptologic
Museum, which includes occasional historical studies from
the CCH, the information on their Web site, and occasional
articles in open-literature journals, I don't think there's
much that they publish that they want the public to notice.
So probably there is no such list. However, there *is* a
Public Affairs office, and they may have something along
those lines, or perhaps they can help you get hold of
known material.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Fri, 13 Aug 1999 21:24:32 GMT
"SCOTT19U.ZIP_GUY" wrote:
> IF there is no secret NSA entry in the remaining contenders
> then we tax payers are not getting our moneys worth.
I think it's more probable that they're ready to propose a
decent alternative if the AES winner turns out to not be good
enough for its intended use within the "national infrastructure".
------------------------------
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: Smart card generating RSA keys
Date: 14 Aug 1999 19:21:07 GMT
[EMAIL PROTECTED] (DJohn37050) writes:
>Or use a DL/EC system, where the private key is simply a random number.
The comment about "simply a random number" hides a lot of detail. With any
type of PKC (conventional or ECC), you can't generate good keys without a
source of unpredictable random numbers, something which is virtually
unobtainable in a smart card. Although many manufacturers won't tell you
what they use as RNG's, of the ones I know of I wouldn't trust any of them
to produce output of a quality suitable for crypto keys. Loading in keys
generated externally is therefore not only faster but should produces keys
which are a lot more secure than ones generated internally.
Peter.
------------------------------
From: Helger Lipmaa <[EMAIL PROTECTED]>
Subject: Re: IDEA in AES
Date: Fri, 13 Aug 1999 23:02:15 +0000
[EMAIL PROTECTED] wrote:
> All of this information I directly pulled out of AC2. The only
> successfull attack on IDEA was using side-channel cryptanalysis, but the
> authors of IDEA created a fix. I'm not sure about mod 3 cryptanalysis,
> though.
You are citing a very old (and partly incorrect) source. Todate the best
known attack breaks 4.5 (where .5 stands for the output transformation
appended to first 4 rounds) rounds of IDEA by using impossible
differentials.
> Simply put, from what I can tell, it will take a major breakthrough to
> break IDEA.
This assertion, is however true. I think IDEA seconds only to DES in the
manpower wasted in analyzing it. Note that the 4.5 round attack for IDEA is
utterly impractical, less practical than the known attacks for full DES.
> As far as I can tell, you can implement IDEA faster than DES. This
> usually occurs in software.
True. See http://home.cyber.ee/helger/fastidea/ --- using MMX technology
you can get very fast encryption/decryption with IDEA.
> > 1. Slow key setup
Nonsense. Only Skipjack has simpler key setup :-)
> > 4. It's patented.
It is patented + has 64 bit blocksize. Many people have tried to create a
128-bit block length version of IDEA that would be as secure, but all
constructions are just too slow... However the key length shouldn't be an
issue.
Helger Lipmaa
http://home.cyber.ee/helger
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Positive News About JAWS Technologies
Date: Sat, 14 Aug 1999 19:20:45 GMT
In article <[EMAIL PROTECTED]>,
dave <[EMAIL PROTECTED]> wrote:
> No bet, Tom....not even canadian $.
> They do mention "cumulative XOR" too.
> "Patent Pending" essentially means that the patent office has
> acknowleged receipt of an application, and confers no protection other
> than established priority. It may mean something more if a patent is
> actually granted, but this is a classic shut the barn door after the
> horse is out. The patent examiner is going to be looking for "new",
> "novel", and "not obvious to one skilled in the field" in the
> application before granting the patent.
> It'll be a while yet before we see patent disclosure on JAWS
> (I'm not a lawyer, but I've seen a few excited inventors go past my
> door, and they all want patents. Problem is....if GM wants your super
> carb, GM will have your super carb, and you cannot afford the
litigation
> to enforce your patent).
> There was an article in one of the local business mags about JAWS, and
> it was headed by a photo of these fellows and gals standing around in
> suits with their arms folded and gazing sternly into the camera.
> Looked like a poster for "Men In Black"
Personally I would ignore JAWS and flame it when asked. I would
seriously consider motivating others to stay away from it.
The problem is most newbie people will trust anything you tell them
(see snake oil faq). They put blind faith in systems that99% of the
time are not secure (most 'unbreakable' programs are like that).
Stick with well known and scrutinized methods and protocals and you
wont get burned in the end.
Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Algorithm M Demo
Date: Sat, 14 Aug 1999 20:19:38 GMT
For those who don't know what Algorithm M is I but together a mini demo
of how it might be used. Check out
http://people.goplay.com/tomstdenis/alg_m_demo.zip
If anyone can comment on the security of Alg M, or my implementation or
knows of any previous work, I would appreciate knowing about it.
The package contains a c source file, a header file, and a makefile.
It will build with djgpp, or compile with Turbo C in the IDE.
Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cipher-Feedback Mode
Date: Sat, 14 Aug 1999 20:31:04 GMT
In article <7p4f91$2imm$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> All the common approved blessed methods have the errorr RECOVERY
> it is no big deal. Except that it makes it easer for the method to be
> broken since the plaintext is in effect only diffused a very short
distance.
> A better chainning would be "wrapped PCBC" I think my stuff is
> the only think that uses it at present.
Actually if the block cipher is strong you could encode the messages in
ECB mode and not worry. I would not use it for uncompressed messages
though because some statistics could be leaked. The problem with
your 'wrapped PCBC' mode is that it's slow and completely unusable in
anything but file encryption. Even then there are better methods. CFB
for example will not relate bytes (if you guess them) and is much
faster.
The thing is if you change one bit of ciphertext in CBC mode the rest
of the file will corrupt, the hash won't match and you will know the
file has been corrupted. The attacker can't flip bits of plaintext
since they are not in possesion of it. You don't need todo 87 passes
over a file to ensure this. I think Dave you need to get your head
into real crypto. Somehow you think this, I know not why. It's just
as simple as checking the hash.
Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: I HOPE AM WRONG
Date: Sat, 14 Aug 1999 20:23:11 GMT
In article <[EMAIL PROTECTED]>,
Jim Dunnett wrote:
> On Sat, 14 Aug 1999 01:28:03 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY)
> wrote:
>
> > Even know as we speak Clinton can not give a firm anwser
> >to what the US would do if the main land Chinese invade Twain.
>
> I hope they *do* invade Twain! [Taiwan]
You mean my scanner won't work? oh foo.
>
> What's all this rubbish got to do with crypto?
Does he ever have any crypto-bearing news to talk about? Nope. he
should get his own group though. Either 'alt.total.paranoia' or wierd
Al's group (From his Running with Scissors cd) 'alt.total.loser'.
He talks like people care. I just like pointing out his silly mistakes
(over and over I might add). Personally I don't take anything he says
with any value.
Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Wrapped PCBC mode
Date: Sat, 14 Aug 1999 20:31:56 GMT
Can someone name me one benefit of Dave's 'super-duper' W-PCBC mode?
Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Sat, 14 Aug 1999 16:42:10 -0400
From: Alwyn Allan <[EMAIL PROTECTED]>
Subject: Re: ORB - Open Random Bit Generator
Thanks for the comments on ORB here and by email. Responses ranged from "not
enough technical information" to "where's the business case?" I will respond
to the technical information requests here.
ORB can be characterized as a continuously re-seeded pseudo random number
generator. Real, physical entropy is used in the re-seeding. The underlying
PRNG is cryptographically secure. No practical method of distinguishing ORB's
output from a hypothetical "real" random number generator is known.
The source of the ORB's entropy is measurement uncertainty. A motivating
problem will make this clear.
Suppose that we have a capacitor, and we want to accurately measure its charge
(voltage) with an A/D converter. Suppose further that we have a resistor and
switch through which we can either charge or discharge the capacitor. Now make
these assumptions:
1. The capacitor's capacitance is constant and is known exactly.
2. The capacitor has no resistance, inductance, leakage,
non-linearity, or noise.
3. The capacitor can hold a continuous range of charge, i.e.
fractional electrons.
4. The switch has no impedance, leakage, or noise.
5. The resistor's resistance is constant and is known exactly.
6. The resistor has no capacitance, inductance, leakage,
non-linearity, or noise.
7. The source (sink) from which we charge (discharge) the capacitor
is constant, know exactly, has no impedance, and is noise-free.
8. The duration of charging (discharging) can be controlled to an
exact, known, jitter-free constant.
9. The A/D converter has fixed, constant, exactly know transition
steps.
10. The A/D converter draws no current from the capacitor, and is
noise free.
11. The entire system is perfectly shielded from external
electromagnetic influences.
12. Arbitrary precision calculations can be performed.
We can then use the following method to measure the capacitor's voltage, using
a perfect model of the system:
1. Take an A/D reading. The A/D converter's known transition steps
on either side of the result establish bounds on the capacitor's
voltage.
2. Arbitrarily charge or discharge the capacitor through the
resistor. Use the model to calculate new bounds on the capacitor's
initial voltage corresponding to the transition steps of the next
A/D result.
3. Repeat from Step 1 until the bounds on the capacitor's initial
voltage are sufficiently close.
This is a rational (if not optimal) method only if ALL of the assumptions (and
perhaps others) hold.
In the real ORB system, NONE of the assumptions hold. The A/D results after
the first several iterations are meaningless. They contain unpredictable
information entropy. The charge/discharge cycle is repeated 261 times per
round, and the entropy is collected from the LSB's of the A/D results. It
results from the much studied and unavoidable phenomenon: measurement
uncertainty.
Some method of testing that ORB's entropy generation process is working (i.e.
the output is not just from the underlying deterministic PRNG) is desirable.
It will be considered for a future release.
ORB's sequence of charge/discharge cycles is determined from residual data
from the prior hash calculation. It is arbitrary, however, as long as it is
nominally "white."
The measurement uncertainty method of entropy generation has the advantage
over noise-amplifier methods that it does not require electromagnetic
shielding or differential techniques. Any electromagnetic influence strong
enough to render the output predictable (or even distinguishable from "real"
randomness) would first disable the host system. ORB works with or without
realistic levels of interference.
It is notoriously difficult to measure the quantity of entropy that is
produced by any physical source. For the ORB this was done by repeatedly
running a fixed sequence of 261 charge/discharge cycles on a fully discharged
capacitor and recording the LSB sequences. Duplicate LSB sequences were found
after a substantial number of repeats. Entropy was then estimated using the
derived relation
2^(h+1) = n (n-1) / c
where
h is the bits of entropy
n is the number of repetitions
c is the number of repeated results (collisions)
The results for various resistor values are:
R n c h
50K 114454 12 30.024
100K 95215 4 31.078
200K 123002 7 31.009
Therefore, a conservative estimate is that 30 bits of new seed entropy are
added in each round. This test will be repeated when a chamber can be
constructed to control the chip temperature, electromagnetic shielding, and
power supply noise, to verify that they have their expected effect, and to
establish a lower bound on entropy generation under all specified conditions.
Readers have expressed a desire to examine the un-hashed LSB output of the
A/D, when the ORB is running. I have modified source code to do this, and have
collected data from it. The results are slightly biased and slightly
correlated. I will make the code, the data, and its analysis available on my
website.
ORB outputs 64 bits in each round. Discovering how these bits relate to the 30
bits of entropy would require inversion of the MD2 hash function. If this is a
concern, the user could simply ignore all but 30 bits out of each 64.
Regarding whether ORB is a good or bad design, I have the following comments:
1. It is a fully open design, unlike any other commercially
available RNG device.
2. Confirming that the code operates as described can be performed
with a free compiler/emulator (MPLAB).
3. Verifying that a particular part conforms to the design is cheap,
easy, and does not require examination of silicon.
4. All claims can be verified by anybody with a small amount of
equipment and a desire to do so.
5. It is cheaper than any other commercially available RNG.
6. It is smaller than any other commercially available RNG.
7. It uses less power than published data for any other commercially
available RNG.
8. It does not require shielding, unlike some available RNG's.
9. It is available now.
Special offer: Ten ORB Release 0 devices will be mailed to the first ten
sci.crypt readers requesting them by email. Use the email address on my web
pages. Include a shipping address and state: "I intend to connect my free ORB
to some system and use or test it."
The ORB web page is
http://www.delanet.com/~apa/orb/
I will be updating it with some of this information.
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
======== Over 73,000 Newsgroups = Including Dedicated Binaries Servers =======
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Algorithm M Demo
Date: Sat, 14 Aug 1999 20:26:02 GMT
In article <7p4j0j$56v$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> For those who don't know what Algorithm M is I but together a mini
demo
> of how it might be used. Check out
>
> http://people.goplay.com/tomstdenis/alg_m_demo.zip
>
> If anyone can comment on the security of Alg M, or my implementation
or
> knows of any previous work, I would appreciate knowing about it.
>
> The package contains a c source file, a header file, and a makefile.
> It will build with djgpp, or compile with Turbo C in the IDE.
I should have also added that it's fast. On my 486 it encodes at 3.4
Mbytes/sec, and 16.5Mbytes/sec on my 686. It also requires little ram
and is compact. (Of course this has little bearing on wheter it's
secure or not).
It's sad to note most protocals involve block ciphers when stream
ciphers would be more appropriate (of course in this case you need to
buffer 4 bytes but for most cases that is ok).
Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
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
******************************
