Re: my periodic rant on quantum crypto
At 03:37 PM 4/12/04 -0400, Perry E. Metzger wrote: QC can only run over a dedicated fiber over a short run, where more normal mechanisms can work fine over any sort of medium -- copper, the PSTN, the internet, etc, and can operate without distance limitation. Nice essay. I especially liked the discussion of authentication. Its also the case AFAIK that the quantum-carrying fiber can only carry one photon at a time. (Perhaps you can multiplex different frequencies, if your demultiplexor doesn't change the quantum properties). Now while there *is* a lot of dark fiber, sending one photon at a time is a pretty good way to keep the construction crews digging up roads :-) Similar quantum-hype is sometimes argued in RNG discussions by those with very narrow views of what an RNG needs and consists of. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Cryptonomicon.Net - Key Splitting : First (and Second) Person Key Escrow
http://www.cryptonomicon.net/modules.php?name=Newsfile=printsid=742 Key Splitting : First (and Second) Person Key Escrow Date: Monday, April 12 @ 08:00:00 EDT Topic: Algorithms / Asymmetric Cipher One of our missions here at Cryptonomicon.Net is to advocate the use of appropriate cryptographic technology. One technology that's sorely missed in a number of commercial products is key splitting. Never heard of key splitting? That's not surprising. A recent google search on 'key-split' and 'key-splitting' turned up about 6000 results, while a search on 'PKI' returned over a million hits. 'Secret Sharing', the technical term, produces a few more hits, but not nearly as many as 'PKI'. Key Splitting, sometimes inaccurately called First Person Escrow, is a technique by which some secret string of bits (like you're web server's private key) is split into two or more shares. The shares are distributed to trusted individuals to hold safe until such time as they are needed. In the event that your secret is destroyed (or more likely you forget the PIN or password used to encrypt your web server's private key,) the shares are recombined to recover the secret. Key Splitting is like an insurance policy for your keys. There are more than a couple algorithms for creating key shares. Menezes, et al.'s Handbook of Applied Cryptography presents the subject in a good way. We especially like the Handbook of Applied Cryptography as a source, as they provide a good deal of the math for math-minded implementors, but also spend time discussing the development of ideas and algorithms. Readers can also download sections of the HAC as .PDF's. Bruce Schneier's perennial favorite Applied Cryptography also describes key splitting algorithms, and for the less mathematically inclined has an expanded plain English description. Why should you care about Key Splitting? With the growth of crypto-enabled products: browsers, email clients, VPN clients, wireless access points, et cetera; more and more people are using strong encryption to protect their privacy or to establish their online identities. But in the rush to get products out the door, sometimes product managers forget to support proper key management techniques. While we've yet to see a product that gives out it's private keys to anyone who asks, we have seen a number of products where keys are encrypted under device master keys. What happens if you lose the device master key? Well... the answer from the support people is don't lose the master key! Some of these products have master keys derivable from serial numbers and salt values. One product we've seen (and you know who you are) derives it's device master key from it's serial number without salting. An attacker wishing to steal the device's master key (and all of the keys it protects) needs only to hash all possible serial numbers. As there were less than 10,000 of these devices made, this is certainly a tractable problem for an attacker. Key Splitting allows your IT staff to essentially back up the cryptographic module protecting your sensitive secret and private keys. If you're thinking that this sounds like it could be a security problem, then give yourself a few extra points. Key Splitting systems should be used in conjunction with a well defined IT process to protect the integrity of the system. There are, fortunately, several examples of how to properly do key splitting from a procedural point of view; your local CISSP should be able to find a process that works for you as it's unlikely that any one process will work for ALL environments. If you are in a position where you specify security features for your IT infrastructure, surprise your sales rep by asking What key splitting features does your product support? Give the supplier extra points if the sales rep understands what you're asking. If you are a product manager, please add key splitting to the list of key management features in your product. Security is playing a larger role in modern IT systems, and customers are starting to add modern key management features to their list of best common practices. By supporting your customers' practices, you're only making your products more marketable. This article comes from Cryptonomicon.Net http://www.cryptonomicon.net/ The URL for this story is: http://www.cryptonomicon.net//modules.php?name=Newsfile=articlesid=742 -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.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' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Mac_crypto] Apple should use SHA! (or stronger) to authenticate software releases
On Mon, Apr 12, 2004 at 06:00:26PM -0700, Joseph Ashwood wrote: From: Nicko van Someren [EMAIL PROTECTED] It's not clear to me that you need all this complexity. All you need if to arrange that the attacker does not know exactly what will be signed until it has been signed. So you append some randomness from a good random number source to the end of the file just before you sign it, and you're safe. I'm not quite sure that's a good solution, that random tail provides exactly what the attacker needs to make this as easy as possible. Since the random tail cannot be know beforehand it cannot be known by the user of the patch. If anything this would actually make an attack easier. It is only if the random data is from a _bad_ random source that you might actually gain some security (a bad source would at the very least have redundancy, internal or external, that could be verified by the end user, making it more complex to compute valid numbers). Instead it would probably be more useful to include the same random number between each file, this should short circuit all but the most fatal of hash flaws, but might open up other possibilities (I don't have the time right now to prove things about it). You and Nicko are discussing different attacks. One attack is Find two patches which have the same MD5. This falls to a birthday-paradox attack with 2^64 work, and is somewhat easier if the patch format includes a random tail. (The collision attack needs 64 bits of controllable input in the message.) Short of a compromise of the developer's machine, it's hard to see how this type of hash collision can be leveraged into getting a malicious patch distributed as genuine. Another attack is Submit a carefully sculpted change through normal channels which results in the new patch having an attacker-determined hash value. The work factor is somewhat difficult to estimate, but is probably a significant multiple higher than 2^64, primarily due to the more-complex iterator due to having to emulate the workflow of the developer when computing hash values. In this attack, the assumption is that the attacker submits a diff (a very innocuous one, but with a special structure), which is integrated, and the result is a (binary) patch which is signed by the developer. The attacker was able to craft the diff so as to cause MD5(patchA) to match MD5(patchB) and then distributes patchB with the signature from patchA. This second attack is made infeasible by simply appending 64 bits of randomness to the patch before signing it. Since the attacker could not possibly know those bits, so his work required increases by a *power* (I believe -- haven't done the math carefully) of 64. These are straightforward extensions of Van Oorschot Wiener's 1994 paper Parallel Collision Search with Application to Hash Functions and Discrete Logarithms. The obvious conclusion is that nobody should be using MD5 any more; follow the OpenBSD project's lead and distribute SHA1 alongside your MD5 distribution. Or SHA-256 if you're really paranoid. On a related note does anyone happen to know of any useful papers on patching, specifically patch integrity/source verification? I don't see how this is any different from the generic source validation problem. -andy - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
DRM of the mirror universe
Hello, I had this idea about reversing the roles of the actors in a typical DRM system, and thinking about where it might lead. I hope the idea will stimulate some discussion: is the idea dead on arrival? Does it have merit? Is it feasible? Is there something like this being built today? Here goes... The main idea is this: the ordinary consumer (you or me) becomes the content provider. The content provider (the corporation) becomes the consumer. Thus, we have now reversed the roles. But what content could the consumer-become-content-provider, the ordinary person, you or me (let's call this actor the user), produce? What could be interesting and rare for the corporation but found in abundance from the user? One answer is personal data. Upon request by some corporation, the user decides to accept the request. The user creates a DRM-protected file containing the personal data the user wishes to reveal. When proper DRM technology is being used (the same technology used to protect e.g. movies), the user can be sure that the corporation is not able to * use the personal data after the license period (e.g. 2 hours) has expired * share the personal data with third party companies without permission * do other non-authorized nasty stuff with the personal data Using the evil DRM technology a very good (good and evil is subjective!) purpose can be achieved: the preservation of the user's privacy. The user gets to decide who can receive and use the information in the first place. The user can disallow use by companies the user considers not to be trustworthy, or who he considers to be immoral, or annoying, or who have the most idiotic advertisements. This kind of application of DRM would probably guarantee privacy of the personal data of each individual person, while at the same time allow companies access to that data with the consent of the user. To me this seems like best of both worlds. The role-reversal idea could help in achieving balance between the concerns of the corporation and the concerns of the consumer, and benefit all parties involved. At the very least, the idea can offer possibilities for stimulating and interesting discussion. (Note: I wrote this originally as a blog article, and it's mostly copy + paste from there with minor editing.. and some attitude removed :-) ) -- GPG 0x6EE92B3E - http://www.lut.fi/~jnurmine/ signature.asc Description: This is a digitally signed message part
Re: TCFS available for NetBSD-1.6.2
VaX#n8 wrote: I've done a survey of the various crypting file system tools, would anyone be interested in a summary of available options? This would likely be an interesting read for many on the list. Perhaps you can put up a PDF somewhere? Cheers, Ivan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
AES suitable for protecting Top Secret information
I haven't seen this mentioned on the list, so I thought I'd toss it out. According to http://www.nstissc.gov/Assets/pdf/fact%20sheet.pdf , AES is acceptable for protecting Top Secret data. Here's the crucial sentence: The design and strength of all key lengths of the AES algorithm (i.e., 128, 192 and 256) are sufficient to protect classified information up to the SECRET level. TOP SECRET information will require use of either the 192 or 256 key lengths. --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Definitions of Security?
[EMAIL PROTECTED] wrote: Hi, I'm looking for interesting and unusal defitions of the term Security (or secure). I'm fully aware that it is difficult or impossible to give a precise, compact, and universal definitions, and some book authors explicitely say so. However, there are definitions (or attempts to give those), and I'd be interested to compare them. If you know of any definition that might be interesting for any reason, please send me a link or citation. thanx a well-informed sense of assurance that information risks and controls are in balance From: James M. Anderson, Why We Need a New Definition of Information Security, Computers Security, vol 22, no. 4, May 2003, 2003, pages 308-313. -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DRM of the mirror universe
Jani Nurminen wrote: [...] But what content could the consumer-become-content-provider, the ordinary person, you or me (let's call this actor the user), produce? What could be interesting and rare for the corporation but found in abundance from the user? One answer is personal data. Upon request by some corporation, the user decides to accept the request. The user creates a DRM-protected file containing the personal data the user wishes to reveal. When proper DRM technology is being used (the same technology used to protect e.g. movies), the user can be sure that the corporation is not able to * use the personal data after the license period (e.g. 2 hours) has expired * share the personal data with third party companies without permission * do other non-authorized nasty stuff with the personal data Using the evil DRM technology a very good (good and evil is subjective!) purpose can be achieved: the preservation of the user's privacy. Welcome to ACME.com. In order to do business with ACME.com we require that your personal data be provided without restriction. If you don't like that, no problem. Feel free to do business with others. (Don't believe that? Gee, how many websites require javascript, java, activeX?) Paul - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Definitions of Security?
According to [EMAIL PROTECTED]: I'm looking for interesting and unusal defitions of the term Security (or secure). See http://en.wikipedia.org/wiki/Security ciao... -- Lars Eilebrecht [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Definitions of Security?
At 08:01 AM 4/14/2004, [EMAIL PROTECTED] wrote: Hi, I'm looking for interesting and unusal defitions of the term Security (or secure) there was a discussion on PAIN taxonomy for security earlier in the year ... misc. references http://www.garlic.com/~lynn/aadsm17.htm#3 Non-repudiation (was RE: The PAIN mnemonic) http://www.garlic.com/~lynn/aadsm17.htm#5 Non-repudiation (was RE: The PAIN mnemonic) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DRM of the mirror universe
On Tue, Apr 13, 2004 at 11:05:10PM +0300, Jani Nurminen wrote: But what content could the consumer-become-content-provider, the ordinary person, you or me (let's call this actor the user), produce? What could be interesting and rare for the corporation but found in abundance from the user? One answer is personal data. Upon request by some corporation, the user decides to accept the request. The user creates a DRM-protected file containing the personal data the user wishes to reveal. When proper DRM technology is being used (the same technology used to protect e.g. movies), the user can be sure that the corporation is not able to * use the personal data after the license period (e.g. 2 hours) has expired * share the personal data with third party companies without permission * do other non-authorized nasty stuff with the personal data DRM only works because the supplier of the content has itself certified the software used to process the content, or trusts the entity that has certified the software. Who would you trust to certify the software that some corporation will use to process your personal data? Another issue is that DRM works best to protect massive content. For example, whether you are HIV-positive is a single bit. How would you prevent me from capturing that bit from my screen with a camera? If the DRM prevents any association of your data with your identity, the data will not be worth much to me. Also, even assuming the DRM works, what prevents the user from presenting false data? The only data I can't lie about is what I generate as a side-effect of something else, for example a click-stream. But that's already available reliably to the server(s) now, without DRM. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DRM of the mirror universe
Jani Nurminen wrote: I had this idea about reversing the roles of the actors in a typical DRM system, and thinking about where it might lead. [...] This kind of application of DRM would probably guarantee privacy of the personal data of each individual person, while at the same time allow companies access to that data with the consent of the user. This kind of idea has been discussed before. Personally, I'm not convinced we're likely to see this take off any time soon. There are some technological barriers, but a bigger one may well be incentives. I'd argue the true source of many privacy problems may be more from the imbalance in bargaining power between the consumer and the corporation (the corporation can often more or less dictate terms -- or, at least, there is not much room for personalized negotiation and bargaining). Fixing the power imbalance may well be a precondition to deploying technology-based privacy defenses (be it DRM, or anything else). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AES suitable for protecting Top Secret information
I missed that announcement too -- but Wikipedia, the web-based Free Encyclopedia, caught it! See Wikipedia on AES at: http://en.wikipedia.org/wiki/AES The Wikipedia module on AES Security has a link to the same NSA fact sheet Steve mentioned. I was surprised. I thought, as in so many other things, the NSA was going to say one thing and do another. Suerte, _Vin At 4/14/2004, Steve Bellovin wrote: I haven't seen this mentioned on the list, so I thought I'd toss it out. According to http://www.nstissc.gov/Assets/pdf/fact%20sheet.pdf , AES is acceptable for protecting Top Secret data. Here's the crucial sentence: The design and strength of all key lengths of the AES algorithm (i.e., 128, 192 and 256) are sufficient to protect classified information up to the SECRET level. TOP SECRET information will require use of either the 192 or 256 key lengths. --- Vin McLellan + The Privacy Guild + [EMAIL PROTECTED] 22 Beacon St., Chelsea, MA 02150-2672 USA - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
