FW: Next Week's FSTC May 17-18 Meeting Update

[Robert Hettinga]

Yee-haaa!

I *love* my non-job...

Cheers,
RAH

--- begin forwarded text


From: Somebody
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Subject: FW: Next Week's FSTC May 17-18 Meeting Update
Date: Thu, 13 May 1999 17:20:23 -0700

Bob:  Have you seen the attachment?  More ATM over the Internet projects.

-Original Message-
From: Gramling, Laura [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 12, 1999 7:35 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Next Week's FSTC May 17-18 Meeting Update


> Have you registered yet for next week's FSTC May 17 -18, 1999 meeting?
> FSTC has put together a great program to address your business needs for
> today and for tomorrow.
>
Note, the attached word document is an example of one of the new project
concepts being explored during the breakout sessions.  Come with other
project ideas!


 <>

> To Register
> Phone:  312.527.6724
> Email:   [EMAIL PROTECTED]
> On-line:  http://www.fstc.org/springmeet.html
>
> Registration Fees
> $50 for members
> $295 for nonmembers if payment is received on or before April 30th.
> $395 for nonmembers if payment if received after April 30th.
>
> Mastercard, VISA, American Express and Diners Club are accepted.  Checks
> should be made payable to FSTC.  All General Meeting attendee fees are
> non-refundable.
>
> 
> Session Updates
> 
> Our interactive breakout sessions have been expanded and our general
> sessions presenters will be covering the latest in technology for the
> financial services industry. See below for topics and session leaders.
>
> Breakout Sessions Topics and Session Leaders
> Customer Authentication and FAST (Financial Agent Secured Transactions)
> Session Leader:  Dan Schutzer, Citigroup
>
> Digital Signatures Basics
> Session Leader: Parker Foley, First Union
>
> Moving the ATM to the Internet
> Session Leader:  Wolf Rossmann, NCR and Susan Symons, First Union
>
> XML for Financial Messaging
> Session Leader:  David White, Wells Fargo
>
> Issues with PKI
> Session Leaders:  Parker Foley, First Union
>
> Privacy and P3P
> Session Leader:  TBD
>
> General Session Topics and Presenters
> Leveraging Emerging Call Center Technologies for Efficiency, Quality and
> Revenue
> Steve Boehm, First Union Direct
>
> First Union Direct is a recognized leader in exploiting the latest
> technologies -
> the Internet, email, integrated desk tops, imaging, digital certificates
> and
> biometrics, and leading edge telephone platforms - to provide superior
> service
> and effective direct marketing of financial services to its growing
> customer
> base.  Mr. Boehm will explore the challenges and rewards of guiding one of
>
> the nation's largest call centers into the second millennium.
>
> The Last Mile - Its Impact on Delivering Financial Services to Consumers
> over the Internet
> Mike Parsons, Wachovia Bank
>
> The focus of the session will be to review the recent developments in
> Internet bandwidth and the current state of Internet connections for the
> home consumer.  In spite of advances, significant numbers of customers
> continue to suffer from slow connections to the Internet.  What are the
> prospects for improvement?  How does this impact presentation of services
> over the Internet to our customers?  My goal is to impart an understanding
> of why financial institutions need to consider the potentially negative
> impact on usability that can emerge from slow downloads of complex
> presentations.
>
> Consumer Payments Research
> David Allardice and Brian Mantel, Federal Reserve Bank of Chicago
>
> David Allardice and Brian Mantel will present an overview of research on
> the primary motivations   impacting consumer payment choice and the
> implications for different forms of payments, including: identification of
> key segments; identification of  critical obstacles; and observations on
> potential opportunities.
>
> Update on BITS Sponsored Initiatives
> Kit Needham, BITS
>
> Kit Needham will be giving an update on BITS key initiatives and actions
> taken at the April Board meeting.  Topics will include IFX,
> InteroperaBILL, Fraud Reduction, ECP, Privacy/Data Sharing, Shared
> Utilities, and Electronic Commerce Framework.
>
> Paperless Automated Check Exchange & Settlement (PACES)
> Mariano Roldan, Chase Manhattan Bank
>
> PACES is a FSTC project whose focus is to move the financial services
> industry towards image-based truncation. Its primary goal is to develop a
> technical platform that demonstrates the viability of interbank image
> exchange based on truncation of paper checks at the bank of first deposit.
> This presentation will provide an update on the status of the project.
>
> Red Teaming:  The Next Wave in Information Security
> Bradley Wood, Sandia National Laboratories
>
> Red Teaming is an alternative method of assessing the relative security
> strengths and weaknesses of an information system.  Some new work in this
> area takes so

PKCS 11 in Netscape

[Patrick Wood]

I'm trying to implement PKCS 11 into Netscape. Can someone tell me what does
Netsacpe needs and their calling functions? I can put my dll into Netscape,
and the token is created, the slots are there and the sessions info are all
there.
But the certificate that is read into the token doesnt appear in the
Certificates>Yours box. What is wrong?

Thanks in advance.

Patrick Wood
R&D Engineer (Security)
MIMOS Bhd.
[EMAIL PROTECTED]
603-9665000 ext. 4016

NY Times article on EU acceptance of Enfopol

[Ernest Hua]

http://www.nytimes.com/techweb/TW_Europe_Votes_For_ISP_Spying_Infrastructure
.html

Ern

Re: A5/1 cracking hardware estimate

[Arnold G. Reinhold]

At 6:17 PM + 5/13/99, Matthew Francey wrote:
>>Your approach is interesting, but it claims a gain of about 100 in reduced
>>cycle time, while giving up the ability to use the knowledge that ten key
>>bits are zero, which is a factor of 1000. So it is not a win in that sense.
>
>I'd just build 10x more of the searchers then;  they are very simple.
>But I don't know how much stuff like this costs to make and such.
>Spending other people's money is always easy ... ;-)

To get an expected search time on the order of an hour with my design, we
are talking about 1 million search engines. For real time performance, a
billion. A factor of ten is not trivial at that scale.

>
>>However your analysis does suggest that going to a full 64 bit key would
>>not yield a corresponding gain in strength for A5/1.
>
>This might also apply to any simple shift-register based crypto with only
>64 bits of state.
>
>>I did think about precomputing the shift register state after part of the
>>key is setup and then loading that in parallel, but the extra circuitry
>>needed to enable parallel load of the shift registers might eat up most of
>>the thruput savings.
>
>Hm.  The "extra circuitry" would be wires and a latch signal.  I can't
>see how this would eat into throughput.

By thruput I mean the number of keys checked per second per chip. With the
cell library I was using, you'd need an additional gate per flip-flop which
adds 384 sites to my original 1178 or 32%. Also you would increase the
number of lines that have to go to each engine by a factor of ten, and that
has got to cost you real estate. You might save 48 out of 212 cycles or
22%. Not a great trade.

>
>>Also if you have 64 circuits running in parallel synchronously, then you
>>can't assume they will all fail in two cycles on the average. If you want
>>the engines to run asynchronously, then you need a 64-bit counter per
>>engine which would increase the footprint by a factor of two or so.
>
>The footprint is already miniscule, especially compared to a DES search
>engine.  Or at least I think it would be; I am not deep into VLSI design.
>
The footprint is miniscule, but we make it up in volume!

>The 64 bit counter can be dispensed with by using the search engine as it's
>own "counter".  Just start the registers at some known point and let it
>loose.  Shift the output bits into a plaintext comparison unit -- simple
>xor/mask/check for zero combinatoric logic.  Stop when a match is decreed.
>
>Problems:  cycles in A5/1's output sequence would preclude a single
>search from spanning the entire space.  The search space itself is now
>rather non-linear -- efficiently searching it is itself an interesting
>problem.

It might be enough to show that you would search most of the key space this
way. If you are screening calls en masse, then you can afford to let a few
get thru undecrypted.
>
>>Finally, it is not clear to me that you can run A5 backwards after the 100
>>mixing steps because then the non-linear majority voting circuit is
>>operating. I haven't thought that question through.
>
>Actually, it doesn't matter in the end:  as soon as the 64 bits of state
>have been found, it is game over for the target.

Good point.

>In this frame of mind,
>all of the key setup stuff in the released A5/1 code is just so much
>obfuscation.

But if the designer knew that only a 54 bit key space was permitted, then
the A5/1 key setup approach may make sense as a key strecher, gaining back
some of the workfactor that was lost by keeping the keys short.


Arnold Reinhold

Re: A5/1 cracking hardware estimate

[Matthew Francey]

I wrote:

>The 64 bit counter can be dispensed with by using the search engine as it's
>own "counter".  Just start the registers at some known point and let it
>loose.  Shift the output bits into a plaintext comparison unit -- simple
>xor/mask/check for zero combinatoric logic.  Stop when a match is decreed.
>
>Problems:  cycles in A5/1's output sequence would preclude a single
>search from spanning the entire space.  The search space itself is now
>rather non-linear -- efficiently searching it is itself an interesting
>problem.

Hmmm... even worse would be "splinters":  those states that lead into cycles.

I wonder if the entire A5/1 "valid" states can be quickly mapped out in a
nice way.  This computation would have to be done only once, and would then
be used to dole out searching tasks, a la distributed.net.

-mdf

Re: A5/1 cracking hardware estimate

[Matthew Francey]

>Your approach is interesting, but it claims a gain of about 100 in reduced
>cycle time, while giving up the ability to use the knowledge that ten key
>bits are zero, which is a factor of 1000. So it is not a win in that sense.

I'd just build 10x more of the searchers then;  they are very simple.
But I don't know how much stuff like this costs to make and such.
Spending other people's money is always easy ... ;-)

>However your analysis does suggest that going to a full 64 bit key would
>not yield a corresponding gain in strength for A5/1.

This might also apply to any simple shift-register based crypto with only
64 bits of state.

>I did think about precomputing the shift register state after part of the
>key is setup and then loading that in parallel, but the extra circuitry
>needed to enable parallel load of the shift registers might eat up most of
>the thruput savings.

Hm.  The "extra circuitry" would be wires and a latch signal.  I can't
see how this would eat into throughput.

>Also if you have 64 circuits running in parallel synchronously, then you
>can't assume they will all fail in two cycles on the average. If you want
>the engines to run asynchronously, then you need a 64-bit counter per
>engine which would increase the footprint by a factor of two or so.

The footprint is already miniscule, especially compared to a DES search
engine.  Or at least I think it would be; I am not deep into VLSI design.

The 64 bit counter can be dispensed with by using the search engine as it's
own "counter".  Just start the registers at some known point and let it
loose.  Shift the output bits into a plaintext comparison unit -- simple
xor/mask/check for zero combinatoric logic.  Stop when a match is decreed.

Problems:  cycles in A5/1's output sequence would preclude a single
search from spanning the entire space.  The search space itself is now
rather non-linear -- efficiently searching it is itself an interesting
problem.

>Finally, it is not clear to me that you can run A5 backwards after the 100
>mixing steps because then the non-linear majority voting circuit is
>operating. I haven't thought that question through.

Actually, it doesn't matter in the end:  as soon as the 64 bits of state
have been found, it is game over for the target.  In this frame of mind,
all of the key setup stuff in the released A5/1 code is just so much
obfuscation.

-mdf

Re: A5/1 cracking hardware estimate

[Arnold G. Reinhold]

Matthew,

Your approach is interesting, but it claims a gain of about 100 in reduced
cycle time, while giving up the ability to use the knowledge that ten key
bits are zero, which is a factor of 1000. So it is not a win in that sense.
However your analysis does suggest that going to a full 64 bit key would
not yield a corresponding gain in strength for A5/1.

I did think about precomputing the shift register state after part of the
key is setup and then loading that in parallel, but the extra circuitry
needed to enable parallel load of the shift registers might eat up most of
the thruput savings.

Also if you have 64 circuits running in parallel synchronously, then you
can't assume they will all fail in two cycles on the average. If you want
the engines to run asynchronously, then you need a 64-bit counter per
engine which would increase the footprint by a factor of two or so.

Finally, it is not clear to me that you can run A5 backwards after the 100
mixing steps because then the non-linear majority voting circuit is
operating. I haven't thought that question through.

Regards,

Arnold Reinhold


At 8:24 PM + 5/11/99, Matthew Francey wrote:
>You wrote:
>
>>The bad news is that Weiner's engine could do one key comparison per clock.
>>Here is an estimate of the number of clocks required to check an A5/1 key:
>>
>>Key load64
>>Frame Number load   22
>
>There are only 64 bits of state in the A5 "engine".  The extra 22 bits
>of framing are actually bogus and can be "wrapped" with the 64 bits of
>key.  That is:  given any A5 state, one can compute a key, given a frame
>number of choice.  It is a simple linear system.
>
>Hence, 22 cycles go away.
>
>However, the 64 bits of key themselves are bogus.  Rather than loading
>the key bit-by-bit, it would make more sense to directly increment a
>64 bit quantity and mass-load into the 3 shift registers for setup.
>
>Hence, 64 cycles go away.
>
>>Setup mix   100
>
>One can also dispense with these 100 cycles, since they too are
>pre-determined.  That is, given the result of the previous 64 + 22 + 100
>cycles, one can compute the input key, given a frame number.  One just
>runs A5 backwards 100 steps, then solves the previously mentioned linear
>system.
>
>Hence, 100 more cycles go away.
>
>>Output compare  24
>
>Output comparison is 1 cycle per bit.  Simply step the engine until
>a bit-miscompare occurs.   Half fail on first bit, half of the half on
>the next bit, etc.  The expected value of the clock count to a mis-compare
>is 2 cycles.
>
>So 22 more cycles are saved.
>
>>Reset   2
>>
>>Total   212
>
>Given 1 cycle to transfer from counter to state registers then
>increment counter, and then O(2) cycles to check the key, and
>say 1 cycle for recovery/overhead/whatever, we have, say, 4
>cycles per A5 key.
>
>The bit-comparison might be reduced to almost exactly one cycle
>in almost all cases with suitable "lookahead" logic, instead of
>stepping the A5 engine once per bit.
>
>Given suitable pipelining, the entire mechanism is could be reduced
>to one A5 key per cycle.
>
>>Performance ratio:  212/64 = 3.3 times worse than the Wiener DES
>>search design.
>
>Which leaves us at 16-64 times faster than a DES search engine.  So
>we have, in effect, O(60) key bits.
>
>The "problem" with this approach is that the use of the 10 "free"
>key bits is difficult to imagine -- they have been mangled into the
>64 bit free-counter.  Perhaps saving the situation is that all of this
>logic is extremely simple, and (except for the look-head idea) requires
>no memory accesses or other latencies.  This may permit clocking the
>whole system at very high rates -- billions of keys per second *per
>A5 engine*.  One is tempted to bread-board a 100MHz version...
>
>[Note:  I monitor Cypherpunks at
>http://www.inet-one.com/cypherpunks/current/index.html;  the list volume
>is too high for my tastes.  You can submit this rambling missive to the
>list if you think it would be interesting to them.]

[Fwd: That spooky PECSENC]

[Robert Hettinga]

--- begin forwarded text


Date: Wed, 12 May 1999 21:10:24 -0500
Reply-To: Digital Signature discussion <[EMAIL PROTECTED]>
Sender: Digital Signature discussion <[EMAIL PROTECTED]>
From: Richard Hornbeck <[EMAIL PROTECTED]>
Subject:  [Fwd: That spooky PECSENC]
To: [EMAIL PROTECTED]

FYI:

Gant Redmon wrote:
>
> Richard:
>
> As a member of PECSENC, I'm responding to you but CC the list to get a
> little info out about PECSENC.  It isn't as clandestine a bunch as we are
> portrayed.  Actually, our closed door briefing on the latest national
> security threats have been rather mind numbing and devoid of substance.
> Instead, we gather to represent different interests and sit down and have a
> dialogue.  It's tough because no one camp controls.  We have industry
> representative like myself, law enforcement representative, usually a strong
> BXA and NSA contingent and a smattering of DOJ and Treasury folks that drift
> in and out.  The real fun starts when the general public takes the time to
> show up.  The venting going on in meeting in California was a blast.  I
> think our value add is the feedback we are able to give the folks that draft
> the laws that make our lives such a treat.  I'd say PECSENC played a role in
> the relaxation of controls last December and who knows what will be next.
> John Gilmore and I have spoken about what this is worth before.  It's true
> we aren't making any radical overnight changes occur, but we are trying to
> work towards some solutions (or maybe some realizations) that should result
> in encryption becoming more fundamental in everyone's lives.
>
> As for notice, we meet the second Friday every other months.  Pretty simple
> formula.  So far, all meetings have been at BXA headquarters except for one
> in California.  Just park at the Ronald Reagan building to get off at Metro
> Center.  See you there.
>
> Gant Redmon
> AXENT Technologies, Inc.
>
> P.S. Richard: can you get this back to Cyberpunks for me?
>

Also, in response to a private inquiry, Gant provided the following:

>Richard
>
> People shouldn't feel slighted.  Even WE don't have a final agenda yet.  A
> lot of times, we don't get it until the night before.  But it will be from
> 10:00 to 3:00 in room 4832 at DOC.  There always seems to be chairs
> available.  It's no rock concert. :)
>
>Gant


> > -Original Message-
> > From: Richard Hornbeck [SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, May 12, 1999 9:32 AM
> > To:   [EMAIL PROTECTED]
> > Subject:  [Fwd: May 14 President's Export Council Subcommittee on
> > Encryption Agenda]
> >
> > FYI (forwarded from Cypherpunks) - apologies for cross-posting.
> >
> > John Young wrote:
> > >
> > > An updated agenda for the May 14 meeting in DC of the
> > > President's Export Council Subcommittee on Encryption
> > > (PECSENC) has been provided by Lisa Ann Carpenter,
> > > Committee Liaison Officer (202-482-2583):
> > >
> > >  Opening remarks by the new chairman, William Crowell
> > >  (ex-Deputy DIRNSA)
> > >
> > >  Encryption initiatives of the Bureau of Export Administration,
> > >  by William Reinsch
> > >
> > >  Overview of the Critical Infrastructure Assurance Office (CIAO)
> > >  by Jeffrey Hunker, Director
> > >
> > >  1:30 Presentation by the office of Senator McCain on his crypto bill
> > >
> > >  2:00 Report on Congressional activities
> > >
> > >  2:30 Presentations on Bernstein by the two sides, Cindy Cohn and
> > >  Department of Justice
> > >
> > >  3:00 Adjourn (cut back from 5:00 as the FR announced)
> > >
> > > Also, a list of PECSENC members was promised but has not yet arrived.
> > > This information is hard to come by so it will be most welcomed.
> > > Minutes of past meetings and policy recommendations are elusive too.
> > > See the one public statement:
> > >
> > >  http://209.122.145.150/PresidentsExportCouncil/PECSENC/pecsenc1.htm
> > >
> > > It's shameful and maybe illegal to hide PECSENC information. Recent
> > > scutbutt was that acting PECSENC chair Stewart Baker (ex-NSA) was
> > > going to help John Gilmore set up a public web site for PECSENC
> > > affairs. That accountability initiative appears to have died with
> > > Crowell's appointment, or to be fair, is more likely being studied
> > > to slow death to cozzen natsec grizzes -- which fits NSA's MO to
> > > SIDA misfit crypto naifs.

--- end forwarded text


-
Robert A. Hettinga 
Philodox Financial Technology Evangelism 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

Just what is the "offense" of encryption?

[Ernest Hua]

> From: http://www.sjmercury.com/breaking/docs/081732.htm>> 
SENATE PANEL OKS MONEY FOR HIGH-TECH> CRIME FIGHTERS>> 
[SNIP]>> The bill deals with several> technology-related 
offenses such as> encryption, use and possession of> devices that 
can intercept cable TV> signals, phone slamming and spreading> 
computer viruses.
 
Would the author, anyone at theS.J. Mercury 
or at the Department ofJustice care to explain just whatexactly is the 
the "offense" ofencryption?
 
May I remind you, and anyone elsewilling to 
blindly accept governmentpress releases and "leaks", 
thatencryption is not only completely legal,but absolutely vital to the 
health andstability of the information age.
 
It is only scare mongering agencies likethe 
National Security Agency and theF.B.I.  that are trying to 
preventeveryone from protecting their privacybecause they would lose 
their God-likeomniscient powers if they cannotrandomly wire tap anyone 
they wish.
 
If it weren't for these 
organizations'subversive behavior, our criticalinfrastructure would be 
well protected,and we would not be spending billions ofdollars and 
several major governmentagencies and committees trying to fixour 
vulnerabilities.
 
Let's face it, it never pays to listento a 
spy agency on how to protect ourelectronic infrastructure.
 
Ernest Hua, TeraLogic Inc, Mountain 
View, CA[EMAIL PROTECTED], 
(650) 526-6064

RSA's BSAFE & Baldwin's RFC (FW)

[Vin McLellan]

From: [EMAIL PROTECTED]
Subject: I-D ACTION:draft-baldwin-bsafe-00.txt
Date: Thu, 13 May 1999 08:49:55 -0400
Sender: [EMAIL PROTECTED]

A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title: BSAFE CRYPTOGRAPHIC SECURITY COMPONENTS

Author(s)   : B. Baldwin, A. Wilson, S. Nishimura, M. Yurovitsky
Filename: draft-baldwin-bsafe-00.txt
Pages: 270
Date: 12-May-99

This Internet-Draft describes protocols, procedures, and conventions
to be employed by peers implementing a generic cryptographic
application program interface. Version 4.0 of this API was
implemented inside RSA Data Security, Inc.'s BSAFE product. The API
provides a model for implementing symmetric ciphers, message digests,
message authentication, random number generation, public-key
algorithms, digital signatures, and secret sharing. The API is
documented here for the benefit of others who might also adopt and
use the API, thus providing increased portability of security
applications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-baldwin-bsafe-00.txt

Finally! A Newsweek article!

[Ernest Hua]

Anyone knows if TIME has any corresponding 
piece?
 
http://www.newsweek.com/nw-srv/printed/us/st/ty0320_1.htm
 
Ern
 

ADMIN: stop the HTML, please.

[Perry E. Metzger]

Several posters have sent mail messages in the last couple of days in
HTML instead of plain text, or in a mime multipart/alternative with
text and HTML.

Please *stop*. I will systematically reject such postings in the
future. Most of us do not read our email with web browsers, no matter
what Netscape or Microsoft may think.

Perry