Cryptography-Digest Digest #380, Volume #12 Tue, 8 Aug 00 12:13:01 EDT
Contents:
Re: Physical RNG (Bob Deblier)
Re: Special RSA moduli (Bob Silverman)
Broadcast key Management (Antonio Romeo)
Re: any ideas on a protocol? ("Scott Fluhrer")
Re: OTP using BBS generator? (Mok-Kong Shen)
Re: Questions about Rijndael (Mok-Kong Shen)
Key in ASCII ?? ("kihdip")
Re: Best AES candidates ?? (DJohn37050)
Re: 2 keys encryption algorithm? (Kent Briggs)
Re: More Secret Conversations ("Trevor L. Jackson, III")
Re: Physical RNG (JCA)
Re: chap authentication scheme? (Mark Wooding)
Re: chap authentication scheme? (Mark Wooding)
Re: Proposal: Timestamping Roundtable w/ PGP Sigs. ("Ed Suominen")
----------------------------------------------------------------------------
From: Bob Deblier <[EMAIL PROTECTED]>
Subject: Re: Physical RNG
Date: Tue, 08 Aug 2000 15:14:30 +0200
Ed wrote:
> Hello,
>
> I'm searching for a physical random number generator.
> But I've have important constraint :
> - it should be plugged in a PCI bus
> - it should be useable under Solaris system ( or Unix system)
>
> If you know a physical RNG that don't match these criteria,
> it could help me.
>
> Please send any information to : [EMAIL PROTECTED]
>
> Edouard DESSIOUX
> Everbee
If you want it to be hardware and PCI and cheap: use the built-in sound
of modern Sparcs, or plug in a supported PCI soundcard, take the LSBs of
sound samples you read from the unplugged microphone port - then run
them through a Von Neuman compensator. If you want you can have a look
at the BeeCrypt crypto library (http://beecrypt.virtualunlimited.com/),
which has been tested on Solaris and Linux. It has an entropy provider
which does exactly this.
Sincerely
Bob Deblier
Virtual Unlimited
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Special RSA moduli
Date: Tue, 08 Aug 2000 13:14:05 GMT
In article <8mo6vj$g6o$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]> wrote:
> Bob Silverman <[EMAIL PROTECTED]> wrote:
> > In article <8mn890$d2t$[EMAIL PROTECTED]>,
> > David A Molnar <[EMAIL PROTECTED]> wrote:
> [snippage]
> >> As far as I can tell, the case of a repeated prime factor in an
> >> RSA modulus isn't covered by the appendix.
>
> > Huh? Of course it is. Factoring p^2q with p~q is the same
> > as factoring pqr with p~q~r. What matters to ECM is the SIZE of the
> > factors. p~q~r is *slightly* easier because there are 3 primes,
> > instead of 2, so it is 50% more likely that an EC modulo one of
> > the primes will be smooth when there are 3. But 50% increase
> > doesn't help much. It is only a small constant factor better.
>
> My apologies, I wasn't clear. I should have written that the
> appendix didn't seem to cover the dangers which are peculiar
> to using repeated prime factors p^r q instead of multiple distinct
> primes. These are the dangers pointed out by the Boneh, Durfee, and
> Howgarave-Graham paper I mentioned.
I have a LOT of respect for Dan Boneh et. al. However,
Their result is IRRELEVANT to key security. It applies only when
r is LARGE. But if r is large and N = p^r q, then p must be
SMALL, which means it is easy to find with ECM anyway! It is totally
TRIVIAL to factor a 1024-bit modulus of the form p^10 q with ECM.
Even p^6 q isn't hard. The latter takes a moderate effort, but can
readily be done in a day or 2 with only about 100 PC's.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 08 Aug 2000 15:33:05 +0200
From: Antonio Romeo <[EMAIL PROTECTED]>
Subject: Broadcast key Management
I need some informations about the key management for broadcast
applications and systems.
thanks in advance.
--
Antonio ROMEO
=========================================
Swiss Federal Institute of Technology
Department of Electrical Engineering
Integrated Systems Laboratory (ISL)
EPFL-DE-LSI ELB-Ecublens
CH-1015 Lausanne
tel. +41 21 693 69 79
fax +41 21 693 46 63
email [EMAIL PROTECTED]
http://lsiwww.epfl.ch
==========================================
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: any ideas on a protocol?
Date: Tue, 8 Aug 2000 06:23:34 -0700
R Fabian <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> If this is the wrong group to post, let me know which would be more
> appropriate.
Sounds as appropriate as any...
>
> I would like to be able to prove that a person has a certain ping. I will
> need this to make a game *very* fair, so that even if a bot is helping a
> player, the bot will still only be able to reduce the reaction time, not
be
> able to see into the future (high fake ping would effectivley be a
> premontion).
>
> Any ideas, or even proofs that it cannot be done would be helpful.
I don't think it can be done. What an attacker can do to create a high fake
ping would be to install a logical box (either hardware or software) that
enforces an N/2 millisecond delay on all incoming/outgoing packets [1].
This would look exactly equivilant to having a total N millisecond roundtrip
delay in various routers between him and the server, and so cannot be
distinguished from normal net delay. And, the attacker can examine the
incoming packets before the N/2 milliseconds is up, giving him some
"premonition".
[1] Of course, the attacker can put an N millisecond delay on incoming
packets and no delay on outgoing packets. This would increase his effective
advantage, but is somewhat distinct from real netdelays, which invalidates
the above argument. In practice, unless N is so huge that you can tell the
difference by clock synchronization, this should be as undetectable.
--
poncho
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Tue, 08 Aug 2000 15:57:03 +0200
Terry Ritter wrote:
>
> I suppose that one of the issues here might be the use of asymptotic
> proofs of strength, or statistical proofs of strength, to incorrectly
> imply strength in every case. Perhaps a statistical proof can just
> mean *most* cases, which may mean that some cases which fit under the
> guarantee are not really secure. That would be an interesting
> definition of "proven strength."
>
As someone has pointed out (I don't remember whether in this
thread or not), the term 'provable security' is misleading
in almost all applied instances. For it carries the easily
misinterpreted connotation that a certain algorithm being
referred to by the term provides absolute security and that
that fact has been UNCONDITIONALLY proved. What actually
happens, however, in such cases is that there exists a
rigorous, logically impacable proof leading from certain
assumptions to the conclusion of perfect security or some
quantifiable approximation of perfect security. There is no
more nor less. So the term 'provable security' should be
replaced by 'existence of a rigorous security proof contigent
on fulfillment of certain assumptions'. The replacement
string is unfortunately rather long but we have to use it in
order to avoid catastrophical misunderstandings of lots of
people.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Questions about Rijndael
Date: Tue, 08 Aug 2000 16:23:56 +0200
Mark Wooding schrieb:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> > All the points in my previous post are summerizable into two
> > (abstract) points that seem to apply to other finalists of
> > AES more or less as well:
> >
> > 1. There is no or little 'variability' (e.g. one single
> > S-box in Rijndael) that could potentially further enhance
> > the strength of the cipher.
>
> Too much `variability', as you call it, increases memory and code
> footprints of software implementations and means you need more chunks of
> hardware in a minimal implementation. Remember that AES is meant to be
> fast and cheap as well as secure.
Unfortunately it is true that in the real world we have to do
some optimizations. The fastest, the cheapest and the most
secure are qualtities that can't be all obtained at the
same time. But some variability seems to be capable of being
introduced without stepping outside of certain bounds fixed
by the AES requirements. Of course, if the designer, for
competition purposes, tries to shrink his design as much
as possible, then one tends to have as little variability as
possible or even none.
>
> > 2. The documentation does not give the rationales at
> > sufficiently detailed level. Thus the reader is not very
> > much better off than with the DES design (which has
> > no official release of design rationales at all).
> >
> > That Serpent has only eight S-boxes and Twofish has only one
> > MDS matrix are facts inline with (1).
>
> Ewww. Adding more MDS matrices to Twofish would be awful! Each matrix
> needs four 8 x 32 bit tables *per key* in an optimized software
> implementation. Each matrix needs separate code or gates to handle in
> low-end software and hardware.
Then perhaps it is worth perhaps some reflections to choose a
different route in the design.
> > As to (2), Twofish has a comparatively better explanation
> > of rationales than Rijndael and Serpent and.
>
> The Twofish paper was undoubtedly the best presented. The wealth of
> analysis gave me an extremely good feeling about how carefully the
> cipher had been designed. (I learned differential cryptanalysis from
> that paper, by the way. ;-) )
>
> It helps if you understand the Square design before you read the
> Rijndael paper.
>
> Oh, you should probably *implement* ciphers before you start criticising
> their design. Actually writing the code gives a much sharper and deeper
> understanding of the cipher's structure and the way in which the various
> components fit together.
>
> On the other hand, Rijndael actually has a lot less to explain. The
> reasons for almost all of the decisions are given in the submission
> document, the Square paper, or are obvious when you actually understand
> the design.
>
> > There is one sentence in the Twofish document, though, that continues
> > to confuse me. It says that it uses key-dependent S-boxes but states
> > also that 'However, there is really no such thing as a key-dependent
> > S-box'. Now, whether its S-boxes are key-dependent or not is obviously
> > a binary, not a fuzzy, issue. If there ever exist two different keys
> > that lead to different S-boxes, then there is key-dependency,
> > otherwise there is no key- dependency, isn't it? (I should appreciate
> > it, if someone would like to enlighten me in this point.)
>
> Ahh, but what's an S-box? ;-)
>
> Consider Twofish. Are the S-boxes really the little 4-bit t-boxes? Or
> the fixed 8-bit q-boxes? Or the key-dependent S-tables constructed by
> XORing key bytes between q-box substitutions? Or even the S-tables
> combined with the following MDS multiply?
>
> Consider Blowfish. Is there really an S-box there at all? What's
> usually implemented as a table lookup is really a (really horrible)
> complex function of the key and the constant \pi.
>
> Wherever you see a `key-dependent S-box', look more deeply. It's
> constructed somehow. You can think of it as some nasty function of some
> constant stuff and user-supplied key bits. The `trick' in building key-
> dependent S-boxes is to make the construction function sufficiently
> horrible that it's best to analyse it as a random secret function.
> Blowfish succeeds here, more or less. Twofish is a boundary case. The
> S-box construction is extremely simple, and doesn't preserve
> differential and linear properties of the underlying q-boxes very well.
What is a S-box in Twofish? Look at one diagram in the Twofish
document. There are drawn four S-boxes, numbered 0 to 3. If
these are not S-boxes, then the document must be erroneous.
So, if the content of these after setup differ for a pair of
keys, then there is key-dependence, otherwise there is none.
M. K. Shen
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Key in ASCII ??
Date: Tue, 8 Aug 2000 16:21:27 +0200
This is probably a silly question, but why is the 'key-material input' in
Twofish chosen to be in ASCII ??
If the first byte is 5A, the first two bytes in the keymaterial would be
0x35 and 0x41.
Is this normal to present the key in this way ??
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Best AES candidates ??
Date: 08 Aug 2000 14:31:52 GMT
My personal AES ranking is Rijndael, Serpent, Twofish, MARS, RC6; for what it
is worth.
Don Johnson
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: 2 keys encryption algorithm?
Date: Tue, 08 Aug 2000 14:40:18 GMT
[EMAIL PROTECTED] wrote:
> Hi all,
>
> Is there a solid 2 keys encryption system out there. What I mean by 2
> keys is the systems requires two keys to encrypt the data and then
> needs only one of the two to decrypt it. An application for such system
> is a conversation recording system where the two parties encrypt the
> system and either of which can hear it later.
>
> I am not sure whether the concept of public and private keys apply here.
If only 1 key is required for decryption then any public key encryption
system that can encrypt to multiple recipients will do. If you require more
than one decryption key then a secret sharing system is needed. My
shareware Puffer program (see web site below in sig) has a secret sharing
scheme with a threshold mechanism. You can encrypt with up to n trustee
keys and require m keys to be used for decryption, where n can be from 1 to
10 and m can be from 1 to n.
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
Date: Tue, 08 Aug 2000 10:48:00 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: More Secret Conversations
Simon Johnson wrote:
> deadman19 <[EMAIL PROTECTED]> wrote:
> >bravo! nice dialogue.
> >
> >however, no matter how considered your writing, you have only
> >succeeded in revealing that you are the disciple.
> >
> >why not wait until someone asks you to teach them to become a
> >master?
> >
> >p.s. By The Way, whose disciple are you, eh?
> >
>
> I follow the path of the lightened ones - I am a disciple of the
> prinicples of Shannon. ;)
SlimFast was around that long ago?
------------------------------
From: JCA <[EMAIL PROTECTED]>
Subject: Re: Physical RNG
Date: Tue, 08 Aug 2000 07:50:35 -0700
If you have a disk drive you can use the air turbulence
around your spinning disk as your source of entropy.
There is a paper that analyzes this, concluding that such
a technique would supply some 100 random (not pseudo-
random) bits per minute.
I can't recall the reference, but if you are interested I can
try and dig it up.
Ed wrote:
> Hello,
>
> I'm searching for a physical random number generator.
> But I've have important constraint :
> - it should be plugged in a PCI bus
> - it should be useable under Solaris system ( or Unix system)
>
> If you know a physical RNG that don't match these criteria,
> it could help me.
>
> Please send any information to : [EMAIL PROTECTED]
>
> Edouard DESSIOUX
> Everbee
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: chap authentication scheme?
Date: 8 Aug 2000 15:37:42 GMT
Tomas Rosa <[EMAIL PROTECTED]> wrote:
> > The authenticator has a modulus N (prime?) and a generator g. The stuff
> > stored in the database is
> > username, salt s, g, N, g^ps modN
>
> Note about the salt: I suppose that you want to use the salt to hide the
> property that two users with the same p will have the same entry in the
> account database. But when N is prime (more precisely, when the order of
> multiplicative group Z/N is known) then it is easy to compute r, such that
> r*s mod phi(n) = 1 and then to compute g^p mod N = (g^ps)^r mod N.
>
> Now is the attacker able to determine accounts wiht the same authentication
> secret p.
>
> Tom
>
>
>
--
[mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: chap authentication scheme?
Date: 8 Aug 2000 15:41:38 GMT
Tomas Rosa <[EMAIL PROTECTED]> wrote:
> > The authenticator has a modulus N (prime?) and a generator g. The stuff
> > stored in the database is
> > username, salt s, g, N, g^ps modN
>
> Note about the salt: I suppose that you want to use the salt to hide
> the property that two users with the same p will have the same entry
> in the account database. But when N is prime (more precisely, when the
> order of multiplicative group Z/N is known) then it is easy to compute
> r, such that r*s mod phi(n) = 1 and then to compute g^p mod N =
> (g^ps)^r mod N.
>
> Now is the attacker able to determine accounts wiht the same
> authentication secret p.
Good point. The solution is easy: discard s; store only g' = g^s.
The resulting protocol has many interesting properties:
* It's simulatable. Working offline, I can generate transcripts of
plausible-looking authentications simply by making up random values
r myself and computing g'^r and (g'^p)^r. Thus, eavesdropping
doesn't help.
* Impersonating someone is the Diffie-Hellman problem: given g'^r and
g'^p compute g'^{rp}.
* Since the server doesn't have any secrets, it can't actually
impersonate people to other hosts which share the same correct
password database. (If it's allowed to send bogus password
databases about then you lose, of course.)
* Distinguishing password entries for identical passwords appears
difficult, but I can't reduce it to any standard problems.
Given g_0 = g^{s_0}, y = g^{s_0 x_0}, g_1 = g^{s_1} and one of z_0 =
g^{s_1 x_0} and z_1 = g^{s_1 x_1}, decide which of the z_i you were
given.
-- [mdw]
------------------------------
From: "Ed Suominen" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.test
Subject: Re: Proposal: Timestamping Roundtable w/ PGP Sigs.
Date: Tue, 8 Aug 2000 08:48:55 -0700
"Kurt Mueller" <[EMAIL PROTECTED]> wrote:
> Doesn't such a service already exist?
> http://www.itconsult.co.uk/stamper.htm
Yes, stamper appears to be a good service and I use it, but it provides only
one signature, which is not publicly posted. My proposed roundtable could
provide several publicly posted replies with signatures to time stamp each
original poster's digital signature. Between the multiple time stamp sigs.
plus the availability of the posts on Usenet archives, it would be seem very
difficult for someone to challenge the date of the original poster's
signature using the roundtable scheme.
Nothing in this message is to be construed as legal
advice, or the opinion of my firm or any client.
==================================
Ed Suominen
Registered Patent Agent
Web Site: http://eepatents.com
PGP Public Key: http://eepatents.com/key
------------------------------
** 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
******************************
