Cryptography-Digest Digest #259, Volume #9 Sun, 21 Mar 99 13:13:03 EST
Contents:
Re: CRYPTOGRAPICALLY USEFUL HUFFMAN COMPRESSION ([EMAIL PROTECTED])
Re: Testing Algorithm (hash) ([EMAIL PROTECTED])
Re: Random Walk (R. Knauer)
Re: Scramdisk ("hapticz")
Re: Random Walk ("hapticz")
Re: Random Walk ("Trevor Jackson, III")
Re: IDEA algorithm (Robert G. Durnal)
Windows 95/98 encryption?? (HaxAttac)
Requesting Opinions, Clarifications and Comments on Schneier's Statements (sb5309)
Re: Random Walk (R. Knauer)
Re: Random Walk (R. Knauer)
Re: SHS (Sha) (iLLusIOn)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: CRYPTOGRAPICALLY USEFUL HUFFMAN COMPRESSION
Date: Fri, 19 Mar 1999 22:55:00 -0600
Reply-To: [EMAIL PROTECTED]
karl malbrain wrote:
>
> [EMAIL PROTECTED] wrote in message <7cjspf$h90$[EMAIL PROTECTED]>...
> >
> >
> > At my website (...) I take an
> >existing adaptive huffman compression program and mod it to
> >make it useful with ENCRYPTION
>
> David, you must be CAREFUL with your usage of MATHEMATICAL terms in our OPEN
> newsgroup. <<Mod>> is a REMAINDER function -- the fractional portion that
> is LEFT-OVER under the similar DIVISION operator. Karl M
I missed the first message in this thread, can anyone tell me the
address
of the web site mentioned in the original message?
ALSO, I remember reading a few years ago about a class of algorithms
that
was being called "comcryption" (cute), short for
"COMpression/enCRYPTION",
that supposedly was used to compress data and encrypt at the same time.
Does anyone know of any work that was actually done, or was it all just
snake oil and blather? Any references will be appreciated. Thanks in
advance.
N.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Testing Algorithm (hash)
Date: Sat, 20 Mar 1999 23:26:43 GMT
> _Applied Cryptography_ is an excellent b-day present. Whomever it is
> that's giving it to you has good taste. :-)
Well I hope my mother will pick it up for my 17th (April 7th :) ). It seems
kinda nerdish, but hey it's what I like :)
BTW, is that book really that good? I have only heard good things about it,
which is why I want to get it. Is there anything I should know about it
first? (Any errata?)
Thanks,
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random Walk
Date: Sun, 21 Mar 1999 11:42:25 GMT
Reply-To: [EMAIL PROTECTED]
On Sun, 21 Mar 1999 05:23:14 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>> >> There is no statistical test to decide if a keystream is crypto-grade
>> >> random. Therefore ALL applications of statistical tests for that
>> >> purpose are inappropriate and their results misinterpreted.
>That's wrong. Statistical tests, properly applied and administered,
>can provide information useful in judging the likelihood of various
>properties of a sequence.
I disagree. The problem is that you must assign an a priori
probability that you do not know in order to make sense of the tests.
That snake oil might be enough to satisfy the amateurs, but it doesn't
fool physicists.
For someone like you who claims to understand such arcane concepts as
Hidden Markov Models, you should most certainly undertand that even
the slightest deviation from prefect symmetry will upset the random
walk catostrophically. Even for p = q = 1/2, there are many anomolies
in the random walk that defy both naive intuition and statistical
models based on infinite steps. Origin crossing is but one of those
"bizarre abberations" which defies the false intuition of the "law of
averages" - whatever that is.
Statisitcal testing of keystreams for apparent randomness is pure 100%
virgin snake oil from the first squeezings.
>The claim that cryptographic security requires a truly random
>physical process is also wrong.
I never said it did. In fact, we know that it is impossible to make a
"Perfect TRNG". So now the question is how do you make a "nearly
perfect TRNG", and how do you know it is "nearly perfect"?
One consideration is that if there is bias (say, p >q), we know the
random walk will be adversely affected, which could result in a
cryptabalyst being able to break the ciphers. It would seem,
therefore, that the design of the TRNG should cause p < q for some
period of generation, to offset the effects of p > q. Whether this is
applicable and, if so, how it would be accomplished is something I am
not equipped to address. I can only ask questions, not answer them.
Maybe the best you can do is shut the TRNG down often, disturb it in
some manner - like removing the radioactive source or changing out the
diode - so that it becomes a physically different device, however
slightly. Or maybe you could put it in an oven and blindly change the
temperature setpoint often. Whatever.
> Actual military-grade systems
>don't normally incorporate "true" (physical) randomness, yet
>they have proven quite secure, for example not having been
>broken (so far as is known to the US) for several decades.
I accept that fact. The cyclotomic generators are supposed to be
especially immune to known attacks based on number theoretic
considerations.
>Even the old electromechanical SIGABA wasn't broken during its
>long operational lifetime.
Yeah, but cryptanalysts back then didn't have today's technology at
their disposal. I am sure that the Caesar cipher was a formidible
challenge 2000 years ago, otherwise Caesar would not have used it.
>There are measures of cryptosecurity, such as required work
>factor to recover a certain expected fraction of the plaintext
>information a certain expected fraction of the time. With
>some designs, this can be reliably estimated.
Yeah, with the ever-present caveat that new technology is always on
the horizon which will compromise even the best systems that are not
proveably secure.
>The main problem with the notion of using physically random
>key streams is the coordination required between sender and
>receiver. If one of them generates the key and sends it to
>the other, to maintain security nearly as much key material
>is needed to send the key as is being sent. The alternative
>is to transport the key via secure physical means, such as
>armed courier. This isn't very practical compared to the
>*highly secure* non-physically-randomly-keyed cryptosystems
>actually in use.
We all know about the key management problems inherent in an OTP
cryptosystem. But that does not stop us from addressing the security
issues in terms of cryptanalytic attack. The OTP serves as a
convenient paradigm for discussing the real issues surrounding our
notions of crypto-grade security.
Bob Knauer
"If you think health care is expensive now, wait until it's FREE!"
------------------------------
From: "hapticz" <[EMAIL PROTECTED]>
Subject: Re: Scramdisk
Date: Sun, 21 Mar 1999 08:57:35 -0500
do the usual scandisk/defrag procedure, then check again
--
best regards
[EMAIL PROTECTED]
------------------------------
From: "hapticz" <[EMAIL PROTECTED]>
Subject: Re: Random Walk
Date: Sun, 21 Mar 1999 09:09:24 -0500
like probably forcasting randomness, deriving an exact criteria for the
randomness requires exact criteria for the set that it is derived from.
that may be "snake oil", but there's still a missing element here. presuming
that the ordered set is NOT random itself, the probability of defining the
randomness is also random ;-D
--
best regards
[EMAIL PROTECTED]
------------------------------
Date: Sun, 21 Mar 1999 09:18:14 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Random Walk
R. Knauer wrote:
>
> On Sun, 21 Mar 1999 05:23:14 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
> wrote:
>
> >> >> There is no statistical test to decide if a keystream is crypto-grade
> >> >> random. Therefore ALL applications of statistical tests for that
> >> >> purpose are inappropriate and their results misinterpreted.
>
> >That's wrong. Statistical tests, properly applied and administered,
> >can provide information useful in judging the likelihood of various
> >properties of a sequence.
>
> I disagree. The problem is that you must assign an a priori
> probability that you do not know in order to make sense of the tests.
> That snake oil might be enough to satisfy the amateurs, but it doesn't
> fool physicists.
>
> For someone like you who claims to understand such arcane concepts as
> Hidden Markov Models, you should most certainly undertand that even
> the slightest deviation from prefect symmetry will upset the random
> walk catostrophically. Even for p = q = 1/2, there are many anomolies
> in the random walk that defy both naive intuition and statistical
> models based on infinite steps. Origin crossing is but one of those
> "bizarre abberations" which defies the false intuition of the "law of
> averages" - whatever that is.
>
> Statisitcal testing of keystreams for apparent randomness is pure 100%
> virgin snake oil from the first squeezings.
>
> >The claim that cryptographic security requires a truly random
> >physical process is also wrong.
>
> I never said it did. In fact, we know that it is impossible to make a
> "Perfect TRNG". So now the question is how do you make a "nearly
> perfect TRNG", and how do you know it is "nearly perfect"?
>
> One consideration is that if there is bias (say, p >q), we know the
> random walk will be adversely affected, which could result in a
> cryptabalyst being able to break the ciphers. It would seem,
> therefore, that the design of the TRNG should cause p < q for some
> period of generation, to offset the effects of p > q. Whether this is
> applicable and, if so, how it would be accomplished is something I am
> not equipped to address. I can only ask questions, not answer them.
> Maybe the best you can do is shut the TRNG down often, disturb it in
> some manner - like removing the radioactive source or changing out the
> diode - so that it becomes a physically different device, however
> slightly. Or maybe you could put it in an oven and blindly change the
> temperature setpoint often. Whatever.
Now let's not avoid the issue by obfuscation. The phrase "blindly
change" actually means "randomly change". So, does the rnadomness of
the temperature set point have to be "crypto-grade" or will any old
"random" sequence do the trick?
>
> > Actual military-grade systems
> >don't normally incorporate "true" (physical) randomness, yet
> >they have proven quite secure, for example not having been
> >broken (so far as is known to the US) for several decades.
>
> I accept that fact. The cyclotomic generators are supposed to be
> especially immune to known attacks based on number theoretic
> considerations.
>
> >Even the old electromechanical SIGABA wasn't broken during its
> >long operational lifetime.
>
> Yeah, but cryptanalysts back then didn't have today's technology at
> their disposal. I am sure that the Caesar cipher was a formidible
> challenge 2000 years ago, otherwise Caesar would not have used it.
>
> >There are measures of cryptosecurity, such as required work
> >factor to recover a certain expected fraction of the plaintext
> >information a certain expected fraction of the time. With
> >some designs, this can be reliably estimated.
>
> Yeah, with the ever-present caveat that new technology is always on
> the horizon which will compromise even the best systems that are not
> proveably secure.
>
> >The main problem with the notion of using physically random
> >key streams is the coordination required between sender and
> >receiver. If one of them generates the key and sends it to
> >the other, to maintain security nearly as much key material
> >is needed to send the key as is being sent. The alternative
> >is to transport the key via secure physical means, such as
> >armed courier. This isn't very practical compared to the
> >*highly secure* non-physically-randomly-keyed cryptosystems
> >actually in use.
>
> We all know about the key management problems inherent in an OTP
> cryptosystem. But that does not stop us from addressing the security
> issues in terms of cryptanalytic attack. The OTP serves as a
> convenient paradigm for discussing the real issues surrounding our
> notions of crypto-grade security.
>
> Bob Knauer
>
> "If you think health care is expensive now, wait until it's FREE!"
------------------------------
From: [EMAIL PROTECTED] (Robert G. Durnal)
Subject: Re: IDEA algorithm
Date: 21 Mar 1999 15:07:15 GMT
In <7d1ujv$ljf$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
: I found an IDEA source (may be old, at
: http://rschp2.anu.edu.au:8080/idea.html) and I have 2 questions.
See also: ftp://garbo.uwasa.fi/pc/crypt/idea3a.zip for a very compact
version.
: 1) Are multiplications suppose to be mod 65537?
Yes
: 2) Given Ax = B, how do you calculate the multplicative inverse of A?
: Should it not be A = Bx? It says:
: sXX* = Mutiplicative inverse of sXX
Multiplicative inverse modulo 65537 can be calculated by Euclid's
extended algorithm. See the IDEA code section in AC2.
: sXX# = Additive inverse (this is just a sign flip right?)
Yes
: Thanks,
: Tom
: btw, I will be adding IDEA to my public domain crypto lib.
In what format? What block chaining mode?
===========
My home page URL=http://members.tripod.com/~afn21533/ Robert G. Durnal
Hosting HIDE4PGP, HIDESEEK v5.0, PGE, TinyIdea (link) [EMAIL PROTECTED]
and BLOWFISH in both Windows and mini-DOS versions. [EMAIL PROTECTED]
EAR may apply, so look for instructions.
------------------------------
From: [EMAIL PROTECTED] (HaxAttac)
Subject: Windows 95/98 encryption??
Date: 21 Mar 1999 16:08:44 GMT
Does anyoneknow what kind of encryption win 95 or win98 uses?? I you do please
e-mail me at [EMAIL PROTECTED]
P.S.-has anyone ever heard of compressed charachter set encryption?
------------------------------
From: sb5309 <[EMAIL PROTECTED]>
Subject: Requesting Opinions, Clarifications and Comments on Schneier's Statements
Date: Sun, 21 Mar 1999 21:54:36 +0800
Reply-To: [EMAIL PROTECTED]
In Bruce Schneier's book "Applied Cryptography", 1996, he writes on page
16 :
"A one-time pad might be suitable for a few short messages, but it will
never work for a 1.54 Mbps communication channel".
Questions :
(a) What One-time pad has got to do with the high-bandwidth
communication channel, given in Mr. Schneier's opinion, that it is
unsuitable for long messages ?
or
(b) From what I can understand from Mr. Scheier passages that, where
there is heavy traffic, one-time pad is not practical because it is very
expensice to generate and deliver message keys (and that is why one-time
pad is unsuitable for long messages). How does this point relate to
"1.54 Mbps communication channel" ?
Thanks.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random Walk
Date: Sun, 21 Mar 1999 16:00:42 GMT
Reply-To: [EMAIL PROTECTED]
On Sun, 21 Mar 1999 09:18:14 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>> Maybe the best you can do is shut the TRNG down often, disturb it in
>> some manner - like removing the radioactive source or changing out the
>> diode - so that it becomes a physically different device, however
>> slightly. Or maybe you could put it in an oven and blindly change the
>> temperature setpoint often. Whatever.
>Now let's not avoid the issue by obfuscation. The phrase "blindly
>change" actually means "randomly change". So, does the rnadomness of
>the temperature set point have to be "crypto-grade" or will any old
>"random" sequence do the trick?
I never implied that the distrubance of the TRNG required random
input. Just shutting it off periodically could cause it to shift
slightly about some mean point centered about p = q= 1/2.
But that brings up an interesting question (to me, at least). What if
you had a two RNGs and used one to seed the other. Included in the key
would be the occurance of the seed change. PRNG1 one would have its
key K1 and it would be used to build the key for PRNG2. After a
sequence of length N was generated by PRNG2 (where N is smaller than
the period inherent in PRNG2), the next key from PRNG1 would be used
to seed PRNG2. Thus, K1 and N would be the overall key for the cipher.
This process could be repeated endlessly. If you wanted, you could
have multiple values for N specifying subsequent occurances of the key
change.
Or perhaps there could be a two-key PRNG, where the keys are created
by two other PRNGs, and key changes are asynchronous. How could a
cryptanalyst ever hope to figure out such a system if the PRNGs were
strong to begin with?
In a third variation of that theme, what if you encrypted a 128-bit
IDEA session key with a 128-bit IDEA cipher and used that key to
encrypt the message with a 128-bit IDEA cipher. Then you would send
the combination of the 128-bit session key and the ciphertext. Since
the session key and its encryption are of the same length, it is
proveably secure regardless of what the session key is, and each
cipher you send will have a new key, thus thwarting cryptanalytic
attacks on the main cipher.
Bob Knauer
"If you think health care is expensive now, wait until it's FREE!"
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random Walk
Date: Sun, 21 Mar 1999 15:41:28 GMT
Reply-To: [EMAIL PROTECTED]
On Sun, 21 Mar 1999 09:09:24 -0500, "hapticz" <[EMAIL PROTECTED]>
wrote:
>like probably forcasting randomness, deriving an exact criteria for the
>randomness requires exact criteria for the set that it is derived from.
>that may be "snake oil", but there's still a missing element here. presuming
>that the ordered set is NOT random itself, the probability of defining the
>randomness is also random ;-D
Li & Vitanyi make that very point in their book on Kolmogorov
Complexity. In fact, it is the essence of the Berry Paradox.
Nevertheless, randomness can be specified in terms of the process
which creates random numbers for a specific application. For example,
randomness in Chaitin algorithmic information theory is embodied in
the notion of indeterminancy of his halting probability, Omega. Also,
radioactive decay in quantum mechanics is a process that is truly
random, and comes from the second order pertrubation theory of
spontaneous emission.
For crypto, a random number is one produced by a process which is
capable of generating all possible finite sequences equiprobably,
namely in an independent and equidistributed manner. We realize that
it is impossible to make an actual device that meets that
specification *perfectly*, just as it is impossible to make a wheel
that meets the specification for perfect circularity.
But that does not make the specification useless, any more than the
reality of less-than-perfect wheels makes the specification of perfect
circularity useless. Furthermore, it does not make it impossible to
build a device that is nearly perfect enough to satisfy the prime
directive of crypto, namely prevent the cryptanalyst from obtaining
reasonable certainty that he has decrypted your intended message.
In fact, there are those who argue that you can build a PRNG that
comes very close enough to fullfilling the specification for
generating random numbers that will thwart all known cryptanalytic
attacks. For example, cyclotomic generators are claimed to be of this
variety.
Bob Knauer
"If you think health care is expensive now, wait until it's FREE!"
------------------------------
Date: 21 Mar 1999 18:05:28 -0000
From: iLLusIOn <Use-Author-Address-Header@[127.1]>
Subject: Re: SHS (Sha)
=====BEGIN PGP SIGNED MESSAGE=====
>Well I am used to the simplicity of Dr. Rivest. Oh well. I like clear step
>by step examples. There wasn't.
>
>If you could provide clean documented (read: commented) source code, I would
>like to see it.
I sent a copy of it to your @my-dejanews.com email address.
//iLLusIOn
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.alias.net.
Date: Sun Mar 21 18:05:17 1999 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQEVAwUBNvU06E5NDhYLYPHNAQF67gf/Reh7H7RY0qhuRVkZt8F+wDEmUnbsexPD
XMgyK83tVdl8O9QnWVOoz0hx3cF5oiZI5qasAujIxFAo4CyKgDgsBF6zyOeVUcbh
4kh/biHO3YL6MQPxZXmGQZsRmYH08H5A9C0MR6Mwyrj/uw1ENZjtiUQqEZorKAju
1D9Us/k6+f7IKvmQpQTiGTN4oGRNT6Wb2F86MlWE52E88m+BsDjNvY2RO8RRSZzN
AWHi8YcbOceIuiKzKNSZlHVc3Zz3g7uottdPMt2GR8A5rCr/WipwhPOiXfgyo6I1
A/gNHk10NcKVcpO9oPP1gc7LSwJLQJR5uW2fN+ybI8ziHDTNu+BN4A==
=TYpL
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
