Re: CSPRNG algorithms
On Fri, Mar 13, 2009 at 1:16 PM, Travis travis+ml-cryptogra...@subspacefield.org wrote: I have never seen a good catalog of computationally-strong pseudo-random number generators. Here is a list of the FIPS-approved random number generators: http://csrc.nist.gov/groups/ST/toolkit/random_number.html NIST Special Publication 800-90 provides recommendations for deterministic random bit generators (not sure why they chose to use DRBG instead of PRNG) based on hash functions, block ciphers, and number theoretic problems (speculation exists that the latter contains a back door). Best regards, Darren Lasko Principal Engineer Advanced Development Group, Storage Products Fujitsu Computer Products of America - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has any public CA ever had their certificate revoked?
pgut...@cs.auckland.ac.nz (Peter Gutmann) on Thursday, May 7, 2009 wrote: Paul Hoffman paul.hoff...@vpnc.org writes: Peter, you really need more detents on the knob for your hyperbole setting. nothing happened is flat-out wrong: the CA fixed the problem and researched all related problems that it could find. Perhaps you meant the CA was not punished: that would be correct in this case. What I meant was that there were no repercussions due to the CA acting negligently. This is nothing happened as far as motivating CAs to exercise diligence is concerned, you can be as negligent as you like but as long as you look suitably embarassed afterwards there are no repercussions (that is, there's no evidence that there was any exodus of customers from the CA, or any other CA that's done similar things in the past). ... If a CA in a trust anchor pile does something terribly wrong and there are no repercussions, why would any CA care about doing things right? All that does is drive up costs. The perverse incentive that this creates is for CAs to ship as many certificates as possible while applying as little effort as possible. And thus we have the current state of commercial PKI. It seems to me that there are a number of problems with the current CA situation. Since no CAs have been identified by name (except Verisign for a very old problem), it is hard for me to reduce the reputation of a specific CA. Even if one was identified, it's not clear what I could do to move business to more responsible CAs. So my reaction is to say that it's all a big stinking pile and try to develop systems and procedures that don't rely on CAs. (e.g. curl with a copy of the server's self-signed certificate, the Petname toolbar, etc.) If SSL/TLS had as part of its handshake, a list of CAs that are acceptable to the client, I could configure my browser with only high-reputation CAs. This step would probably make it desirable for servers to get certificates from more than one CA so they could return a certificate signed by an acceptable CA. It would certainly allow for some market pressure on CAs, and high reputation CA might be able to charge more for certificates. (The last time I ran into a case where the server certificate was not signed by a CA on my browser's default list, I used the 800 number instead. That was for activating a credit card.) In addition, I am worried that some countries cyber-warfare department has a copy of some well-installed CA's signing key and can generate certificates whenever it wants. When D-day comes, it will spoof DNS and use the certificates to disrupt the economy of its target country. If we had a 2 level security system, with CAs for the first introduction, and something more robust for subsequent sessions, these attack scenarios would be less likely. Cheers - Bill --- Bill Frantz| gets() remains as a monument | Periwinkle (408)356-8506 | to C's continuing support of | 16345 Englewood Ave www.pwpconsult.com | buffer overruns. | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
80-bit security? (Was: Re: SHA-1 collisions now at 2^{52}?)
On Thu, 30 Apr 2009 17:44:53 -0700 Jon Callas j...@callas.org wrote: The accepted wisdom on 80-bit security (which includes SHA-1, 1024-bit RSA and DSA keys, and other things) is that it is to be retired by the end of 2010. That's an interesting statement from a historical perspective -- is it true? And what does that say about our ability to predict the future, and hence to make reasonable decisions on key length? See, for example, the 1996 report on key lengths, by Blaze, Diffie, Rivest, Schneier, Shimomura, Thompson, and Wiener, available at http://www.schneier.com/paper-keylength.html -- was it right? In 1993, Brickell, Denning, Kent, Maher, and Tuchman's interim report on Skipjack (I don't believe there was ever a final report) stated that Skipjack (an 80-bit cipher) was likely to be secure for 30-40 years. Was it right? The problem with SHA-1 is not its 80-bit security, but rather that it's not that strong. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
MetriCon 4.0
On behalf of the program committee, may I please direct your attention to your possible participation MetriCon 4.0. The MetriCon 4.0 Workshop will be held on Tuesday, August 11, 2009, in Montreal, Quebec, co-located with the USENIX Security Symposium. All who are interested in participating should review the formal Call for Participation and, as it says, soon communicate via email to the MetriCon 4.0 program committee. As with all MetriCon events, MetriCon 4.0 is by invitation with both invitations for attendance-only and for attendance with presentation possible. Please be in touch. The theme of this episode is The Importance of Context. This workshop series is intense, and is focused on progress rather than claims of first discovery. See http://securitymetrics.org/content/Wiki.jsp?page=Metricon4.0 Dan Geer - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has any public CA ever had their certificate revoked?
Bill Frantz fra...@pwpconsult.com writes: So my reaction is to say that it's all a big stinking pile and try to develop systems and procedures that don't rely on CAs. (e.g. curl with a copy of the server's self-signed certificate, the Petname toolbar, etc.) The problem with this is that recent changes in browser UI (particularly in FF3) make it really, really hard to work with anything but cert-vending- machine certificates. It could be argued that of all the (public) CAs out there, CACert is the most trustworthy because they're the only one not motivated by money to crank out as many certs as possible as cheaply as possible (although the last time I checked they also do email-verification- only certs, so it may be more a theoretical advantage than a real one). Of course with the universal implicit cross-certification present in browsers this is all a moot point because the whole thing is only as secure as the least reliable, least digilent sub-sub-sub-CA in the whole dogpile (insert Matt Blaze PKI quote here). If SSL/TLS had as part of its handshake, a list of CAs that are acceptable to the client, I could configure my browser with only high-reputation CAs. Uhh, how is that meant to work? In any case even if it did, every time you went to a site using a cert vending machine not on your list the browser wouldn't let you connect (or at least not without serious amounts of messing around, which means that eventually you'd add it to your list just to get rid of the nuisance). This is unfixably broken. We've been trying the same broken thing for fifteen years now and it still hasn't started to work. The solution is to look at alternatives like mechanisms that protect relationships (challenge-response mutual auth like TLS-SRP and TLS-PSK), not a nonfunctional mechanism which, even if it worked perfectly, could only protect mostly-meaningless names. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
fyi: Accelerating computation with FPGAs
of possible (topical) interest... Stanford EE Computer Systems Colloquium 4:15PM, Wednesday, May 13, 2009 HP Auditorium, Gates Computer Science Building B01 http://ee380.stanford.edu[1] Topic:Accelerating computation with FPGAs with a seismic computation example Speaker: Michael Flynn Maxeler Technologies (and Stanford) About the talk: For many high performance applications the alternative to the multicore rack is to use an accelerator assist to each multicore node. There are a number of instances of these accelerators: GPGPU, Specialized processors (E.G.IBM's Cell) and FPGAs. At Maxeler we've found that the FPGA array technology wins out on performance for most relevant applications. Given the initial area-time-power disadvantage of the FPGA in (say) a custom designed adder this is a surprising result. The sheer magnitude of the available FPGA parallelism overcomes the initial disadvantage. Using Maxeler's FPGA compiler toolkit, it is now feasible to transform a software application into a data flow graph mapped to an unconstrained systolic array. The array structure can be matched to the applications structure and is not constrained to nearest neighbor communications as the FPGA provides a generalized interconnect. As an example we consider modeling problems in seismic data processing. In a typical problem we realize a 2000 node systolic array on 2 FPGA's, each node performing an operation each 4 ns. About the speaker: Michael Flynn is now Professor Emeritus of EE at Stanford. He directed the Architecture and Arithmetic group in CSL for many years. He is now Senior Adviser and Board Chairman at Maxeler. Contact information: Michael J Flynn fl...@maxeler.com[2] Embedded Links: [ 1 ]http://ee380.stanford.edu [ 2 ]mailto:fl...@maxeler.com ABOUT THE COLLOQUIUM: See the Colloquium website, http://ee380.stanford.edu, for scheduled speakers, FAQ, and additional information. Stanford and SCPD students can enroll in EE380 for one unit of credit. Anyone is welcome to attend; talks are webcast live and archived for on-demand viewing over the web. MAILING LIST INFORMATION: This announcement is sent to multiple mailing lists. If you are signed up on our private EE380 list you can remove yourself using the widget at the upper left hand corner of the Colloquium web page. Other lists have other management protocols. ++ | This message was sent via the Stanford Computer Science Department | | colloquium mailing list. | | To be added to, or removed from, the list, please go to: | | https://mailman.stanford.edu/mailman/listinfo/colloq-local-list| | For more info, send an empty message to colloq-requ...@cs.stanford.edu | | For directions to Stanford, see http://www-forum.stanford.edu | +-xcl+ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has any public CA ever had their certificate revoked?
pgut...@cs.auckland.ac.nz (Peter Gutmann) on Thursday, May 7, 2009 wrote: If SSL/TLS had as part of its handshake, a list of CAs that are acceptable to the client, I could configure my browser with only high-reputation CAs. Uhh, how is that meant to work? The client hello message would include the list of acceptable CAs. The server could use that list to select an acceptable certificate to return to the client. In the rare cases where there is a client certificate, the server hello could include a similar list and the client could use it to select an acceptable certificate. If the lists aren't included in the hello messages, the behavior is the same as the current versions of SSL/TLS. In any case even if it did, every time you went to a site using a cert vending machine not on your list the browser wouldn't let you connect (or at least not without serious amounts of messing around, which means that eventually you'd add it to your list just to get rid of the nuisance). Yes, I know I'm way out in left field, but I just might not go to a web site if I cared about security with my transaction and the site didn't use a reasonable CA. There are many alternatives both with competitor organizations, and competitive communication techniques. For example, if I didn't like the CA my bank used, I could either change banks or do my banking by phone or in person at a local branch. I have avoided many sites that want user names and passwords, or want me to turn on Javascript. The popularity of the noscript plugin for Firefox means that perhaps I'm not the only one out in left field. Cheers - Bill --- Bill Frantz| gets() remains as a monument | Periwinkle (408)356-8506 | to C's continuing support of | 16345 Englewood Ave www.pwpconsult.com | buffer overruns. | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
