Cryptography-Digest Digest #113, Volume #9 Sat, 20 Feb 99 16:13:02 EST
Contents:
Re: Benchmarks (fungus)
Re: Randomness of coin flips (Herman Rubin)
Re: True Randomness (Herman Rubin)
SkipJack vs RC2 ("jmp")
Re: Randomness based consciousness?. (Was: Re: *** Where Does The (Herman Rubin)
Looking for proof on whitening (Scott Fluhrer)
Re: True Randomness ("karl malbrain")
same key ([EMAIL PROTECTED])
Re: Looking for proof on whitening (Scott Fluhrer)
Re: Snake Oil (from the Feb 99 Crypto-Gram) (David Hamilton)
Re: Randomness of coin flips (R. Knauer)
Re: Standard fileheaders for encrypted files ("Jay")
Re: Looking for proof on whitening (Sandy Harris)
Re: same key (Mr. Tines)
Re: Telephone Encryption ("Steve Sampson")
Standard fileheaders for encrypted files (Kiril Kesarev)
----------------------------------------------------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Benchmarks
Date: Sun, 21 Feb 1999 00:33:51 +0100
Michael Scott wrote:
>
> (3) You say that "Pentiums have a built-in math processor that is used
to
> speed up modular exponentiations such as those in traditional DH. The
Math
> coprocessor is not used to speed up ECDH operations in this benchmark".
> Please explain.
An obvious lie (or truth bending). The math coprocessor cannot be used
to work with the large numbers as used in real-life cryptography.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: Randomness of coin flips
Date: 20 Feb 1999 08:08:39 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On Fri, 19 Feb 1999 01:30:13 -0500, Nicol So <[EMAIL PROTECTED]>
>wrote:
................
>The concept of True Randomness we are using here on sci.crypt comes
>from crypto itself. A True Random Number is one that is produced by a
>True Random Number Generator (TRNG), which is a process that is
>capable of generating all possible finite sequences equiprobably.
If this is your definition, it is in the same class as the
frictionless bearing, the perfect engine, and other such
entities which are ideals only, and cannot exist in reality.
The best one can do is to produce ways of generating information
by physical processes which is close, and to test for the
operation of Murphy's Law.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: True Randomness
Date: 20 Feb 1999 08:17:09 -0500
In article <W0lz2.100$[EMAIL PROTECTED]>,
karl malbrain <[EMAIL PROTECTED]> wrote:
>Herman Rubin <[EMAIL PROTECTED]> wrote in message
>news:7akljp$[EMAIL PROTECTED]...
>>Even if one has a "perfect" result of a quantum process, it gets
>>somewhat distorted through the measuring or recording equipment.
>I'm a little rusty after 30 years, but wasn't EISENBERG's point that
><<perfect>> results are absolutely/completely distorted??? Karl M
The amount of distortion depends on the accuracy wanted.
The imperfections of the recording instrument are, for
the purposes wanted, far greater than those of the quantum
processes.
The success of digital devices is due to the fact thet they
are of LOW thermodynamic efficiency, so high precision can
be achieved, but still much care must be taken to avoid
signal conflicts.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: "jmp" <[EMAIL PROTECTED]>
Subject: SkipJack vs RC2
Date: Fri, 19 Feb 1999 09:44:13 -0500
Am I the only one who has noticed the important similarities between the
SkipJack algorithm and Rivest's RC2???? Is this a coincidence or not????
They were both developed around 1987-90 and Rivest has had the OK to export
RC2 and RC4 before the rest of us. I am not making any accusation, but it is
funny.
jmp
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Crossposted-To:
sci.skeptic,sci.philosophy.meta,sci.psychology.theory,alt.hypnosis,sci.logic
Subject: Re: Randomness based consciousness?. (Was: Re: *** Where Does The
Date: 20 Feb 1999 08:26:42 -0500
In article <[EMAIL PROTECTED]>,
Aaron Boyden <[EMAIL PROTECTED]> wrote:
>David Vivash wrote:
>> Godel's incompleteness theorem implies that all logical systems of any
>> complexity are, by definition, incomplete; each of them contains,
>> at any given time, more true statements than it can possibly prove according
>> to its own defining set of rules.
>Goedel's incompleteness result does not apply to first-order predicate logic, a
>quite powerful and complex system. Indeed, if I recall correctly, Goedel himself
>produced one of the proofs of the completeness of first-order logic. I'm also a
>little vague on why you say it's "by definition" that the Goedel incompleteness
>theorem applies to those logical systems it does cover (specifically those
>powerful enough to contain Dedekind's axioms of arithmetic as theorems). Finally,
>though I suppose you might evade this point by a sufficiently cunning definition
>of "complexity," any inconsistent logical system is complete.
Incompleteness here is not the negation of completeness.
Completeness means that any consistent set of axioms has a model.
Incompleteness means that any consistent set of axioms in a
system adequate to do Peano arithmetic (the positive integers,
with addition, multiplication, and induction) has propositions
which can be neither proved nor disproved in the system.
Both of these were shown by Godel to hold for the first-order
predicate calculus.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Looking for proof on whitening
Date: Sat, 20 Feb 1999 17:17:28 GMT
Hi all,
I believe that it has been proven that applying
whitening [1] to a block cipher makes brute force
searches more difficult by a factor of 2**N (where
N is the block size).
Does anyone have a pointer to the paper where
this is proven?
[1] Whitening is the process of adding 2*N key bits
to the key, and xoring the plaintext with N of
the additional key bits before the block cipher,
and xoring the result with the other N
additional key bits to form the ciphertext
--
poncho
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: True Randomness
Date: Sat, 20 Feb 1999 09:51:15 -0800
Herman Rubin <[EMAIL PROTECTED]> wrote in message
news:7amckl$[EMAIL PROTECTED]...
>The amount of distortion depends on the accuracy wanted.
>The imperfections of the recording instrument are, for
>the purposes wanted, far greater than those of the quantum
>processes.
No, I believe that EISENBERG based his uncertainty principle on what can be
(SHOULD BE) DETERMINED in general. The cryptographic result desired from
quantum mechanics are extermely accurate, precisely determined, measurements
of events. I don't think you will escape CHAOS/COMPLEXITY with this
approach. Karl M
------------------------------
From: [EMAIL PROTECTED]
Subject: same key
Date: Sat, 20 Feb 1999 17:52:48 GMT
Hi, i would like to know why the secret key and the public key have the same
key ID and the same key FingerPrint.
Thanks!
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: Looking for proof on whitening
Date: Sat, 20 Feb 1999 19:25:06 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Sandy Harris) wrote:
>Scott Fluhrer <[EMAIL PROTECTED]> writes:
>
>> I believe that it has been proven that applying
>>whitening [1] to a block cipher makes brute force
>>searches more difficult by a factor of 2**N (where
>>N is the block size).
>>
>> Does anyone have a pointer to the paper where
>>this is proven?
>>
>>
>>[1] Whitening is the process of adding 2*N key bits
>> to the key, and xoring the plaintext with N of
>> the additional key bits before the block cipher,
>> and xoring the result with the other N
>> additional key bits to form the ciphertext
>
>Of course, if I have several known plaintext/ciphertext
>pairs Pn/Cn and the algorithm is:
>
> Cn = k2^E(k1,(Pn^k0))
>
>where ^ is XOR and k0, k2 are the whitening keys,
>then it looks as if an attacker can fairly easily play
>with the eq'ns to get rid of k2 and come up with a
>search whose difficulty is only the 2**N you've
>quoted.
Yes. You can also derive this using the standard
meet-in-the-middle attack, with optimizating out
the large memory device (because of the group
properties of XOR).
>
>Proving that there isn't some attack much better than
>that on such a cipher would be an interesting result.
That was exactly what I thought was proven (obviously
making some assumptions on the properties of the
block-cipher itself)
>
>Ron Rivest's paper on DESX would be one reference
>on this.
This is exactly what I'm looking for. Where was it
published? Where can I get a copy?
--
poncho
------------------------------
From: [EMAIL PROTECTED] (David Hamilton)
Subject: Re: Snake Oil (from the Feb 99 Crypto-Gram)
Date: Sat, 20 Feb 1999 17:19:13 GMT
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
> Sorry Bruce but longer key lengths are better. But the fact that a
>key is long does not nesecciarly mean that it is strong.
Haven't you contradicted yourself? By the way, have you broken IDEA yet?
> You just have
>a prejiduice towards short key systems so the NSA and folks like you
>can stay in business.
It's more likely to be a prejudice towards reality.
> Actully cracking contests are quite good because certain contests can
>be set up to show how strong a cipher is compared to others. Like my
>contests.
And if competent cryptographers don't enter, what does this prove?
>David Scott
>self appointed cyrpto expert and one man stand alone team.
>I would of commented on more but the note was to bloated.
>any way for get the crappy military grade crypto get the
>Universe Plus Strength Grade stuff wirtten be me.
Do not trust David A. Scott's cryptography software. It is almost certainly
waker than, eg, PGP. See message-ID: <[EMAIL PROTECTED]> in
the thread 'David A. Scott's software v PGP (was Re: Shame!)' posted in
alt.privacy on 31st January or see message-ID:
<[EMAIL PROTECTED]> in the thread 'Re: Encryption Basics'
posted in sci.crypt on 19th December for details.
David Hamilton. Only I give the right to read what I write and PGP allows me
to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179 Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<[EMAIL PROTECTED]>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with 2048 bit RSA key
iQEVAwUBNs7obMo1RmX6QSF5AQF26wf/XAmorjeY97aGpis9XT+GwIAODRyMaRMq
C72ndV19Mg9nYSyMFNOfyNYjTWm6klWPA1/3yJovI4FcAnOpNvOBFfvhzHTwrO2+
ryHFq2Hs+OkpavuYxjjujbMWij51yspLd30zbWx+C6qX1SgUcP60pF8SyVEsHuCK
6OSD5EuOykxHHxGYf1xvKyFDubcJZAXjqXQNU0pCcrbtE4EPx/48KW2ozWneYkry
/CfDeNwasehuw/rsQbHNZMESayLVLjFhG6AcdI9EIWH1KpaJ4fbaZBkfqcY5BQzo
F7gouqiU7ZVdbwkqTTnWQp4n0rZn3bHoME8bOkuwqfkhusoxy2abJw==
=wD1A
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Randomness of coin flips
Date: Sat, 20 Feb 1999 16:44:20 GMT
Reply-To: [EMAIL PROTECTED]
On 20 Feb 1999 08:08:39 -0500, [EMAIL PROTECTED] (Herman
Rubin) wrote:
>>The concept of True Randomness we are using here on sci.crypt comes
>>from crypto itself. A True Random Number is one that is produced by a
>>True Random Number Generator (TRNG), which is a process that is
>>capable of generating all possible finite sequences equiprobably.
>If this is your definition,
It is not MY definition - it is the definition of those on sci.crypt
who participated in the discussions about crypto-grade randomness a
year ago and recently. It is the result of a prevailing consensus
gleaned from a set of threads that ran over a thousand posts and drew
wide ranging participation.
BTW, since you are a statitician, maybe you can comment on this: How
does that definition above differ, if any, from a Uniform Bernoulli
Process (i.e., p = 1/2)? For some reason that I cannot recall, the UBP
was rejected as a definition for a TRNG.
Remember that the term "TRNG" as used here applies only to
crypto-grade randomness, not the notions of randomness in other
fields. For example, algorithmic complexity randomness does not apply
to crypto, since it distinguishes between "regular" and "irregular"
strings, whereas there is no such distinction in crypto.
> it is in the same class as the
>frictionless bearing, the perfect engine, and other such
>entities which are ideals only, and cannot exist in reality.
According to that there could never be a wheel, since a Perfect Circle
cannot exist in reality. In fact a Perfect Circle cannot even exist
mathematically, since there are infinitely many points on the locus
that are uncomputable.
There are TRNG designs, complete with audits and diagnostics, which
can produce crypto-grade random numbers. One such set are based on
Quantum Mechanical measurements, and are as secure as you want to make
them if you are willing to expend the effort to do so.
Crypto-grade security does not require 100.0 % security, since in the
real world work effort and the amount of information leakage need to
be taken into account. If you can demonstrate that a TRNG is secure to
a level sufficient to meet the needs of the cryptosystem it will be
used with, then that is secure in the sense of crypto-grade security.
If you can demonstrate that, then you have a proveably secure system,
even if the proof involves experimental tests.
After all, the goal of crypto it to prevent a crypanalyst from
decrypting your messages, and if that can be accomplished with even a
small amount of information leakage, that is good enough. That's the
same design philosophy for making wheels that work in the real world,
despite the fact that a Perfect Circle does not exist.
>The best one can do is to produce ways of generating information
>by physical processes which is close, and to test for the
>operation of Murphy's Law.
Is that your notion of how experimental science works?
What if there is no exhaustive set of tests for every possible
instance of Murphy's laws? In fact it is a tenent of probability
theory that you cannot apply all statistical tests on any given
number, since there is no number that can pass all statistical tests
for pseudo-randomness (cf. Li & Vitanyi, op. cit.).
Bob Knauer
"Never Trust Anyone Who Doesn't Know How To Compute!"
------------------------------
From: "Jay" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Standard fileheaders for encrypted files
Date: Sat, 20 Feb 1999 14:58:10 -0500
Kiril Kesarev wrote in message <[EMAIL PROTECTED]>...
>Is there any standardized fileformat for encrypted files which
>indicates whether the file is encrypted? The standard I am looking
>for should not be application-specific, but an official government
>standard.
>
>The reason for the above question is that exportable crypto should
>not be easily modifiable to support longer keys. This implies that
>multiple encryption must be blocked. The problem is that if I write
>exportable software which blocks multiple encryption, the blocking
>does not extend to other encryption software. An encrypted file can
>be encrypted a second and third time with other programs.
>
Why on earth are you adding restrictions to yourself?? I have never heard of
a case where the gov required this, why are you trying to add it?
There is no such standard (thankfully) and hopefully will never be. Even if
there were, a user need only do a simple XOR or similar operation to hide
the header, to be reversed at decrypt time. This is, of course one of the
unworkable problems that is not discussed in the 'crypto limits' crowd,
but, hell, that's their problem, not mine.
Jay
------------------------------
From: [EMAIL PROTECTED] (Sandy Harris)
Subject: Re: Looking for proof on whitening
Date: Sat, 20 Feb 1999 18:59:45 GMT
Scott Fluhrer <[EMAIL PROTECTED]> writes:
> I believe that it has been proven that applying
>whitening [1] to a block cipher makes brute force
>searches more difficult by a factor of 2**N (where
>N is the block size).
>
> Does anyone have a pointer to the paper where
>this is proven?
>
>
>[1] Whitening is the process of adding 2*N key bits
> to the key, and xoring the plaintext with N of
> the additional key bits before the block cipher,
> and xoring the result with the other N
> additional key bits to form the ciphertext
A proof that this makes brute force search harder by
2**(2N) is trivial. If the attack is to try all possible keys
(which brute force is, by definition) then adding 2N
extra key bits increases the number of possibilities
by 2**(2N) and therefore makes the attack that much
slower.
Of course, if I have several known plaintext/ciphertext
pairs Pn/Cn and the algorithm is:
Cn = k2^E(k1,(Pn^k0))
where ^ is XOR and k0, k2 are the whitening keys,
then it looks as if an attacker can fairly easily play
with the eq'ns to get rid of k2 and come up with a
search whose difficulty is only the 2**N you've
quoted.
Proving that there isn't some attack much better than
that on such a cipher would be an interesting result.
Ron Rivest's paper on DESX would be one reference
on this. Several of the AES ciphers, including Twofish,
also use whitening.
------------------------------
From: Mr. Tines <[EMAIL PROTECTED]>
Subject: Re: same key
Date: 20 Feb 1999 20:30 +0000
###
On Sat, 20 Feb 1999 17:52:48 GMT, in <7amspf$4mn$[EMAIL PROTECTED]>
[EMAIL PROTECTED] wrote.....
> Hi, i would like to know why the secret key and the public key have the
same
> key ID and the same key FingerPrint.
I'm presuming you're talking PGP here. The answer is that the
SecretKey packet has the following format
secret key header
public key packet contents
extra secret key information
and in each case, the key ID and fingerprint are computed on
the public information. This is for two main reasons
1) if we computed a value based on the secret key information,
no-one else would be able to tell that they referred to the
same key
2) it avoids leaking any more information about the secret.
-- PGPfingerprint: BC01 5527 B493 7C9B 3C54 D1B7 248C 08BC --
_______ {pegwit v8 public key =581cbf05be9899262ab4bb6a08470}
/_ __(_)__ ___ ___ {69c10bcfbca894a5bf8d208d001b829d4d0}
/ / / / _ \/ -_|_-< www.geocities.com/SiliconValley/1394
/_/ /_/_//_/\[EMAIL PROTECTED] PGP key on page
### end pegwit v8 signed text
cb3175284864418196ca13dfac3f363c44324485c263876e2c575fabe4bc
8992ce398c267b65c1bf5d43c072fcc307161988d7265200071fb12865dc
------------------------------
From: "Steve Sampson" <[EMAIL PROTECTED]>
Subject: Re: Telephone Encryption
Date: Fri, 19 Feb 1999 21:17:37 -0600
>Perhaps you can comment on why there is no greater demand. By now the
>public must be aware that their phone conversations are being
>monitored by any number of different entities, and that could prove
>costly in certain venues, like the corporate environment.
Most people don't care. They hop from job to job anyway. You don't have
to spy on a company, you hire their staff. Netscape uses this policy. They
can't recruit the right people, so they buy companies that have the people
they need. At least they did until AOL bought them out.
>The boxes are extremely well built and VERY sexy.
>
>Hmm, maybe I need to ask you to send me that reference after all,
>since I am always a sucker for sexy, well built devices. :-)
That better mean, they have a women's voice embedded in them, which
comforts me while the fricking wife drones on and on about my playing
Golf every Saturday, while she stuffs her face with another pound cake...
------------------------------
From: Kiril Kesarev <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Standard fileheaders for encrypted files
Date: Sat, 20 Feb 1999 21:08:49 +0200
Is there any standardized fileformat for encrypted files which
indicates whether the file is encrypted? The standard I am looking
for should not be application-specific, but an official government
standard.
The reason for the above question is that exportable crypto should
not be easily modifiable to support longer keys. This implies that
multiple encryption must be blocked. The problem is that if I write
exportable software which blocks multiple encryption, the blocking
does not extend to other encryption software. An encrypted file can
be encrypted a second and third time with other programs.
Kiril
--
------------------------------
** 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
******************************
