Cryptography-Digest Digest #12, Volume #9 Sun, 31 Jan 99 17:13:03 EST
Contents:
Re: Encryption for my little java-mail-server (fungus)
Re: SCOTT19U (JPeschel)
Re: Some more technical info on Pentium III serial number (John Savard)
Re: PRNG Theorem (Gregory G Rose)
Re: *** Where Does The Randomness Come From ?!? *** ("Tom Norback")
Re: Sanity check take 2 (Edward Keyes)
Re: *** Where Does The Randomness Come From ?!? *** (R. Knauer)
Re: ("Jennifer M Phillips")
Re: Encryption for my little java-mail-server ("Markus Hahn")
Re: Random numbers generator and Pentium III (R. Knauer)
Re: Sanity check take 2 ("Kazak, Boris")
----------------------------------------------------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Encryption for my little java-mail-server
Date: Sun, 31 Jan 1999 19:41:35 +0100
Dominik Werder wrote:
>
> Hi All!
>
> I need any good and fast encryption for my little java chat server. I
> tried RSA, but its too slow. Has anybody DES or IDEA for Java or
> Pseudocode or a realy good docu for these algorithms?
Get DES in Java here:
ftp://ftp.artlum.com/pub/DES.java
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: SCOTT19U
Date: 31 Jan 1999 19:32:47 GMT
>[EMAIL PROTECTED] writes, in part:
>Is the latest contest for real? The contest seems very easy,
Yes, it is for real. Scott knows finding the solution should be easy.
That is why there is no money involved, only the chance to gloat.
It may, however, be a bit (or 4 bits) harder than you think, so, in March,
a 1 nibble clue will be given on my site and Scott's.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Some more technical info on Pentium III serial number
Date: Fri, 29 Jan 1999 20:38:59 GMT
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote, in part:
>I've had some experience designing tamper-proof software, including
>anti-emulator and anti-debugger techniques. It is not simple. Only
>multiple layers of security offer a hope of protecting app code.
I would tend to agree with that assessment. One provides the computer
with the full set of instructions to execute the program; so there is
very little one can do.
One can use an encrypted p-code for part of the program.
One can do some I/O, and check the timings for reasonableness.
But all these efforts just make work - eventually, step by step, one
can unscramble the code.
But an undocumented instruction would, at least, prevent a trivial
direct attack with an emulator - and do so dependably in all machines
in which the chip was used, even if they weren't PC-compatible. Also,
as Intel _is_ the chip designer, they could have included a special
instruction specifically suited to this kind of purpose.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: PRNG Theorem
Date: 31 Jan 1999 11:29:44 -0800
In article <790b9b$nv0$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>Let p(i) be the probability that the PRNG enters a cycle (encounters a
>previous state) after i hash rounds, starting from an arbitrary initial
>state, and given that a cycle was not entered in a previous round.
>Obviously,
>
> i
> p(i) = --- (1)
> 2^K
No. This is the least probability... the actual
probability could be greater than this. A good hash
function would be very unlikely to have this
probability, because it would have to map the
possible inputs to *distinct* outputs, and hence
would be reversible.
>Is it correct?
No.
>Is it new?
No.
A good summary plus references is in one of the
early chapters of "the Handbook of Applied
Cryptography", by Menezes, van Oorschot and
Vanstone. It may even be online.
Basically (from memory) a good hash function
should lead to a number of distinct cycles after a
tail of similar length. The largest cycle and the
tail length are of order 2^(K/2) elements. Quite a
lot can be proven about the statistical
properties.
Greg.
--
Greg Rose INTERNET: [EMAIL PROTECTED]
QUALCOMM Australia VOICE: +61-2-9181 4851 FAX: +61-2-9181 5470
Suite 410, Birkenhead Point http://people.qualcomm.com/ggr/
Drummoyne NSW 2047 B5 DF 66 95 89 68 1F C8 EF 29 FA 27 F2 2A 94 8F
------------------------------
From: "Tom Norback" <[EMAIL PROTECTED]>
Crossposted-To: sci.skeptic,sci.philosophy.meta
Subject: Re: *** Where Does The Randomness Come From ?!? ***
Date: Sun, 31 Jan 1999 19:40:19 GMT
Marty Fouts wrote in message ...
> >[Tom Norback suggested:]
> > It may be that likening reality to a system with discrete
> > configurational states introduces difficulties into our analysis.
>
>possibly. However, if one assumes that time is quantized then it
>should follow.
>
Quantized time (or epochal duration) is a feature of some metaphysics
(Bergson's and Whitehead's in particular, vaguely in William James) but as
far as I know it is not currently a feature of any scientific theory.
My understanding is as follows (I'm no expert so I welcome correction on
these points):
Space-time in general relativity is treated as a single, continuous
operator. Time in quantum physics is a parameter--not an operator--so time
does not correspond to any observable quantity of the quantum system. In
particular, "quanta of time" are not features of quantum systems. (Spatial
coordinates are operators in QM describing observable characteristics of the
quantum system.)
Relativistically the notion of a discrete (and absolute) order of succession
from C(n) to C(n+1) is problematic. In some frames of reference the
separation between the two configurations would be timelike while in others
the separation would be spacelike (making C(n) and C(n+1) "simultaneous").
In extraordinary frames of reference C(n+1) would actually preceed C(n). As
Roger Penrose likes to point out, gravity--unlike the other fundamental
forces--influences causality.
Relativity makes F(C(n)) = C(n+1) merely a local sort of "perceived
determinism".
QM makes F(C(n)) = C(n+1) something of a crap shoot.
Our intuition of causal relationships between events is obviously expressive
of some deep truth about reality. But what would motivate us to believe
that it is the "whole truth"? If every feature of C(n+1) is determined by
C(n), then every event of the universe was completely determined within
C(0). This strikes me as very unlikely in that it would deny our similarly
powerful intuitions that freedom, spontaneity, and creativity are still part
of the world and not merely antecedents to the world. [Okay, so arguments
from intuition are weak. Still, it is always useful to ask into the
motivations of our speculations.]
Tom Norback
------------------------------
From: [EMAIL PROTECTED] (Edward Keyes)
Subject: Re: Sanity check take 2
Date: Sun, 31 Jan 1999 13:40:30 -0500
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> Allow me to throw in a couple of words in favor of layman's
> approach. Why is your S so short (256 bits)? I understand that your
> platform may be computationally meager, but is it memory-meager also?
Actually, for use as a cryptographic key, 256 bits is quite adequate,
since it is effectively immune to brute-force attacks (that is, if
you assume the cipher algorithm is any good). It isn't a memory
issue... that's simply all you need to be secure without horrendous
overkill. The key is only used to encrypt session keys, so there's
very little ciphertext to analyze anyway.
> If yes, then disregard all the following (or upgrade).
> Assume that your random shared secret S is of order of 100-500 Kbyte.
> This can be just a random file generated by any appropriate method and
> exchanged once between two correspondents.
Of course, such a file will have to be exchanged securely. A 256-bit
key can be generated from a memorized passphrase, for instance.
A 500-kilobyte file presents a little more hassle, especially since
it will have to be generated by some (cryptographically secure) random
process to begin with. And since it cannot be memorized, it is subject
to physical attacks (steal the hard drive!).
> Then all the protocol will consist of sending an encrypted message
> accompanied by a cleartext phrase like following:
> "Use 236315, 25" ,
> which will mean "open the S file, copy out of this file 25 bytes
> starting from byte #236315, use these bytes as key for the message".
> Authentication is automatic, if the message decrypts, it is indeed
> coming from the right party.
Of course, some means of recognition will have to be built in to the
encrypted message, then... a checksum or a bit of known plaintext.
Otherwise it would be impossible to send, for instance, another session
key in this way, since one string of random bytes is indistinguishable
from the 'correct' one.
And of course, once you start incorporating a known plaintext header
into your messages, you begin to allow attacks against them.
> The man in the middle can intercept the messages until Turkish
> Easter, the only way to make sense of these numbers is to compromise
> the S file (steal, buy, confiscate, take by force, etc).
However, a man in the middle could easily start to fake messages, since
he would be able to replay old messages encrypted with an old session
key. Since no challenge-response is performed, a valid replayed message
is indistinguishable from a new message that just happened to repeat
an old session key.
> Any party can initiate the conversation, there are no restrictions.
> Session keys are never reused, provided the S file is long enough.
> Respectfully BNK
> P.S. I use this protocol communicating with my son in Moscow.
I agree, this is a nice secure way of communicating between *people*.
Communicating between machines, on the other hand, requires a little
more care, since they often (a) have to send seemingly random data,
and (b) don't have the intelligence to recognize when they're being
spoofed with a replay attack.
+------------ Edward Keyes, [EMAIL PROTECTED] -------------+
|................ http://web.mit.edu/eakeyes/www/ ................|
|.... DaggerWare: "small, sharp, and with a heck of a point!" ....|
+- "A little inaccuracy saves a world of explanation." C.E.Ayres -+
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Crossposted-To: sci.skeptic,sci.philosophy.meta
Subject: Re: *** Where Does The Randomness Come From ?!? ***
Date: Sun, 31 Jan 1999 20:10:38 GMT
Reply-To: [EMAIL PROTECTED]
On Sun, 31 Jan 1999 19:40:19 GMT, "Tom Norback" <[EMAIL PROTECTED]>
wrote:
>Time in quantum physics is a parameter--not an operator--so time
>does not correspond to any observable quantity of the quantum system. In
>particular, "quanta of time" are not features of quantum systems. (Spatial
>coordinates are operators in QM describing observable characteristics of the
>quantum system.)
Time is the conjugate variable to energy, which is related to
frequency through Planck's constant. The linewidth of an energy
spectrum is related to the time constant for the process that
produces that energy spectrum.
For example, in radioactive decay the linewidth of the Mossbauer
spectrum is related to the half life of the radioisotope producing the
spectrum. The shorter the half life of the excited state from which
the decay occurs, the broader the resulting spectrum of gamma rays
emitted for recoilless events.
In the limit of an infinte half life, a perfectly stable state, the
spectral linewidth is zero - that is, its energy is precisely
defined. That is the property of the ground state.
So time plays a crucial role in Quantum Mechanics. Transitions in
general from one state to another are characterized by a time constant
which is related to the energy spectrum for the transition.
Bob Knauer
"I place economy among the first and most important virtues and
public debt as the greatest dangers to be feared. We must not
let our rulers load us with perpetual debt."
--Thomas Jefferson
------------------------------
From: "Jennifer M Phillips" <[EMAIL PROTECTED]>
Subject: Re:
Date: 31 Jan 1999 20:39:36 GMT
Here's a good one....
"Oldy but goody"
New and improved
jsw73 hushywquiy uyuwud/
HJSHD HUDUWJK
hjshjd87*&^%$% h8*
^&^*^$%&$%& *^&uIghgxUyu9[
t^&*(^& huIYUUlll!!!!!!!!!
Have fun...
Terje Mathisen wrote in message
------------------------------
From: "Markus Hahn" <[EMAIL PROTECTED]>
Subject: Re: Encryption for my little java-mail-server
Date: 31 Jan 1999 21:13:17 GMT
Dominik Werder <[EMAIL PROTECTED]> schrieb im Beitrag
<[EMAIL PROTECTED]>...
> Hi All!
>
> I need any good and fast encryption for my little java chat server. I
> tried RSA, but its too slow. Has anybody DES or IDEA for Java or
> Pseudocode or a realy good docu for these algorithms?
> Then please mail me: [EMAIL PROTECTED]
>
> Thank you very much!
> DoMiNik
You may try my Blowfish for Java 1.5, which might be fine for
encrypting short e-mail messages with the BlowfishEasy class.
Markus
--
// remove SPOOKY_ to get
// my real e-mail address
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random numbers generator and Pentium III
Date: Sun, 31 Jan 1999 22:02:07 GMT
Reply-To: [EMAIL PROTECTED]
On Sun, 31 Jan 1999 16:02:12 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>You keep repeating this same falsehood.
Yeah, me and von Neuman.
"Anyone who considers arithmetical methods of producing random digits
is, of course, in a state of sin. For, as has been pointed out several
times, there is no such thing as a random number - there are only
methods to produce random numbers, and a strict arithmetic procedure
is of course not such a method."
Although von Neumann was focusung on the method of generation is that
statement above, his comment: "There is no such thing as a random
number" is what I am defending here.
>Please get it straight.
No, you get it straight. You are the one who is going against
mathematical tradition, not me.
>The fact
>that there is no statistical test that is sufficient to qualify a sequence
>as random DOES NOT mean that a sequence can be qualified as random without
>passign the necessary statistical tests.
You are overlooking two most fundamental problems with that assertion:
1) If you use statistical tests to qualify numbers as random, you will
reject a TRNG, since some of its outputs are not stochastically
random.
2) If you use statistical tests to qualify numbers as random, you will
accept a PRNG, since some of its outputs are stochastically random.
The best you can hope to accomplish with statistical tests is to put
some kind of confidence limits on the suitability of the generator.
But that falls far short of the agenda for the OTP system. Confidence
limits on suitability are not only of no value for a system that must
be proveably secure, but they are dangerous in that they can give a
false sense of confidence.
>It's just not that hard a concept.
Actually randomness is an extremely hard concept in many ways. Just
the fact that there are so many different and contradictory kinds of
randomness attests to that.
Li and Vitanyi in their book on Kolmogorov Complexity demonstrate that
all probabilistic measures of randomness fail except for algorithmic
complexity. They show many reasons why stochastic randomness is not
suitable for finite strings. For example if p is the probability for
the bit 1 to occur, then infinite strings will have an infinite number
of 1s as aexpected only if p>=1/2. If p<1/2, then there are only
finite number of 1s in an infinite sequence. IOW, if p = 0.5-epsilon,
then the infinite number is not random.
They also show that there is a very close relationship between
algorthmic complexity and shannon entropy, your favorite concept.
Unfortunately algorithmic conplexity is unsuited for crypto-grade
randomness..
>In theory this is true. However, there is no known attack that makes it
>easier for an attacker to decipher a non-trivial message masked with a key
>that has been filtered by 50%.
Patrick Juola and others have disagreed with that so many times we
could write a book on it. Once you start filtering strings you open
the OTP up to a Bayesian inference attack.
Li and Vitalnyi demonstrate a remarkable thing about Bayesian
inference. It makes no difference which initial distribution you use
as your starting hypothesis as long as you can collect enough new
information to converge on the correct distribution. In fact there is
a universal distribution that can be used as the initial hypothesis
which makes the process efficient. The only requirement is that you
have sufficent information.
When we talk here of proveable security, we are not placing any
arbitrary restrictions on the use of the OTP system, like a very small
number of very short messages. Therefore we assume that a Bayesian
attack can be made, and it will uncover any filtering of strings. If
you filter strings, you open up the OTP system to attack, however
small that might be - and that means it is not proveably secure.
>While the reduction in possible plaintexts
>is 50%, the effective loss of information is one bit.
As stated above, entropy and algorithmic complexity are the same
concepts and we know that algorithmic complexity is not suitable as a
criterion for proveable security of the OTP - Greg Chaitin himself has
stated that in (private communication). Therefore partial entropy is
unsuitable as a criterion to ensure the proveable security of the OTP
system.
Bob Knauer
"I place economy among the first and most important virtues and
public debt as the greatest dangers to be feared. We must not
let our rulers load us with perpetual debt."
--Thomas Jefferson
------------------------------
From: "Kazak, Boris" <[EMAIL PROTECTED]>
Subject: Re: Sanity check take 2
Date: Sun, 31 Jan 1999 17:11:52 -0500
Reply-To: [EMAIL PROTECTED]
Edward Keyes wrote:
> > Assume that your random shared secret S is of order of 100-500 Kbyte.
> > This can be just a random file generated by any appropriate method and
> > exchanged once between two correspondents.
>
> Of course, such a file will have to be exchanged securely. A 256-bit
> key can be generated from a memorized passphrase, for instance.
>
> A 500-kilobyte file presents a little more hassle, especially since
> it will have to be generated by some (cryptographically secure) random
> process to begin with. And since it cannot be memorized, it is subject
> to physical attacks (steal the hard drive!).
=====================
So here you assume that _somebody_ keeps this key in memory...
But a helper file can be kept on a floppy and guarded in a safe...
> Of course, some means of recognition will have to be built in to the
> encrypted message, then... a checksum or a bit of known plaintext.
> Otherwise it would be impossible to send, for instance, another session
> key in this way, since one string of random bytes is indistinguishable
> from the 'correct' one.
========================
Why another session key? The number pair "Use 236315, 25"
IS your session key, you just extract it from the helper file.
However, the checksum at the end of the file is a must, this way the
ciphering program can automatically check if the file is decrypted with
the correct key.
> However, a man in the middle could easily start to fake messages, since
> he would be able to replay old messages encrypted with an old session
> key. Since no challenge-response is performed, a valid replayed message
> is indistinguishable from a new message that just happened to repeat
> an old session key.
=======================
What would be the point of retransmitting the old message without
knowing its content? It can only alert the correspondents...
> I agree, this is a nice secure way of communicating between *people*.
> Communicating between machines, on the other hand, requires a little
> more care, since they often (a) have to send seemingly random data,
> and (b) don't have the intelligence to recognize when they're being
> spoofed with a replay attack.
>
=======================
Here you are contradicting yourself. Before you said that the 256-bit
key is "memorized", which clearly means *people*. Now you say that
communication is between machines. Sorry, but I cannot figure out the
actual environment of your problem. Also, many of replay attacks can be
redered harmless just by incorporating a time stamp or serial number
inside the message. This can also help to alert the correspondents
on the missing messages and out-of-order messages.
Respectfully BNK
------------------------------
** 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
******************************
