Cryptography-Digest Digest #302, Volume #11 Fri, 10 Mar 00 23:13:01 EST
Contents:
Re: NIST, AES at RSA conference ("Douglas A. Gwyn")
Re: ZIP format is gone in the past. ("Douglas A. Gwyn")
Re: encrypting to unknown public key? (Eric Norman)
Re: Big Float project ("Douglas A. Gwyn")
Re: How does % operator deal with negative numbers? ("Douglas A. Gwyn")
Re: NIST, AES at RSA conference (Terry Ritter)
Re: why xor?(look out,newbie question! :) ("Douglas A. Gwyn")
Re: Universal Language ("Douglas A. Gwyn")
SSLeay application ("����ö")
Re: NIST, AES at RSA conference (Bryan Olson)
Re: Mark Twain's advice for Markku J. Saarelainen ("Thomas Keske")
Blind-recipient-hiding (was Re: encrypting to unknown public key?) (David Hopwood)
Re: How does % operator deal with negative numbers? (David Hopwood)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sat, 11 Mar 2000 02:20:10 GMT
Terry Ritter wrote:
> ... Whatever "simpler, faster"
> function you like can be one of the three ciphers in a cipher stack.
> In practice, that stack will be at least as strong as your cipher.
If this was purely a matter of probabilities, sure, but not always.
Suppose one of the ciphers were FG and the other were G'H,
where G and its inverse G' are much "stronger" subsystems
than F and H. The composing these ciphers yields FH, which
is evidently much weaker than either of the component ciphers.
You might counter that one should not choose such ciphers, but
the substructure of a cipher might not be immediately apparent.
This problem, which is *probably* not too bad for composition
of just a few randomly-chosen relatively simple component
ciphers from a large pool of different principles of operation,
becomes a dominant issue as the complexity increases.
> Your remaining complaint is that the other two ciphers may have
> an execution cost that you don't want to pay.
Without judging what Bernstein's remaining complaint is,
mine would be that this does not seem to be the most
effective way of utilizing the available key bits.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: ZIP format is gone in the past.
Date: Sat, 11 Mar 2000 02:24:54 GMT
finecrypt wrote:
> It's more and more people prefer to use self-extracting executables
> instead of zip archives.
Sure, we love to run foreign executables in our local system context.
Also, it is a delight to receive an Intel Windows executable image on
a non-Intel Windows platform.
------------------------------
From: Eric Norman <[EMAIL PROTECTED]>
Subject: Re: encrypting to unknown public key?
Date: Fri, 10 Mar 2000 20:31:31 -0600
David A Molnar wrote:
> * The blinding function can be evaluated efficiently without
> knowledge of the secret key SK. So anyone can create a blinded
> version of a public key they posess.
>
> * The encryption function E() takes as input a message M and
> any blinded public key BK or the original public key PK.
> On these inputs it computes a ciphertext C which can be
> decrypted by the decryption function in conjunction with a
> secret key SK. SK is static and independent of whatever value
> of BK or blinding factor F is used.
>
> So we have
> C = E(BK, M)
> and M = D(SK, C) for all BK used to encrypt C.
>
> * It is infeasible to determine PK from BK without knowledge
> of F or access to a decryption oracle.
> (because clearly you can just encrypt something, then try
> to decrypt it using the decryption oracle)
>
> * The blinding function B() "looks random" - it should be
> infeasible to guess any other BK or any other F given one
> (BK, F) pair. It should be infeasible to create another BK
> or another F given only BK but not the original PK.
>
> Anyone seen anything like this before?
Perhaps you would like to read the thesis of Stefan Brands.
Start here:
http://www.xs4all.nl/~brands
--
Eric Norman
"Congress shall make no law restricting the size of integers
that may be multiplied together, or the number of times that
an integer may be multiplied by itself, or the modulus by
which an integer may be reduced".
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Big Float project
Date: Sat, 11 Mar 2000 02:42:37 GMT
Mike Rosing wrote:
> z^2 + 3z - 5 = 0 is an equation which we can solve for z.
Sure, but we don't need complex numbers for that.
A better example is z^2 + 3z + 5 = 0, which has no solutions
among the set of real numbers, but has two solutions among
the set of complex numbers. Indeed, this is essentially the
original motivation for inventing complex numbers. The
complex field is the essentially unique extension of the
real number field that preserves the common algebraic
properties.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.javascript
Subject: Re: How does % operator deal with negative numbers?
Date: Sat, 11 Mar 2000 02:49:11 GMT
Hal Pawluk wrote:
> That's because they call it 'modulo' but make it act like
> 'remainder'
This is a legacy from C. The original reason was to allow
faster code to be generated on many platforms; otherwise
they would have to check for the negative case and adjust
the natural remainder from a machine DIV instruction, even
when at run time most uses of % would not actually encounter
negative operands.
I think it is a pity that Java didn't clean up some things
like this; it missed a golden opportunity.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Sat, 11 Mar 2000 02:57:32 GMT
On Sat, 11 Mar 2000 02:20:10 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>> ... Whatever "simpler, faster"
>> function you like can be one of the three ciphers in a cipher stack.
>> In practice, that stack will be at least as strong as your cipher.
>
>If this was purely a matter of probabilities, sure, but not always.
>Suppose one of the ciphers were FG and the other were G'H,
>where G and its inverse G' are much "stronger" subsystems
>than F and H. The composing these ciphers yields FH, which
>is evidently much weaker than either of the component ciphers.
This has previously been discussed at length. It is a normal part of
cryptography do deal with imperfections: for example, we cannot prove
any practical cipher is secure. We also cannot prove that
multiciphering necessarily helps. But we can say that it almost
always does, which is in fact more than we can say about ciphers.
>You might counter that one should not choose such ciphers, but
>the substructure of a cipher might not be immediately apparent.
The substructure of an exact inverse would not be apparent? Why not?
It should virtually cry out: We know what that inverse looks like, it
is the deciphering program.
>This problem, which is *probably* not too bad for composition
>of just a few randomly-chosen relatively simple component
>ciphers from a large pool of different principles of operation,
>becomes a dominant issue as the complexity increases.
Nonsense. If we want, we can easily avoid using the same cipher in
two contiguous slots.
I have always stated that the keys should be independent. Even if the
ciphers are inverses, they are unlikely to be inverses when they are
using different keys. The result would be sort of like Triple-DES.
>> Your remaining complaint is that the other two ciphers may have
>> an execution cost that you don't want to pay.
>
>Without judging what Bernstein's remaining complaint is,
>mine would be that this does not seem to be the most
>effective way of utilizing the available key bits.
As I have said repeatedly, the issue is *not* key bits. We expect
that each and every cipher will have enough keying; we don't need any
more keying.
[ But nowadays we have plenty of storage for keys, and could easily
use keys of 4KB or larger with almost no negative impact. ]
What we do need is the ability to function securely in the presence of
broken ciphers. Multiciphering helps.
What we do need is the ability to terminate any successful break which
may have occurred. That requires us to change ciphers.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: why xor?(look out,newbie question! :)
Date: Sat, 11 Mar 2000 03:03:06 GMT
Mok-Kong Shen wrote:
> I haven't heard of hi-square test. Do you mean chi-square test?
Yes, he must.
> I don't yet see how you can use that to test independence.
Basically, Pearson's chi-square statistic can be used via
the probability of it having so large a value if the hypothesis
of independence were true (which can be looked up in tables,
or computed fairly simply). If that probability is very small,
then the test casts doubt on the hypothesis, which can be taken
as evidence in favor of the opposite hypothesis (dependence)
in the same overall context.
> Note that many textbooks only use the notion of independence and
> assume that in a number of theorems but don't go to the topic of
> how one can test that property.
You need better textbooks!
Note that your idea of "testing the independence of two bit
sources" needs to be recast in terms of likelihood, not
definite certainty. Even if two random-bit generators were
truly independent, occasionally they will produce highly
correlated stretches of output. So you need to judge from
the data at hand the *likelihood* of independence, which
depends on the probability of such a fluke occurring.
(That's why larger data samples are better than small ones,
usually. With a small sample, there is a relatively large
probability of a fluke, but with a large sample, the
probability can be reduced to a practical impossibility.)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Universal Language
Date: Sat, 11 Mar 2000 03:09:30 GMT
Mok-Kong Shen wrote:
> Logic formalism is probably not good for serving as a base for
> designing a universal 'natural' language. My conjecture is based on
> the fact that even logic programming hasn't yet succeeded to replace
> the classical programming with C++, ADA, etc.
That isn't due so much to the use of logical formalism as it is
to the fact that "logic programming" languages such as Prolog
have radically different goals from procedural languages, also
to the fact that they take an excessive amount of resources to
accomplish many of the things that people want computers to do.
But for things they are good at, logic programming languages
are indeed used enough that there are companies making money
selling implementations of them.
------------------------------
From: "����ö" <[EMAIL PROTECTED]>
Subject: SSLeay application
Date: Sat, 11 Mar 2000 12:21:15 +0900
I would like to develope cryptographic application using SSLeay.
That will does not use the full function of SSLeay.
I would like to only cryptographic modules(crypto algorithms).
Is it possible? Thanks in advance
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sat, 11 Mar 2000 03:20:33 GMT
Terry Ritter wrote:
>
> D. J. Bernstein wrote:
> > You seem to think that there's some magical
> > intermediate stage between simple operations and
> > complete encryption functions. You artificially
> > divide the design of encryption functions into
> > the design of ``ciphers'' from simple operations
> > and then the design of encryption functions from
> > ciphers. You artificially limit your notion of
> > cryptanalysis to the process of studying and
> > breaking individual ``ciphers.''
> Your very use of the terms "Feistel" and "rounds" shows there *is* a
> difference between ciphers and operations: Feistel ciphers generally
> repeat *the* *same* functional rounds over and over and call the
> result secure. Well, call me dubious. I prefer to have multiple,
> distinct ciphering approaches, each of which would be considered
> secure standing alone.
There is the seed of a reasonable proposal there: design a
cipher with three layers each of a different structure and
each somewhat larger than needed to resist all known attacks
absent the other layers. This is a plausible approach to
defending against unknown attacks and a defensible tradeoff
between resources and confidence in security.
But the proposals I've seen from Ritter are for the
arbitrary, or even random composition without regard to the
internals of the individual ciphers. What matters is the
structure of the cipher we actually use, not whether we
choose to view it as one cipher or three. We we want a
cipher that will resist future breaks of certain classes of
ciphers, then we should choose these layers because their
functions are fundamentally different, not because they were
once packaged separately and given different names.
> The issue is not *my* favorite encryption function, the issue is
> *your* favorite encryption function: Whatever "simpler, faster"
> function you like can be one of the three ciphers in a cipher stack.
The issue is encryption function we use. A cipher stack is
a cipher. If we can call a cipher a single point of failure
without consideration of its internals, then the Ritter
cipher stack is also a single point of failure.
> In practice, that stack will be at least as strong as your cipher.
And the square of Terry Ritter can make the same argument
with the same force to justify a stack of three of Ritter's
stacks.
Dan Bernstein is correct: the distinction between building
ciphers from simple operations and encryption functions from
ciphers is artificial. There are reasonable arguments to be
made both for and against using different round structures
and designing more conservatively than most current
proposals. The significant issue is the structure of one's
favorite cipher, not the fact that we can always make it
more complex by adding stuff.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Thomas Keske" <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia
Subject: Re: Mark Twain's advice for Markku J. Saarelainen
Date: Sat, 11 Mar 2000 03:48:45 GMT
>
> "Better to remain silent and though a fool,
> than to speak up and remove all doubt"
>
Frankly, I don't think that the man is a fool, I think
he's playing a game.
The CIA hates newsgroups. They don't want a place
where disgruntled ex-employees could get a forum
and broadcast something to thousands of people that
they aren't supposed to hear.
So, the goal is to drive everybody away with the
impression that only crazies would bother posting
here. It not only drives people away, but it
discredits anything posted that might of real significance,
in a case where the truth strains everyday reality
levels, as with the CIA, the truth sometimes does.
Of course, we *would* all be crazy to post here,
*unless* we understand the game and its goals.
I think that our govt is playing this game on nearly
*all* newsgroups. Some newsgroups get
censored by moderators. Others are flooded with porno.
Others have controversial message disappear
almost as soon as they appear.
Others are crawling with provocateurs who try
to sew divisions and harass everyone into
giving up. Using any single technique all the
time would become too obvious.
Some of this is natural. Much of it isn't.
Tom Keske
------------------------------
Date: Sat, 11 Mar 2000 03:17:03 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Blind-recipient-hiding (was Re: encrypting to unknown public key?)
=====BEGIN PGP SIGNED MESSAGE=====
David A Molnar wrote:
> John Myre <[EMAIL PROTECTED]> wrote:
>
> > Is there any reason why you require the decryption function to
> > work with both a blinded key and the original public key? It
> > would seem easier (i.e., to admit more solutions) without that
> > restriction.
>
> Well, if the same decryption function works in both cases, the
> decryptor may not be able to distinguish between messages encrypted with
> a normal public key, and those encrypted with a blinded public key.
> I have the feeling that this indistinguishability may be a useful
> property, but no concrete protocols as yet.
>
> That being said, what originally motivated the question was that I
> wanted servers in a chain of anonymous remailers to create receipts
> encrypted with the sender's public key. Clearly if they have an
> unblinded public key, then all servers know who the sender is and there
> is no point to using more than one server. With blinded public keys,
> each server can create receipts encrypted with the sender's public key
> without knowing who the sender is. Then these receipts can be posted
> to usenet or something.
For this application, you need both the blinding feature that you've just
described, *and* the "recipient hiding" property described in a sci.crypt
thread from February (ah, I see that you initiated that thread as well :-),
in the same algorithm. Maybe this could be called something like
"blind recipient hiding".
Adding blinding effectively strengthens the original recipient hiding
property, because even the sender does not need to know the recipient
(although we have to trust someone to blind the keys correctly).
It doesn't appear to be important to prevent keys from being blinded
more than once, AFAICS, as long as it isn't possible to infer that two
given public keys are equivalent (i.e. they are blinded versions of the
same key), with non-negligable probability.
There is an attack that appears to apply to all such schemes, although
it could be mitigated by careful protocol design: if Bob and Robert
(possibly the same user) have blinded public keys BK_Bob and BK_Robert,
then Alice could send a message encrypted using BK_Bob to Robert, and
observe from his actions whether he has been able to read it. If he can,
then Bob and Robert are the same. Therefore it's important that recipients
not give any indication of whether they have been able to read a message
or not. Remailer protocols are normally designed so that messages aren't
acted upon for a random length of time after being received (to prevent
correlating inputs and outputs), which would help against this attack.
Using a broadcast channel, rather than point-to-point messages would
also probably help.
Given that we need both blinding and recipient hiding, I would suggest
John Savard's scheme with DHAES, using a common modulus (or a common
elliptic curve, or whatever). The random blinding value b should be
uniformly distributed on [1, |G|], where G is the group or subgroup being
used, and |G| is its order. It's important that the group or subgroup be
cyclic (as it is required to be for DHAES), since otherwise some
information is leaked. The common modulus (or curve) is needed so that an
attacker can't distinguish between the distributions of ciphertexts sent
to different users, as we discussed in the earlier thread.
The sender should also do public key validation: if (g, y) is purported
to be a blinded public key, check that both g and y are actually elements
of G (the description of G should be a fixed parameter).
Using different generators for different users doesn't break the basic
recipient hiding property, because g^u (using the notation from the DHAES
paper) is expected to have a uniform distribution on the elements of G,
from the point of view of an attacker; this is true regardless of the
value of g, provided that the public key is valid.
It looks as though it should be quite feasible to create a formal model
of the properties required for a blind recipient hiding PK encryption
algorithm, and prove that this special case of DHAES satisifies it (under
the same assumptions used in the existing DHAES security proofs).
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOMm5/zkCAxeYt5gVAQHxXgf/Yx+rLXoyQGBLKjTxqCtYhVI1AM7gh/Jy
qW+eyPPVF6NhsJ1QtjJl70tGy7UwJZWuxsYWvQGeBwuxJKWhzSkcKWkAsAKhETh/
ftn18yDKDxD4emRrLa3z/f4EXRqCw5+z/5c8UXTWnG03cnyK+nYSbPDVFvW5FNUj
st+t6PKbwbayUgPM+mVbCFMwJ1aO0KMs8KnVHPLNbK9T5lPOBfBcMwoiss10rPZv
/WfGThqzyEBsJrsHrLtfqmd+aQV8Weafb1HQ1gBVcFMh5FqOihVr+VxLQv2+XVbT
XMdJWJBHmRaiXBHKamkZtOlcr5QrvrYWoUjvUmZCvdvjzTNAy1OIEQ==
=mDKV
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 11 Mar 2000 03:29:56 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.lang.javascript
Subject: Re: How does % operator deal with negative numbers?
=====BEGIN PGP SIGNED MESSAGE=====
Paul Rubin wrote:
[...]
> % is usually the "remainder" operation, also called "trunc-mod".
> It's different from the mathematical "modulo" (also called "floor-mod")
> operation.
>
> remainder: a % b = a - (b * trunc (a/b))
> modulo: a % b = a - (b * floor (a/b))
>
> Where: a/b = the real number a/b
> trunc(x) = sgn (x) * (largest integer with absolute value <= |x|)
> floor(x) = sgn (x) * (largest integer <= x)
That should be:
floor(x) = largest integer <= x
> sgn (x) = { 1 if x >= 0, otherwise -1 }
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOMm9kTkCAxeYt5gVAQE2FAf/T9rMDUMyYj1E4NSkT/FK3crvpbiv4X1C
U3Wx6tIdqS3NAUekC3iJFHcCRuD99QscTcBOeSwxBdzD0DwNcZAvhaEMQAVeHR7h
gz510xKyb8N/isCMd9G9AjpovHHPaeSSR2UOzUfQZkJprieuJQ3bxMhmxDZ6oys0
qbqiwcE4eFfEMiyIjTqkaCYx9m7UtlmVY75cDlAdCKHdMrF62oqKlwPGNiXiDA73
R5J+KPDFjcn1XuoHw3hww2Mm3Tk7Js8mcsL+VRJCKp9vnMIhPvGivzN8X2jf7HvP
NAvm3CFiCm8mH/wlX9+qk5ytAT7ZxMgn7/na2xAgXmBA+eO20hzw6g==
=p6YE
=====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
******************************
