Cryptography-Digest Digest #418, Volume #12 Fri, 11 Aug 00 13:13:00 EDT
Contents:
Re: 1-time pad is not secure... (Guy Macon)
Re: idear for new cipher (tomstd)
Re: 1-time pad is not secure... (James Felling)
Re: Random Number Generator (James Felling)
Re: Best AES candidates ?? (Roger Schlafly)
New version of scott16u and scott19u available (SCOTT19U.ZIP_GUY)
Re: WAP gateway to WWW - Will this configuration really fly from a security
perspective ? (Paul Rubin)
Re: Random Number Generator ("Douglas A. Gwyn")
Re: Secure Operating Systems (wtshaw)
Re: 1-time pad is not secure... (Mickey McInnis)
Re: Destruction of CDs (Mickey McInnis)
Re: New version of scott16u and scott19u available (tomstd)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: 1-time pad is not secure...
Date: 11 Aug 2000 16:27:28 GMT
Tim Tyler wrote:
>
>fvw <[EMAIL PROTECTED]> wrote:
>: <8mth1u$vpt$[EMAIL PROTECTED]> ([EMAIL PROTECTED]):
>
>:>Can you generate truly random numbers? No.
>
>: yes. time between radioactive decays for instance is a
>: textbook example of a perfect random generator.
>
>No such thing as a perfect random number generator has ever been created.
>
>Time between radioactive decays /may/ be random - or it may not be.
>Without vertain access to a complete theory of physics nobody knows.
>...but this is beside the point - even *if* such a random process were
>available, there's no way of measuring it without using a detector
>which is potentially subject to non-random environmental interference.
Speaking as someone who does this kind of measuring for a living, I can
with confidence set an upper bound for such non-random environmental
interference. First we get rid of all noise effects by measuring the
time between radioactive decays and keeping everything digital.
Now we are left with timing errors only (jitter). Our ability to
measure time happens to be far, far more accurate and precise than
our ability to measure any other physical parameter. Cesium clocks
have an accuracy of 2 or 3 parts in 10 to the 14th, i.e. 0.0002 Hz;
this corresponds to a time measurement accuracy of 2 nanoseconds per
day or one second in 1,400,000 years. With this accuracy, and with
a digitizing rate of 4,596,315,885 Hz, (half the Cesium clock freq.)
The maximum amount of non-random environmental interference is very
small indeed - not perfect, but far lower than needed to be of any use
in decrypting an OTP encrypted message. You can, of course, always
win this sort of argument by demanding that anyone who disagrees
prove perfect randomness and perfect knowledge of all possible causes
of interference. True but not interesting.
>: a 100 byte message encrypted with a OTP would have would have
>: 2^800 keys, meaning all possible messages could be 'bruteforced'
>: from that plaintext. Even with a PRNG, all possible plaintexts
>: are possible [...]
>
>With a 100 byte message? Unlikely - unless the PRNG has a comparable seed
>size.
He shouldn't have thrown a comment about Pseudo Random Number Generators
into this. OTPs by definition must use RNGs, not PRNGs.
------------------------------
Subject: Re: idear for new cipher
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 11 Aug 2000 09:22:50 -0700
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>tomstd wrote:
>> Since newer computers are swinging to 64-bit registers it
seems
>> like a good idea to use them but our i86 friends don't have
64-
>> bit registers? or do they? Hmm well the MMX registers look
>> pretty neato but we can't do Z math in them... oh well what
>> about GF math? yuppers..
>
>The forthcoming IA64, which is expected to replace x86
eventually
>(at least in high-end servers), has direct support for 64-bit
>arithmetic, but it isn't terribly hard to support 64-bit
arithmetic
>even on a 32-bit architecture. PK crypto in fact requires much
>wider integers than that, and there are several implementations
>of such "bignum" multiple-precision arithmetic, most of them
>containing specially tuned assembly language for x86.
Try doing a few million 1024 bit adds per second and tell me
bignum libs are practical. Sure if you do ONE per second it
seems fast...
With mmx a ia32 programmer can use 64-bit registers in GF math...
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Date: Fri, 11 Aug 2000 11:27:30 -0500
[EMAIL PROTECTED] wrote:
> Here's a different viewpoint.
>
> I think all the crypto-books are wrong. One-time pad is only secure
> based on the assumption that random numbers do exist.
>
> But can you prove that random numbers really exist? No.
Ummm... No, but yes.
You cannot demonstrate that any finite string is "random", or compare the
"randomness" of finite string X to finite string Y.
However, this is not what is necessary for good crypto. What is necessary
for good crypto is "unpredictable" and "independent" numbers, which are
much more achievable.
>
> Can you generate truely random numbers? No.
You are correct, but it is not necessary to generate TRULY random numbers,
merely "good enough" numbers
>
>
> It's like 1/x tends to zero but you'll never get zero, if you use
> enough bytes to hold the number.
Yes, you are correct that randomness is an impossible thing to catch, but
it can be shown that something is "unpredictable" and "independent" enough
for the job at hand. If 1 bit of a 20 gig message is leaked using
generator X, that is an acceptable level, as the inherent entropy of the
data being transmitted is not compromised. ( If I know that bit 3 of byte
0x4A3D9 of this string is a 0, this does not in any way contribute to a
compromise of the system. True the system is not PERFECT, but it is
sulficiently strong to protect my message from prying eyes as the work
factor to break the code has been exactly halved, but is still much more
than the human race is likely to EVER be capable of doing.
>
>
> One-time pad is only computationally secure, no difference than any
> other systems. The key-generating process may be duplicated, if not
> exactly, to some probability. And because the key is so long, getting
> at least a portion of the key right will be easier than in systems with
> a shorter key.
WRONG here. I strongly doubt that you could "duplicate the radioactive
decay of source X" in any "real" or usable sense of the word without
having compromised the generator manufacturer totally and utterly.( Which
means that an attack using a compromised generator card that transmits the
key on a OOB chanel is much easier and better for you than a "cryptographic
compomise"). Frankly "rubber hose" cryptoanalisys is still going to be
more efficient than either of those.
>
>
> Get the picture? You can duplicate the key-generating parameters:
> computer model, OS, PRNG, date, time, location, hardware, software,
> room temperature, humidity, magnetic field... The list goes on and on.
> Then the longer the key, the higher possibility that you'll get
> something right.
>
> --Sisi
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
The objective with crypto is not to be absolutely secure, as given an n-bit
message you are still vulnerable to a Karnak attack with probability 2^-n,
and to key theft and agent compromise with much higher probabilities.
Cryptographic secrecy is a chain and is only as strong as its weakest
link. Real world OTP is (when properly implemented) stronger than all
other links in the chain, and that is enough.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator
Date: Fri, 11 Aug 2000 11:29:39 -0500
How does it do vs. DIEHARD?
[EMAIL PROTECTED] wrote:
> Alex Random Number Generator
>
> The objective of this algorithm is to map finite
> key/seed to an infinite sequence of random bytes.
> The implementation has following characteristics:
>
> - 16 byte Key/Seed
> - 57% Avalanche Effect
> - 760Kbyte/sec performance
> - 64 Kbyte generated random string shows Null ZIP
> compression
> - The probability to find in random sequence 0/1
> value bits is exactly 50%
>
> Randomness factors
> - lose overflow bit by addition
> - lose overflow byte by multiplication
>
> Algorithm description, source code and EXE
> can be found and download at
>
> www.alex-encryption.de
>
> Regards.
> Alex.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Best AES candidates ??
Date: Fri, 11 Aug 2000 09:37:48 -0700
DJohn37050 wrote:
> Wrong. They have always be very careful to say there many be multiple winners.
Here is what NIST said in the original announcement.
It is intended that the AES will specify an unclassified, publicly
disclosed encryption algorithm available royalty-free worldwide
that is capable of protecting sensitive government information
well into the next century.
[Federal Register: September 12, 1997 (Volume 62, Number 177)]
http://csrc.nist.gov/encryption/aes/pre-round1/aes_9709.htm
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: New version of scott16u and scott19u available
Date: 11 Aug 2000 16:38:51 GMT
This site http://www.radiusnet.net/crypto/
know has the latest versions of scott16u and scott19u
the scott16u package also contains code that was sent
to me from Germany. The code that it uses may make it
easier for others to compile on other then DJGPP GNU C.
Both methods use a form of "all or nothing" encryption
where a single bit change in the plain text would change
the whole output file. Also if even one bit changes in cipher
text file it changes the whole input file it uses "wrapped
PCBC" and the 19 bit version is slow unless you have a very
fast machine. I my make more contests later since the
last one was not solved. Also any one even with JavaScript
on can visit mt website. These changes make it easier to use
on other machines.
Look in there Crypto directory for subdirectory SCOTT
sorry but you have to be from the US to down load it.
Unless your very clever and I hope you are.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction
of the truth."
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: WAP gateway to WWW - Will this configuration really fly from a security
perspective ?
Date: 11 Aug 2000 16:44:06 GMT
In article <3993f3fb$0$[EMAIL PROTECTED]>,
Mark Currie <[EMAIL PROTECTED]> wrote:
>Apologies if this is perhaps a bit off-topic.
It's on-topic as far as I'm concerned.
>In the WAP protocol stack, WTLS or Wireless Transaction Layer
>Security provides security and is similar to SSL-3 or TLS. However
>this is only between a wireless device and a WAP server/gateway. In a
>WWW gateway scenario the WAP gateway handles the SSL session with the
>WWW server and acts as a proxy on behalf of the wireless client. Will
>this model really fly ? The WAP gateway will effectively be a
>man-in-the-middle and have access to all user's sensitive info.
This effect is called "the gap" in the wireless industry.
>The only way that I can see an acceptable security model for
>wireless-WWW commerce with end-to-end security is to have WWW hosts
>implement WTLS or run WAP servers. This sounds like a tall order to me.
I think the e-commerce sector isn't delighted about the situation, but
it doesn't mind that much. The idea is the WAP gateway is located at
the wireless telco and is supposed to be secure. (Of course, that's
the same wireless industry operating it that brilliantly gave us the
A5 ciphers and millions of cloned phones, so some of us stay skeptical
about the security). Law enforcement could probably get access to the
gap given a wiretap order, but the data can't be sniffed over the air
by random people.
>IMHO even apart from the security aspect, the marriage of limited
>content wireless devices to WWW is not good. Wouldn't it be better to
>create a separate WWWW (Wireless WWW) ?
Normally one does that already.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator
Date: Fri, 11 Aug 2000 15:36:46 GMT
[EMAIL PROTECTED] wrote:
> Arithmetic operations with lose of overflow bit by addition and overflow
> byte by multiplication implement one way function. It is impossible to
> calculate previous state from current one. Third randomness factor means
> that during consequently interpretation of words some of them may be
> already modified by previous steps and probably not only one time.
> Got knows how you can calculate previous state from the current one.
Nobody needs to reverse the mapping. Consider:
/* "absolutely secure" key generator */
#include <stdio.h>
int main() {
FILE *fp = fopen("/dev/random","rb");
for(;;) {
int c = getc(fp);
c &= 0xF0; /* irreversible */
putchar(c);
}
}
What does the irreversibility of the mapping have to do with
whether the output can be used securely as a crypto key?
Indeed, push this to the limit and mask off *all* the information
originally in c; clearly the output is the worst possible key.
> Let me ask you how can man implement permutation of bits not using
> Assembler?
It's easy enough to do in C; every bit (on all popular platforms)
in the representation of an integer is individually accessible in
various ways, most commonly by using logical operators (bit masks).
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Secure Operating Systems
Date: Fri, 11 Aug 2000 10:17:29 -0600
In article <8n08v7$1e2$[EMAIL PROTECTED]>, Greggy <[EMAIL PROTECTED]> wrote:
>
> I always thought that a secured OS is an oxymoron...
>
It all depends on how it is designed, software as well as the hardware
configuration. Inapproopriate design has been popular because it was
cheap and is done by people who really do not understad the goals of good
computer security, or wished to subvert devices for their own purposes.
This will change because it must.
--
Too bad from the party members point of view that Ventura has
gone, for what the Reform Party needs is a good referee and
someone who understands how to *fix* things, before hurt sets in.
------------------------------
From: [EMAIL PROTECTED] (Mickey McInnis)
Subject: Re: 1-time pad is not secure...
Date: 11 Aug 2000 16:35:56 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Jerry Coffin
<[EMAIL PROTECTED]> writes:
|> In article <8muoki$994$[EMAIL PROTECTED]>,
|> [EMAIL PROTECTED] says...
|>
|> [ ... ]
|>
|> > The problem with "physically-generated" numbers is that if you
|> > don't do it right, you may have a very slight bias in the distribution
|> > of the numbers. Consider, for instance, a coin flip with a coin with
|> > a 51% chance of heads. Given cleartext that you think goes with
|> > an intercepted ciphertext, you can produce a "trial key". If the
|> > message is long enough, you can say with some probability that
|> > you have the correct cleartext because the trial key shows the
|> > bias you're looking for.
|>
|> This has a number of major problems (at least most of the time). The
|> most obvious is that this requires the attacker to know things about
|> the key. If I simply grab a coin out of my pocket, I might end up
|> with a small bias. There is, however, no way for the attacker to
|> know this, and without knowing it I'm hard put to believe that he can
|> exploit it either.
It's simple to exploit in the right situation for the right purpose.
Given a long enough ciphertext and a number of possible cleartexts,
you can tell with a calculable degree of certainty if any of the
cleartext match the ciphertext. Generate a trial key and see if it
has a bias that's statistically improbable. You can calculate a
probability that you have the right cleartext.
The limiting case is that you have one ciphertext and one cleartext
obtained by some non-cryptographical method, and you want to "prove"
that they match.
I agree, it's far from a generic break in the OTP algorithm in this
case, but it demonstrates the theoretical weakness.
It also conceptually removes the absolute OTP protection against
attack by key exhaustion. Try all probable cleartexts, and look
for ones that generate a trial key with the signature of your
broken key generator. You can calculate differing probabilities
of a trial cleartext being the correct one. (Theoretically, that
is. It's probably computationally infeasible in the most cases.)
You wouldn't even have to know the bias beforehand. Try your
probable cleartext and analyze the resultant key for bias.
You also need to consider the case where the enemy has
obtained a known cleartext/ciphertext pair for a previous
message. He can then has a known key from your "random" number
generation pad generation process. If there's a bias in this
system, the enemy could detect it and look for it in the future.
|>
|> It might be possible for statistics about the ciphertext to be
|> combined with guessed statistics of the plaintext to yield matching
|> guesses on the key, assuming a typical Vernam cipher is used. OTOH,
|> using a different type of cipher (I.e. a different method of
|> combining the key material with the plaintext) can make this
|> substantially more difficult, if possible at all.
Well, the standard practice for determining the strength of a cryptosystem
assumes that the enemy knows everything about your system but the
particular key used for the message under attack.
|> Second, all it
|> gets you is a fairly direct reflection of your guesses about the
|> plaintext statistics; with most ciphers, guesses, cribs, etc., affect
|> enough of a decryption that it's fairly easy to decide whether a
|> particular guess was right or not. In this case, you get no such
|> confirmation.
I'm not quite sure what you mean here.
|>
|> Finally, there are well-known methods of removing systematic bias
|> from a source in any case. When using a physical source of random
|> input, there's certainly nothing that says you can't process it to
|> ensure that what you're getting really is random and free of
|> predictability (e.g. introduced by measuring equipment).
|>
That's why I said, "if you don't do it right". Don't most such
methods of removing bias only work if you know what kind of bias
you're removing? i.e. it's easy to remove the bias of a coin
that has a 1% bias for heads, but if a RNG device has
some more complicated bias, is there a generic bias removal
system? For instance, if there was some slight bias toward every
bit to be identical to the bit 10 positions before it, would a
generic bias removal algorithm catch it?
BTW, I'm not arguing against physical RNG's. I'm pointing out
the possible weaknesses in a bad RNG. I'm very concerned about
some of the "random" number generation processes people propose and
think many of them are a lot weaker than people think they are.
|> --
|> Later,
|> Jerry.
|>
|> The Universe is a figment of its own imagination.
I realize that a lot of this is unlikely to be computationally feasible,
but absolute protection is the name of the game with OTP's. Also, you
need to understand the threat to get an idea of how feasible it is.
I think the threat of imperfect RNG's is, in some cases, larger than
it first appears to be.
--
Mickey McInnis - [EMAIL PROTECTED]
--
All opinions expressed are my own opinions, not my company's opinions.
------------------------------
From: [EMAIL PROTECTED] (Mickey McInnis)
Subject: Re: Destruction of CDs
Date: 11 Aug 2000 16:37:41 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Dave Hazelwood
<[EMAIL PROTECTED]> writes:
|>
|> Earlier I had posted quite a bit about dissolving such CD's in a
|> solvent.
|>
|> This is the best way. No muss, no fuss, no pollution and no
|> pieces left over for forensics....kinda like dissolving a body
|> in acid. When its gone...its gone.
|>
Well, what solvent will a CD dissolve in? What happens to the aluminum
layer, how toxic is the resultant mixture? How toxic is the solvent?
--
Mickey McInnis - [EMAIL PROTECTED]
--
All opinions expressed are my own opinions, not my company's opinions.
------------------------------
Subject: Re: New version of scott16u and scott19u available
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 11 Aug 2000 10:04:45 -0700
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> This site http://www.radiusnet.net/crypto/
>know has the latest versions of scott16u and scott19u
>the scott16u package also contains code that was sent
>to me from Germany. The code that it uses may make it
>easier for others to compile on other then DJGPP GNU C.
>Both methods use a form of "all or nothing" encryption
>where a single bit change in the plain text would change
>the whole output file. Also if even one bit changes in cipher
>text file it changes the whole input file it uses "wrapped
>PCBC" and the 19 bit version is slow unless you have a very
>fast machine. I my make more contests later since the
>last one was not solved. Also any one even with JavaScript
>on can visit mt website. These changes make it easier to use
>on other machines.
Who are you to say javascript is bad?
BTW where can I get a documented (properly) description of
scottu16?
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
** 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
******************************
