Cryptography-Digest Digest #882, Volume #10 Tue, 11 Jan 00 01:13:01 EST
Contents:
Edgar Allan Poe limited edition book (Bill & Maggie Bright)
Financial Cryptography '00 Preliminary Program (Fcrypt2000)
Re: Intel 810 chipset Random Number Generator (Vernon Schryver)
Re: Simple Encryption ... ("r.e.s.")
Re: Intel 810 chipset Random Number Generator ("Trevor Jackson, III")
Modular Inverse with RSA ("Ryan Phillips")
Re: Modular Inverse with RSA (Paul Rubin)
----------------------------------------------------------------------------
From: Bill & Maggie Bright <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Edgar Allan Poe limited edition book
Date: Mon, 10 Jan 2000 19:16:08 -0800
Hi
We have just put an interesting book of E. A. Poe up for auction on
ebay. It was printed in 1941 for the Limited Editions Club. It has 16
aquatints which look like block prints on heavy paper. It is copy number
40 of 1500 and is signed by the artist.
If you are interested in a complete description go to ebay auction #
233747687.
Thanks
Bill & Maggie
------------------------------
From: [EMAIL PROTECTED] (Fcrypt2000)
Subject: Financial Cryptography '00 Preliminary Program
Date: 11 Jan 2000 03:44:12 GMT
Financial Cryptography '00
February 21-24, 2000, Anguilla, BWI
Preliminary Conference Program
NOTE: Early Registration Deadline is January 15, 2000
FC00, the fourth international conference on financial data security
and digital commerce, will be held in Anguilla, British West Indies.
FC00 aims to bring together persons involved in both the financial and
data security fields to foster cooperation and exchange of ideas. The
conference is organized by the International Financial Cryptography
Association (IFCA).
PRELIMINARY CONFERENCE PROGRAM
Monday 21 February
PAYMENT SYSTEMS
Self-Escrowed Cash Against User Blackmailing
Birgit Pfitzmann and Ahmad-Reza Sadeghi
Blind, Auditable Membership Proofs
Tomas Sander, Amnon Ta-Shma (International Computer Science Institute)
and Moti Yung (CertCo)
Private Selective Payment Protocols
Giovanni Di Crescenzo (Telcordia Technologies Inc.)
INVITED SPEAKER
Toward a More Sensible Way of Regulating the Circumvention of
Technical Protection Systems
Pam Samuelson
DIGITAL RIGHTS MANAGEMENT
Efficient Trace and Revoke Schemes
Moni Naor and Benny Pinkas (Weizmann Institute of Science)
Efficient Watermark Detection and Collusion Security
Francis Zane
Tuesday 22 February
ELECTRONIC POSTCARDS
Postal Revenue Collection in the Digital Age
Leon A. Pintsov (Pitney Bowes Inc.) and Scott A. Vanstone (University
of Waterloo & Certicom Corp.)
Signing on a Postcard
David Naccache (Gemplus Card International) and Jacques Stern (Ecole
Normale Superiere)
PANEL
Payment Systems: The Next Generation
Moderator: TBA
ANONYMITY
Self-Scrambler Anonymizers
David Pointcheval (Ecole Normale Superiere)
Authentic Attributes with Fine-Grained Anonymity Protection
Stuart G. Stubblebine (CertCo) and Paul F. Syverson (Naval Research
Lab)
Resource Efficient Anonymous Group Identification
Ben Handley
Wednesday 23 February
FINANCIAL CRYPTOGRAPHY POLICIES AND ISSUES
The Encryption Debate in Plaintext: National Security and Encryption
in Israel and the United States
Barak Jolish (Hancock Rothert & Bunshoft)
Comments and Critical Reflections on the Proposal for a European
Directive on a Common Framework for Electronic Signatures and
Certification Service Providers
Apollonia Martinez-Nadal (University of Balearic Islands, Spain)
A Response to "Can We Eliminate Certificate Revocation Lists?"
Patrick McDaniel (University of Michigan) and Avi Rubin (AT&T Labs)
ABUSES OF SYSTEMS
Non-Repudiation in SET: Open Issues
Els Van Herreweghen
Statistics and Secret Leakage
Jean-Sebastien Coron (Ecole Normale Superiere), Paul Kocher
(Cryptography Research, Inc.) and David Naccache (Gemplus Card
International)
Analysis of Abuse-Free Contract Signing
Vitaly Shmatikov and John C. Mitchell (Stanford University)
Asymmetric Currency Rounding
David M'Raihi, David Naccache and Michael Tunstall (Gemplus Card
International)
Thursday 24 February
FINANCIAL CRYPTOGRAPHY TOOLS
Secret Key Authentication with Software-Only Verification
Jaap-Henk Hoepman (University of Twente, The Netherlands)
Sharing Decryption in the Context of Voting or Lotteries
Pierre-Alain Fouque, Guillaume Poupard and Jacques Stern (Ecole
Normale Superiere)
PANEL
Public Key Infrastructure: PKIX, Signed XML or Something Else?
Moderator: Barb Fox & Brian LaMacchia (Microsoft)
Carl Ellison (Intel Architecture Labs)
Caelen King (Baltimore Technologies)
Michael Meyers (Verisign)
Andrew Konstantaras (independent consultant)
SYSTEM ARCHITECTURES
Financial Cryptography in 7 Layers
Ian Grigg (Systemics, Inc.)
Capability-Based Financial Instruments
Mark S. Miller (ERights.org), Bill Franz and Chip Morningstar
(Communities.com)
RUMP SESSION
In addition to the regular conference program, a rump session will be
held on the evening of Tuesday 22 February to provide an opportunity
for less formal presentations. Although the rump session will be
organized during the conference itself, advance proposals may be
submitted by email. Rump session contributions will not appear in the
conference proceedings. An award of $350 in e-gold will be awarded to
the best rump session presentation.
EXHIBITION
An exhibition will be held in conjunction with the technical program,
with product displays, demonstrations, and presentations of a
business-oriented nature. Scientific sessions are primarily scheduled
for the mornings and exhibition sessions for the afternoons.
CONFERENCE VENUE
The conference will be held at Chandeliers, the conference facility of
the InterIsland Hotel, which is on Road Bay, near Sandy Ground
Village, in the South Hill section of Anguilla. The conference will
have TCP/IP internet access. Shuttle service between the conference
and the Mariners hotel will be available.
REGISTRATION
Registration can be done via the web at URL http://fc00.ai/. The fee
for the conference, which covers all conference materials and events
(including preproceedings, final proceedings, attendance at scientific
sessions, and breakfast and lunch each day of the conference), is:
$850 regular registration
$350 academic registration
$150 student registration
An additional $150 fee applies to registrations for which payment is
received after January 15, 2000.
A $100 discount ($50 for academic and student registrations) is
available to participants who pay their registration fee by electronic
money.
Payment may be made by credit card, bank transfer, electronic money,
or cash.
STIPENDS
A limited number of stipends to help defray the costs of attendance
may be available to full-time students with a paper accepted for
presentation at the conference. If you would like to apply for a
stipend, please contact the General Chair at the email address listed
below.
HOTEL ACCOMODATION
The conference hotel is not recommended except to those seeking budget
accomodations. The recommended hotel is Mariners, where a block
reservation has been made. To reserve a room, please call the hotel
at +1 (809) 497-2671 and mention that you will be attending FC00.
Information about other hotels is available at URL http://fc00.ai.
WELCOME RECEPTION
A welcome reception will be held from 6:30pm to 8:00pm on Monday,
February 21, 2000, the evening of the first day of the conference.
GENERAL INFORMATION
Visas
Visas are not required for citizens of most American and European
countries. If you are uncertain about whether you need a visa,
contact the local British consulate for information.
Getting to Anguilla
From North America, Anguilla is usually reached via San Juan (Puerto
Rico). From Europe, the best connections are via
St. Maarten/St. Martin (from Amsterdam or Paris), or Antigua (from
London). St. Martin is very close to Anguilla and is connected by
ferry as well as by plane.
Local Transportation
The simplest way to get around Anguilla is to rent a car. You will
need to buy an Anguilla drivers license, but this is a formality.
Taxis are also available. Another possibility is to hitch rides from
local residents, who are eager to provide them and will often stop to
offer rides unsolicited. Transportation will be provided at specific
times between Mariners and the InterIsland hotel.
Weather
Expect temperatures in the 20's or 30's Celsius, 70's or 80's
Fahrenheit. There is often a strong wind, with cloudbursts that
quickly blow over. Dress code for the conference is shorts and
T-shirt.
Money
The local currency is the Eastern Caribbean dollar (EC$), with an
exchange rate of approximately EC$2.7/US$1, but many goods and
services in Anguilla, particularly those aimed primarily at tourists
(such as restaurants and hotels) are priced in US dollars. US dollars
are freely tradable everywhere on the island, so there is no need to
obtain EC dollars before arrival.
PROGRAM COMMITTEE
Dan Boneh, Stanford
Joan Feigenbaum, AT&T Labs - Research
Yair Frankel, CertCo
Stuart Haber, InterTrust STAR Lab
Philip MacKenzie, Lucent Bell Labs
Ueli Maurer, ETH Zurich
Clifford Neuman, USC
Kazue Sako, NEC
Dan Simon, Microsoft
Paul Syverson, Naval Research Laboratory
Win Treese, Open Market, Inc.
Nicko van Someren, nCipher
Program Chair:
Yair Frankel (email: [EMAIL PROTECTED])
ORGANIZING COMMITTEE
General Chair:
Donald Beaver (email: [EMAIL PROTECTED])
Local Arrangements Chairs:
Vincent Cate (email: [EMAIL PROTECTED])
Rafael Hirschfeld (email: [EMAIL PROTECTED])
Sponsorship Chairs:
Lesley Matheson (email: [EMAIL PROTECTED])
Robert Tarjan (email: [EMAIL PROTECTED])
SPONSORS
FC00 is sponsored by:
e-gold Transnational <http://www.e-gold.com>
Hush Communications Corporation <http://www.hushmail.com>
InterTrust Star Lab <http://www.star-lab.com>
Telcordia Technologies <http://www.telcordia.com>
nCipher Corporation <http://www.ncipher.com>
Zero-Knowledge Systems <http://www.zeroknowledge.com>
Hansa Bank & Trust Company <http://www.hansa.net/>
Offshore Information Services <http://offshore.ai/>
If you are interested in sponsoring FC00, please contact the
Sponsorship Chairs at the email addresses listed above.
For further information, please see the main FC00 conference web page
at URL http://fc00.ai/.
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: Intel 810 chipset Random Number Generator
Date: 10 Jan 2000 17:41:34 -0700
In article <85djt4$qib$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> ...
>Ok, fine, but there are a zillion other ways to generate random
>numbers at the OS level.
That is a gross overstatement. Randomness is always hard to find in
software. Yes, /dev/random works, but only by lots of work and some leaps
of faith about what are almost errors in disk drives, clocks, and other
hardware. The Intel mechanism is very valuable, its low speed and other
difficulites notwithstanding, because the only leap of faith required is
that it works as advertised.
> I am not planning on going into the
>OS business, and I don't know anyone who is.
Now that I can believe.
> Intel's literature
>talks about making random numbers available to apps. Microsoft
>may not be interested in implementing it. It would have been
>nice is Intel had supplied something more convenient.
The audience for Intel data sheets is people in the OS business. As I
keep saying, as far as the hardware is concerned, the operating system is
an application. That is both reasonable if you understand the overall
layering in computer systems, and has decades of historical precedent.
> As it is,
>reading the microphone is more convenient.
The word "the" which suggests not only that there is at least one
microphone but that there is exactly one. I've seen more systems with
more or less than one than with exactly one microphone.
I wonder what happens when a "multi-threaded app" or two applications try
to read from the the microphone? My guess is that in reasonable operating
systems, there is a driver that buffers samples from "the" microphone,
clocked at a reasonably stable rate, and that when the application reads
what it thinks are current sound bits, it really gets bits from that
buffer. Yes, such buffering can be partly in hardware, but if so, you
probably want the operating system to make copies so that applications or
threads can share the microphone. Yes, level controls and other stuff
can cause problems with a shared microphone, so you might want your
operating system microphone driver to let only a single application open
the microphone at a time. The point is that in no reasonable multi-
processing operating system will you simply "mov ecx,XX; rep ins; ...".
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Simple Encryption ...
Date: Mon, 10 Jan 2000 20:08:35 -0800
"r.e.s." <[EMAIL PROTECTED]> wrote ...
: ---------------begin SHA1-------------------
: "Derek Potter" <[EMAIL PROTECTED]> wrote ...
: :
: : "r.e.s." <[EMAIL PROTECTED]> wrote
: : > Wouldn't it be easier, and just as well, to simply
: : > identify yourself in the plaintext document, then
: : > publish a 1-way hash of the document (say with SHA1),
: : > avoiding the use of keys altogether?
: :
: : How big would the hash be compared with the
: : original document? I can see that an extra
: : m digits (base n) would give a maximum of
: : m^n -1 "wrong" de-hashes, if you see what I'm
: : saying, but can it be as efficient as that?
:
: SHA1 hashes "any" input document into 20 bytes of output
: (illustrated below as 5 blocks of 4 hex chars each, with
: each hex char represented by 2 ascii chars, and blocks
: separated by a space, for a total of 44 characters.)
:
: I don't know the practical limitations on just how large
: the input can be without encountering problems, but it's
: probably huge. Maybe one of the local gurus will answer
: that for us?
:
: (I've only been playing with SHA1 a bit. The hash for
: the message you're now reading, between and including the
: 44-character begin & end lines, appears below.)
:
: r.e.s.
: [EMAIL PROTECTED]
:
: ----------------end SHA1--------------------
: 6B67A22E DDC8C5A2 104D33D5 DB4E358C 533791B4
I notice that the above hash value does not correspond to the
posted text if I now just copy & paste it from my newsreader.
(My email software might have removed a character or two after
I hit "send", e.g. a space at the end of a line -- of course
one character is all it would take to change the hash value.)
In any case the SHA1 hash I get for the text as copied & pasted
from my newsreader, is
36C4B1B1 88A25A1A 3455D453 BE5916D2 2A482B2A
This also leads me to wonder if there is variation in the exact
byte-for-byte content of a posting across various servers and
various kinds of newsreader. (?)
Curious.
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
Date: Tue, 11 Jan 2000 00:35:49 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Intel 810 chipset Random Number Generator
Vernon Schryver wrote:
> In article <[EMAIL PROTECTED]>,
> James Felling <[EMAIL PROTECTED]> wrote:
> >My personal belief is as follows. The RNG generates a bit at fixed
> > intervals , if multiple apps are accessing it at the same time then they
> > are each getting the same value. If this is the case, then there are
> > issues with more than 1 thread accessing it at the same time. (i.e. if
> > you are doing a montecarlo method of finding area, with thread 1 picking
> > the x coord, and thread 2 the y coord, you will get an extreme bias
> > toward values being on the line x=y.
>
> That's an interesting idea almost makes the difference between multiple
> threads and multiple applications relevant. However, it seems too
> subtle to me. Depending on the operating system and the application,
> a real "multi-threaded application" might use multiple processes instead of
> what most people now (but not always) consider threads.
What ever task//thread/scheduling mechanism is used, it is unreasonable to assume that
the software author is unable to use the device correctly. Thus the bias above would
be attributable to the flaw int he software, not a flaw in the device.
>
>
> > Ny guess is that it is indeed
> > intended as an entropy source for driving a /dev/random type randomness
> > pool.
>
> Yes, the warning is the standard Intel and other hardware vendor clue
> intended to say "you need to do the usual operating system stuff with this
> thing." I think I've seen those same beware-of-multi-threaded-applications
> words in other Intel publications. No programmer who has (or can) actually
> dealt with hardware much would infer alleged the doom and incompetence
> from the words, even if they think the device is a crock for other reasons.
I've spent a lot of time writing software in parallel with the development of
hardware. So, as a professional, I believe I'm entitled to an opinion as to hardware
quality. In this particular case the hardware design could have been arranged to
eliminate any possible race condition. It wasn't. That's a design flaw.
It's not doom and gloom. It does not prevent the proper operation of the device. But
it is an obvious flaw. One that indicates either incompetence or lack of attention.
Given Intel's track record, I'd bet on institutional incompetence cultivating lack of
attention on the part of the design engineer(s).
> >>"Trevor Jackson, III" wrote:
>
> >> ...
> >> $100 says they didn't think about it at all. had they considered the
> >> usage of the device the interface would look considerably different. I
> >> suspect some engineer was handed a feature to implement and all the effort
> >> went into the quality of the data and none went into the quality of the
> >> interface. N.b., the interface would logically include the hardware device
> >> registers and any software needed to drive it.
>
> In the past, it was often true that hardware people knew nothing about
> code. Today, they're likely to be running Linux or FreeBSD at home, and
> writing simulations of their hardware in C and other languages at work.
Yes. That's a good thing. But the phase change you described has clearly not
penetrated to Intel.
> No one, not even those criticizing Intel, has said that the interface is
> in any way defective, wrong, or in need of improvement, other than that
> it would be nice to have a way to detect the device, and it's not clear
> to me that there is no way to detect the 801. Exactly what is wrong with
> the interface?
A trivial change to the interface would produce both the status bit and the current
RNG value in a single, atomic read cycle. Such a change would eliminate the
possibility of a race condition between multiple readers. It's not the case that the
interface is _wrong_. It is the case that the interface is poorly designed. A
typical complaint of (software) people using Intel chips.
> All that I can see is that the Intel tech-writers (not
> designers) inflamed some netnews commentators who appear to have no
> experience writing code that talks to hardware.
>
> The appropriate emphasis is on the quality of the data, but it's not clear
> to me that the data is very wonderfully random. In other words, what
> evidence there is contradicts Mr. Jackson's claim about where the effort
> went.
Really. What evidence is that?
------------------------------
From: "Ryan Phillips" <[EMAIL PROTECTED]>
Subject: Modular Inverse with RSA
Date: Mon, 10 Jan 2000 21:34:36 -0800
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
After reading Applied Crypto I'm still confused on creating a private
key
with RSA. if d=e^(-1) mod ((p-1)(q-1)), how do you calculate d.
so if p = 47, q = 71, (p-1)(q-1) = 3220,
choose e at random that abides by the prime rules, e = 79 (just for
this case).
now solve:
d =79^(-1) mod 3220 , the answer is 1019
How do you get the answer 1019, and if someone could include another
example
that would be great.
Thanks for your time.
- -Ryan Phillips
=====BEGIN PGP SIGNATURE=====
Version: PGP 6.5.2
iQA/AwUBOHrA6uB/yjQQFbPXEQJ8BACdGLo5g13iKQN/4mlo9cg5/HAbP4wAn1rX
kRdCMBKcQFvwgnwcmXDk+jhe
=Wsew
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Modular Inverse with RSA
Date: 11 Jan 2000 05:58:49 GMT
Ryan Phillips <[EMAIL PROTECTED]> wrote:
>After reading Applied Crypto I'm still confused on creating a private key
>with RSA. if d=e^(-1) mod ((p-1)(q-1)), how do you calculate d.
>
>so if p = 47, q = 71, (p-1)(q-1) = 3220,
>choose e at random that abides by the prime rules, e = 79 (just for
>this case). now solve:
>d =79^(-1) mod 3220 , the answer is 1019
>
>How do you get the answer 1019, and if someone could include another
>example that would be great.
The point is that (1019 * 79) % 3220 = 1.
Look in a math book under "Extended Euclidean Algorithm" for how
to do the calculation. Knuth vol. 2, "Seminumerical Algorithms" or
Koblitz, "A Course in Number Theory and Cryptography" might be good
places to start.
------------------------------
** 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
******************************
