RSA's BSAFE Baldwin's RFC (FW)
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 snip
Just what is the offense of encryption?
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
[Fwd: That spooky PECSENC]
--- 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 mailto: [EMAIL PROTECTED] Philodox Financial Technology Evangelism http://www.philodox.com/ 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'
Re: A5/1 cracking hardware estimate
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
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
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
NY Times article on EU acceptance of Enfopol
http://www.nytimes.com/techweb/TW_Europe_Votes_For_ISP_Spying_Infrastructure .html Ern
PKCS 11 in Netscape
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 CertificatesYours box. What is wrong? Thanks in advance. Patrick Wood RD Engineer (Security) MIMOS Bhd. [EMAIL PROTECTED] 603-9665000 ext. 4016
FW: Next Week's FSTC May 17-18 Meeting Update
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! ATMOnePager_Revised 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 some of the "black magic" out of the process and gives decision-makers hard data for making
