Cryptography-Digest Digest #303, Volume #11 Sat, 11 Mar 00 03:13:01 EST
Contents:
Re: NIST, AES at RSA conference (David A. Wagner)
public key encryption ("Marianne Laws")
Re: How does % operator deal with negative numbers? (Paul Rubin)
Re: How does % operator deal with negative numbers? (Bill Unruh)
Re: Server Config: How allow both 128-Bit and 40-Bit browsers ? (Paul Rubin)
Re: Blind-recipient-hiding (was Re: encrypting to unknown public key?) (David
Hopwood)
Blind recipient hiding (was Re: encrypting to unknown public key?) (David Hopwood)
Re: Passphrase Quality ? ("r.e.s.")
Re: Linking Time-Stamping Servers (Ron Skoog)
Re: Birthday paradox (James Muir)
Re: NIST, AES at RSA conference ("Douglas A. Gwyn")
Re: Blind-recipient-hiding (was Re: encrypting to unknown public key?) (David A
Molnar)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: NIST, AES at RSA conference
Date: 10 Mar 2000 20:00:56 -0800
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> 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.
The part left unsaid in your example is that ciphers F,G,G',H are
assumed to be unkeyed. In reality, so long as the ciphers are keyed,
and keyed independently, your concern cannot happen, and the stack will
be as strong as the first one (`the importance of being first').
This leaves open the question of how to build a key schedule so that
round subkeys are effectively random (or, at least, pseudorandom, i.e.,
indistinguishable from the information-theoretic truly-independent case),
but for that I will point you to, e.g., Knudsen's work on TEMK.
------------------------------
From: "Marianne Laws" <[EMAIL PROTECTED]>
Subject: public key encryption
Date: Sat, 11 Mar 2000 15:43:37 +1100
Hi! I am researching public key encryption for a Uni assignment.
Can anyone recommend useful sites on the WWW on the subject.
Thanks for your help in advance,
Marianne.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Crossposted-To: comp.lang.javascript
Subject: Re: How does % operator deal with negative numbers?
Date: 11 Mar 2000 05:10:17 GMT
In article <[EMAIL PROTECTED]>,
David Hopwood <[EMAIL PROTECTED]> wrote:
>That should be:
> floor(x) = largest integer <= x
Oops, yes, that's what I meant. (Editing error). Thanks.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: comp.lang.javascript
Subject: Re: How does % operator deal with negative numbers?
Date: 11 Mar 2000 05:26:25 GMT
In <[EMAIL PROTECTED]> Frank <[EMAIL PROTECTED]> writes:
]I'm trying to write some non-kludgy JavaScript for a simple
] cryptography demonstration. One of the encrypt steps adds
] key%97, so the obvious decrypt step should be (-1*key)%97.
((-1*key)%97+97)%97
]In standard mathematics, -4 modulo 97 should equal 93.
] Instead, Netscape returns -4, Explorer returns 4.
Explorer is wrong in any possible definition.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Server Config: How allow both 128-Bit and 40-Bit browsers ?
Date: 11 Mar 2000 06:14:38 GMT
In article <33by4.95$h21.96311@news>, Phil <[EMAIL PROTECTED]> wrote:
>How can I configure the SSL-Settings of a Webserver (IIS 5.0) to be
>compantible with browsers of 128-Bit keysize AND browsers of 40-Bit keysize
>(often used in Europe) ?
It will work automatically.
>I want to use 128-Bit SSL with 128-Bit Browsers in order to achieve a high
>level of encryption.
>But i'd like to use exactly the same html-pages for all 40-(or 56-) bit
>Browsers too.
>
>QUESTION:
>- Is this impossible ? (if I choose 'REQUIRE 128-Bit encryption' in my
>IIS-Settings)
Choosing "require 128 bit encryption" means 128 bit encryption is required.
If you don't choose "require 128 bit encryption", then other lengths will
also work.
>- How can the webserver dynamically detect which SSL-keysize to use ?
"40-bit encryption" is sort of a misnomer. All the encryption is 128
bits. With "40-bit" browsers, 88 of the bits are revealed in the
clear and only 40 are secret, but that doesn't enter into the
cryptography. So the server does the same thing either way. It
doesn't have to dynamically detect anything.
The browser does this, not the server.
>- Will I have to use two different directories (one with normal encryption
>for 40-bit browsers / and one with 128-bit encryption) ?
No.
------------------------------
Date: Sat, 11 Mar 2000 05:23:54 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Blind-recipient-hiding (was Re: encrypting to unknown public key?)
=====BEGIN PGP SIGNED MESSAGE=====
I wrote:
> 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).
I should have said, "elements of G other than the identity".
(For GF(p), or a subgroup of GF(n) the identity is 1; for an elliptic curve
it is the point at infinity.)
Also, the blinding function should technically do key validation on the
blinded key, and repeat with a different b if it fails - although the
probability of that is so small if the input key was valid, that it should
never happen in practice.
- --
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
iQEVAwUBOMnYBTkCAxeYt5gVAQEopgf+LqrENhPFHkNJYZqMFVAajl4s6lZPpkLs
XRaxmmcRCLJtdTjHJHxKK8++eiFcdeTmtiho2Kzb6O2gPNBTtI4jJyMNc8g8EkNH
NhFea4F69JxJglJ7ZYiiPFkXupOtENQom6bM2vD0sq/MzBvFtdjGTR81ak8Ot4QP
U0vGhiPJr/ti5c/HPjnPmmAvAiQdc1qqUOT8yNKC5yDCCVQVHs3R09qQ1fpinfTg
gpi+NFkf2utRomXNdv3G8H6+nHbhbRNuTrrW2njkmmDxBwg6r3UBD23+afTEtwtD
swn07/3skLXqFgXjw8KAIdO/L14RuqapjPAtLcIxybn1ynxEVnxAUQ==
=brvh
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 11 Mar 2000 06:07:32 +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:
> David Hopwood <[EMAIL PROTECTED]> wrote:
> > # (BK, F) pair. It should be infeasible to create another BK
> > # or another F given only BK but not the original PK.
>
> > The DH-based scheme above doesn't fulfil that requirement, because if
> > (u^b, v^b) is a public key, then so is ((u^b)^b', (v^b)^b'). I can't
> > immediately think of any way to fix that; it seems to be quite difficult.
>
> Argh. You're right, and so is John Myre. I will say right now that
> I thought I was thinking of non-malleability when I stated this
> requirement. That is, when we have ciphertexts, we generally want it to
> be infeasible to create a new ciphertext just by applying some function
> (other than the encryption function) to a current ciphertext we have.
More precisely, non-malleability means that it is not feasible to create
ciphertexts which, when decrypted, give a plaintext that is related to
but not equal to some other target plaintext, when only an encryption of
that target plaintext is known. It is usually required that this be true
under adaptive chosen-ciphertext attack.
(Obviously, it's always possible to create new valid ciphertexts for a
public key algorithm, when the public key is known.)
I think the property you wanted was probably something like this:
Define a blinding tree as a tree with an initial public key at the root,
such that the children of a key are the keys that can be formed from
that key by blinding.
A blind PK encryption scheme has "public key anonymity" if an attacker
cannot feasibly obtain any information (that was not known a priori)
about whether two blinded public keys are in the same blinding tree.
I don't think this is possible under chosen ciphertext attack, because
of the problem of an attacker seeing whether the owner of some public
key can decrypt messages encrypted using a different blinded key, but
it seems to be possible under less powerful attacks. Also, you could
possibly weaken the notion of a (maybe adaptive) chosen ciphertext
attack just enough that this property would be possible under the
weakened version.
For the scheme I described in my other post based on John Savard's
suggestion (call it BRH-DHAES), two keys are in the same blinding tree
if-and-only-if they are equivalent keys, in a particularly strong sense:
the corresponding encryption functions produce exactly the same
distribution of ciphertexts for a given plaintext.
This has some advantages - for example, it means that anyone who is given
a public key can create an arbitrary number of equivalent blinded public
keys from it, and pass them on to other parties, without those parties
being able to tell that they have been given equivalent keys (even if
they collude). Also, the recipient of a message cannot tell which blinded
key the sender used, unless that can be inferred from the contents of the
message.
For other blind encryption schemes, two keys in the same blinding tree
might not be equivalent, because they might require different encryption
and/or decryption functions.
> Might as well play with the mistake, though :
>
> IF you can somehow acheive this requirement, then it seems you can have
> a situation in which parties are "marked" by which blinded key they use
> to encrypt messages. This would be useful in the case of referrals,
> for instance -- if Alice gives Bob a blinded key, and Carol later uses
> the same blinded key, Bob and Carol may be linked. Alice knows she
> gave the key to Bob, so she infers that Bob referred Carol to Alice.
>
> This assumes, *contrary to what I had previously thought*, that someone
> can distinguish encryptions due to blinded public keys from those due
> to normal public keys.
It depends on the specific algorithm. For BRH-DHAES they cannot (but
BRH-DHAES is an "unlimited blinding" scheme, by your definitions below).
> Otherwise the only way to carry out this linking
> seems to be to actually interrogate senders as to what public key they
> use.
>
> So on reflection, there seem to be several choices at least we can make
> about such a "blind encryption" scheme :
>
> (btw, if my terms change from previous messages or if you have better
> terms, please yell)
>
> * "single-blinding" vs. "unlimited blinding"
>
> Whether a blinding of a blinded key produces a valid
> public key ("unlimited blinding") or does not ("single
> blinding").
A single-blinding algorithm has blinding trees that are limited to a
depth of 2 (i.e. the root and its children).
> * Whether or not the sender knows he is using a blinded
> public key. Is there a single E() which takes
> both PK and BK, or are there separate E() for PK and
> for BK?
For BRH-DHAES, no; there is a single E.
> * Whether or not the recipient *knows* a message was
> encrypted with a blinded key. Is there a single D()
> which takes messages encrypted with both PK and BK, or
> is there a separate D'() for BK??
For BRH-DHAES, no; there is a single D (and in fact the distribution
of possible encryptions of a message is provably identical, for
different but equivalent blinded keys). This suggests an additional
choice/property:
* Whether the recipient can distinguish which blinded key
was used to encrypt a message.
> * Whether or not the party which created the blinded key
> can determine which messages were encrypted with that
> key. He can't necessarily see the content - he can just
> see which used "his" value of BK.
For BRH-DHAES, no.
> This might be useful in case Alice is contracting out
> work using both Bob and Carol as agents. Bob and Carol
> give out blinded keys to customers. Then they can simply
> sniff Alice's link to see how much of her traffic is
> due to buisness that they brought in, but can't actually
> read any of Alice's traffic.
> Note that Bob and Carol may not even know that the other
> exists.
I can't see any way to construct a scheme where blinded keys can be
traced in this way using Diffie-Hellman-type keys. Maybe it could
be done using a factorisation-based trapdoor, but it's too early in
the morning for me to think about that now.
- --
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
iQEVAwUBOMnh/TkCAxeYt5gVAQHpDAf/XjFQb3+PmnsLas7c2KOZMRVCiYqZZ5z7
RQF0pzIskr0XrvI+bPM3O5qV9iNXUkmcfWaaM46CRUDwj+Tii2MP3eliG5QEFFYO
vYj/WQ4uCND8esxVazMb8ShZFXRx1cl46eojHjK9Bq8F+u7Jx0hJVkdna3ANcYq4
RHda55OesqM/fNzZtQJwLeM8e/sEfKgb0gKPe0Ih5Exz+f59ofBcvraOFV9pFWWB
cj/lY5W3Agu1cewmkasqLuIc6nhsJ1kyG3tLibuaw/N3Gn7Cp8PGxIIt1QmtWk+Q
DaneORxk9U3n+fG/NmHei6yktafpjtRFJ4aVcRAV25vLo9DfqXvOZA==
=a7Y1
=====END PGP SIGNATURE=====
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Passphrase Quality ?
Date: Fri, 10 Mar 2000 22:35:01 -0800
I figured it was prohibited because of what I mentioned, e.g. touch the =
grid in any way as you read along a path, and even the smallest traces =
may leave the grid advertising the password it's supposed to hide. (In =
trying to judge the security of this method, I think the physical grid =
itself should be regarded as accessible to an opponent.) On the other =
hand, the following esimates suggest that in practice the entropy per =
passsword-character is probably far less than one might naively suppose.
If this method is nevertheless going to be used, I would say to make =
sure that all the grid characters are different, and that the path is as =
complex as possible, as long as you are sure to remember it. In =
particular, don't constrain the path to be connected =
laterally/diagonally. For a grid of m distinct characters, the best =
you could do for an n-character password would be independent uniform =
selection of each character, i.e. log2(m) bits of entropy per =
pw-character. For an 8x8 grid of distinct chars, that's 6 bits/pw-char. =
If you limit the path to be connected laterally/diagonally, then that =
bound drops to about (1/n)log2(64*(6.6)^(n-1))=3D2.7 + 3.3/n, say about =
3 bits/pw-char. This is due to the fact that there are 64 choices for =
the first pw char, and either 3, 5, or 8 possible choices for the =
others, averaging 6.6 choices per char. In practice the entropy would =
be much less than these bounds because the paths that we can remember =
constitute a *very* small fraction of the total, I believe.
--r.e.s.
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message =
news:[EMAIL PROTECTED]...
| r.e.s. wrote:
| >=20
|=20
| > BTW, the password grid idea isn't new, and was specifically and =
strictly forbidden in one of my former workplaces decades ago.
|=20
| It is a little bit special case of the 'simple grille', but its
| application isn't bad, I suppose. Why were your former superiors=20
| so sensitive to its use?
|=20
| M. K. Shen
------------------------------
From: Ron Skoog <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Linking Time-Stamping Servers
Date: Fri, 10 Mar 2000 22:56:09 -0800
Terje Mathisen wrote:
>
> Paul Koning wrote:
> >
> > Terje Mathisen wrote:
> > > NTP is definitely the 'Right Way' to sync servers, ...
> >
.
.
.
>
> And how would you attach those clocks to your servers?
>From what I've worked with there are GPS time receivers that will
connect via ethernet, VME, ISA, or PCI. I'm sure there are others.
>
> NTP is _the_ best piece of sw available to sync a system clock to an
> external source, preferably using a Pulse Per Second (PPS) signal to
> slave the kernel clock directly to the exterbak reference.
It all depends on what you need the time precision to be. I found out
recently that setting the system clock on a Wintel box would give upto
100 milliseconds error from the time base it was being set against even
though that was good to a few microseconds. This problem was inherent
in the design of the O/S and onboard clock.
That time base was a PCI card. Trying to set a system against a network
time base could be worse depending on the network traffic. However, if
you don't have a need for sub-second accuracy the NTP is certainly
better.
>
> One of my reference servers, currently sitting in my office with the
> antenna on an outside ledge, is a FreeBSD machine using a $400 Motorola
> Oncore GPS receiver which is capable of 30 ns RMS precision.
>
> That particular box uses the standard (bad) motherboard crystal, so when
> I measured the error, I got something like 0.4 us of RMS jitter.
How did you measure that? I've been running across problems related to
PCI
bus latencies of almost 100 ns and (for NT) time slices of around 80 ms.
The combination of the two tent to make sub-millisecond measurements
difficult without using interrupts and those have shown ~3us variation
around a 10K PPS interrupt.
>
> Poul-Henning Kemp, who wrote the Oncore driver, have also replaced the
> motherboard crystal with an OCXO, he got significantly better than 0.1
> us precision.
Is there a webpage on this trick?
>
> So, as I said, NTP is the 'Right Way', it is even an Internet standard
> (RFC). :-)
>
> Terje
Ron
------------------------------
From: James Muir <[EMAIL PROTECTED]>
Subject: Re: Birthday paradox
Date: Sat, 11 Mar 2000 06:59:04 GMT
In article <[EMAIL PROTECTED]>,
Raphael Phan Chung Wei <[EMAIL PROTECTED]> wrote:
> We come across the term birthday paradox when we go through literature
> on cryptanalysis.
>
> It states that for example in a room of 23 persons, the probability of
> any two persons having the same birthdate is about 1/2. Now how do we
> apply that to the search for matches in block ciphers?
The birthday paradox says that if X is a random variable drawn
uniformily from an interval of n values then we expect that X will take
on a repeated value after sqrt( pi*n / 2 ) draws.
People's birthdays are just occurences of the random variable X drawn
uniformly from [1..365]. So we expect that in a group of sqrt(
pi*365 / 2 ), which is approximately 24, two people will share the same
birthday ( a birthday collision ).
The principle can be applied to block ciphers and hash functions.
Assume your cipher outputs a random string of n bits for each key
value. A key value represents an occurence of the random variable X
sampled from the interval [1..2^n]. Thus we expect a collision in
every group of sqrt( pi*n / 2 ) key values.
-James
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sat, 11 Mar 2000 07:32:27 GMT
"David A. Wagner" wrote:
> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> > 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.
> The part left unsaid in your example is that ciphers F,G,G',H are
> assumed to be unkeyed.
That was for simplicity of exposition. For the independently
keyed case, some fraction of the time (same key for G and G')
the system reduces to the much weaker one FH, so the effective
failure rate is around 2^-(key size of G). For certain
parameter sets, that is less secure than FG or G'H. The
point remains: the interaction of substructure can make the
composition of ciphers less strong than one might think,
certainly less strong than a system that always makes optimum
use of the entire key.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Blind-recipient-hiding (was Re: encrypting to unknown public key?)
Date: 11 Mar 2000 07:40:21 GMT
David Hopwood <[EMAIL PROTECTED]> wrote:
> 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 :-),
Gee, my nefarious plans reveal'd. :-)
------------------------------
** 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
******************************
