Re: CSPRNG algorithms
On Mar 13, 2009, at 12:16 PM, Travis wrote: [...] would people like to help me create one by emailing me references to extant PRNG definitions? This paper describes the architecture of a prototype I built at Sun back in 1995 for a random number generating service that ran in user land. It went through a couple revisions, and eventually got ported to the kernel in Solaris 10. http://wikis.sun.com/download/attachments/100794535/CryptoRand- Soley96.pdf The revisions since the paper were fairly minor: using a bigger entropy pool, improving the entropy estimation algorithm, and tweaking the bleed function. I am not sure what changes were made when it was ported to the kernel as I was not directly involved. Unfortunately, the details of the revisions are only documented in the source code. Kind regards, -Bill - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: SHA-1 collisions now at 2^{52}?
On Thu, Apr 30, 2009 at 11:07:31PM -0400, Perry E. Metzger wrote: Greg Rose g...@qualcomm.com writes: This is a very important result. The need to transition from SHA-1 is no longer theoretical. It already wasn't theoretical... if you know what I mean. The writing has been on the wall since Wang's attacks four years ago. Sure, but this should light a fire under people for things like TLS 1.2. Perhaps, though the MAC in TLS cipher-suites needs just 2nd pre-image resistance, not collision resistance. The collision resistance is more relevant to X.509 authentication, and even there only when CA practices are sub-optimal. Yes, by all means, new hash functions, but lets not over-emphasize the magnitude of the problem. This is not a SHA-1 pandemic... -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CSPRNG algorithms
I have never seen a good catalog of computationally-strong pseudo-random number generators. Chapter 3 of Knuth's TAOCP is all about pseudo-random number generators, starting with a fine example of the wrong way to do it. My copy is several thousand miles away but my recollection is that his main advice was to stick to linear congruential PRNGs, perhaps with a buffered postpass to scramble up the order or the results. It's certainly a good place to start. R's, John [Moderator's note: none of the generators in TAOCP are cryptographically strong. They are fine for Monte Carlo simulations and such. --Perry] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: full-disk subversion standards released
Thor Lancelot Simon wrote: No, no there's not. In fact, I solicited information here about crypto accellerators with onboard persistent key memory (secure key storage) about two years ago and got basically no responses except pointers to the same old, discontinued or obsolete products I was trying to replace. I wouldn't normally play marketeer but since you asked did you look at this product ? Either way I'd be interested in your view on it. http://www.sun.com/products/networking/sslaccel/suncryptoaccel6000/index.xml Please ignore the sslaccel in the URL this card doesn't know anything about SSL it is a pure Crypto accelerator and keystore with a FIPS 140-2 @ Level certification. Support on Solaris, OpenSolaris, RHEL 5 and SuSE 10. It has the ability to have centralised key management and shared keystores (within and across machines). It even has Eliptic Curve support available. -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: full-disk subversion standards released
Thor Lancelot Simon wrote: To the extent of my knowledge there are currently _no_ generally available, general-purpose crypto accellerator chip-level products with onboard key storage or key wrapping support, with the exception of parts first sold more than 5 years ago and being shipped now from old stock. CA-6000 supports on board key storage and key wrapping. It even supports the NIST AES Keywrap algorithm. This card is certainly newer than 5 years old, in fact when we first released it we had some deployment issues because we had created a PCIe only card and several customers wanted to put on in machines that didn't have PCIe capability. -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: full-disk subversion standards released
Peter Gutmann wrote: (Does anyone know of any studies that have been done to find out how prevalent this is for servers? I can see why you'd need to do it for software-only implementations in order to survive restarts, but what about hardware-assisted TLS? Is there anything like a study showing that for a random sampling of x web servers, y stored the keys unprotected? Are you counting things like Windows' DPAPI, which any IIS setup should use, as protected or unprotected?) We recently had some discussion about this inside Sun. Not just for TLS but for IKE as well. Until very recently our IKE daemon required the PKCS#11 PIN to be on disk (readable only by root) even if you were using sensitive and non extractable keys in a hardware keystore. We changed that to provide an admin command to interactively load the key. However we know that this won't actually be used on the server side in many case, and not in a cluster (the Solaris/OpenSolaris IKE and IPsec is cluster capable). For Web servers the situation was similar, either the naked private key was on disk or the PKCS#11 PIN that allowed access to it was. I solicited information here about crypto accellerators with onboard persistent key memory (secure key storage) about two years ago and got basically no responses except pointers to the same old, discontinued or obsolete products I was trying to replace. I was hoping someone else would leap in about now and question this, but I guess I'll have to do it... maybe we have a different definition of what's required here, but AFAIK there's an awful lot of this kind of hardware floating around out there, admittedly it's all built around older crypto devices like Broadcom 582x's and Cavium's Nitrox (because there hasn't been any real need to come up with replacements) but I didn't think there'd be much problem with finding the necessary hardware, unless you've got some particular requirement that rules a lot of it out. The Sun CA-6000 card I just pointed to in my other email is such a card it uses Broadcom 582x. -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CSPRNG algorithms
On Sat, Mar 14, 2009 at 3:16 AM, Travis travis+ml-cryptogra...@subspacefield.org wrote: I have never seen a good catalog of computationally-strong pseudo-random number generators. It seems that everyone tries to roll their own in whatever application they are using, and I bet there's a lot of waste and inefficiency and re-inventing the wheel involved. If this true, or is there a survey somewhere? If not, would people like to help me create one by emailing me references to extant PRNG definitions? There's a nice survey, with some advice on how to construct a good PRNG, at J. Kelsey, B. Schneier, D. Wagner, and C. Hall Cryptanalytic Attacks on Pseudorandom Number Generators Fast Software Encryption, Fifth International Workshop Proceedings (March 1998), Springer-Verlag, 1998, pp. 168-188. http://www.schneier.com/paper-prngs.html ABSTRACT: In this paper we discuss PRNGs: the mechanisms used by real-world secure systems to generate cryptographic keys, initialization vectors, random nonces, and other values assumed to be random. We argue that PRNGs are their own unique type of cryptographic primitive, and should be analyzed as such. We propose a model for PRNGs, discuss possible attacks against this model, and demonstrate the applicability of this model (and our attacks) to four real-world PRNGs. We close with a discussion of lessons learned about PRNG design and use, and a few open questions. The authors' reputations suggest their advice is probably excellent... ciao, -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy, Indiana University, Bloomington, Indiana, USA C++ is to programming as sex is to reproduction. Better ways might technically exist but they're not nearly as much fun. -- Nikolai Irgens
Response to The Strange Rise and Fall of Hardware Disk Encryption
Here is a response to Jon Callas' The Strange Rise and Fall of Hardware Disk Encryption[1]: http://security-basics.blogspot.com/2009/04/re-fde-mgiebelpgpcom-has-shared-strange_6682.html 1. http://blog.pgp.com/index.php/2009/04/the-strange-rise-and-fall-of-hardware-disk-encryption/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Fully Homomorphic Encryption Using Ideal Lattices
On Tue, Mar 17, 2009 at 5:06 PM, R.A. Hettinga r...@shipwright.com wrote: Title: Fully Homomorphic Encryption Using Ideal Lattices Speaker: Craig Gentry, Stanford University Time/Place: 11 am, 18 March, Wozniak Lounge [Ed. note: 4th floor, Soda Hall, UC Berkeley] This looks fascinating, but isn't local to me. Does anyone know of a paper? -- Taral tar...@gmail.com Please let me know if there's any further trouble I can give you. -- Unknown - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: [tahoe-dev] SHA-1 broken! (was: Request for hash-dependency in Tahoe security.)
On Thu, 2009-04-30 at 13:56 +0200, Eugen Leitl wrote: http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf Wow! These slides say that they discovered a way to find collisions in SHA-1 at a cost of only 2^52 computations. If this turns out to be right (and the authors are respected cryptographers -- the kind of people who really hate to be wrong about something like this) then it is very exciting! I cannot derive a realistic threat model from the very general statements in the slides. In the case of, for example, the Debian organization, which uses SHA-1 keys to check in code so that it's always clear with a distributed network of developers who made what changes, What threats must they now guard against and what corrective measures ought they take? Can a third-party attacker now forge someone's signature and check in code containing a backdoor under someone else's key? Such code could be loaded on a poisoned server, downloaded, and executed on millions of target machines with devastating effect and no way to catch the attacker. Can a rogue developer now construct a valid code vector B, having the same signature as some of his own (other) code A, thus bypassing the signature check and inserting a backdoor? The scenario is the same with a poisoned server but, once detected, the attacker would be identifiable. Is it the case that a constructed hash collision between A and B can be done by a third party but would be highly unlikely to contain any executable or sensible code at all? In this case the threat is serious, but mainly limited to vandalism rather than exploits. Is it the case that a constructed hash collision between A and B can only be done by the developer of both A and B, but would be highly unlikely to contain any executable or sensible code at all? In this case the threat is very minor, because the identity of the vandal would be instantly apparent. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: [tahoe-dev] SHA-1 broken!
Ray Dillinger b...@sonic.net writes: I cannot derive a realistic threat model from the very general statements in the slides. (BTW, you mean threat, not threat *model*, in this instance.) As just one obvious example of a realistic threat, consider that there are CAs that will happily sell you certificates that use SHA-1. Various clever forgery attacks have been used against certs that use MD5, see: http://www.win.tue.nl/hashclash/rogue-ca/ Those attacks can now be extended to SHA-1 pretty easily. It might require a bit of compute infrastructure -- say a lot of FPGAs and a bunch of cleverness -- to turn out certs quickly, but it can be done. Given that there are lots of high value certs out there of this form, this is rather dangerous. For example, Verisign has lots of cert infrastructure right now that uses SHA-1. Imagine if I now use the above described attack and start forging certs that look to all the world like they're from Verisign and claim that I'm a major bank, or to forge a CA that then forges certs that claim I'm a major bank. Ooops! In the case of, for example, the Debian organization, which uses SHA-1 keys to check in code so that it's always clear with a distributed network of developers who made what changes, What threats must they now guard against and what corrective measures ought they take? One can easily imagine a forgery attack right now where someone presented you with one piece of code which you sign and then made use of a different piece of code with the exact same SHA-1 which you didn't intend to sign. I don't know if Debian's specific processes are vulnerable or not to various clever attacks -- it would require a lot of thinking even if I was familiar enough with them, and I'm not. So, use something other than SHA-1 -- SHA-256 at least. Don't panic, don't flail around like a headless chicken, but do move away with all deliberate speed. Can a third-party attacker now forge someone's signature and check in code containing a backdoor under someone else's key? Perhaps, if they're clever enough. The most obvious attacks require preimage weaknesses, and those aren't known yet. However clever people can find ways to get around this -- see the Rogue CA attack -- and cause havoc. Is it the case that a constructed hash collision between A and B can be done by a third party but would be highly unlikely to contain any executable or sensible code at all? See the Rogue CA attack -- by being clever enough, one can almost certainly produce two executables with the same SHA-1 hash. They would need some sort of area that varied, but that's not too hard -- ELF note sections, data segments regions that contain some blob of data you don't care about, etc., are all fine possibilities. So, don't use SHA-1 if you can help it. This is not to say that all uses are unsafe. There is also no need to panic. However, it is clearly not a good idea to continue using it. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: [tahoe-dev] SHA-1 broken!
Perry E. Metzger pe...@piermont.com writes: For example, Verisign has lots of cert infrastructure right now that uses SHA-1. Imagine if I now use the above described attack and start forging certs that look to all the world like they're from Verisign and claim that I'm a major bank, or to forge a CA that then forges certs that claim I'm a major bank. Ooops! Eric Rescorla correctly points out to me that Verisign randomizes SNs so it would be hard to attack them that way, but I'm sure not everyone who is in the root cert list in IE or Firefox does. It also is not going to be trivial to do this -- but it is now in the realm of possibility. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
