FC: Int'v with Microsoft's Scott Charney on benefits of key escrow
--- begin forwarded text Status: U Date: Sun, 3 Feb 2002 19:06:49 -0800 (PST) From: Declan McCullagh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: FC: Int'v with Microsoft's Scott Charney on benefits of key escrow Sender: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Politech archive on Scott Charney: http://www.politechbot.com/cgi-bin/politech.cgi?name=charney -- Forwarded message -- Date: Sat, 2 Feb 2002 22:47:41 -0500 (EST) From: Charles Platt [EMAIL PROTECTED] To: Declan McCullagh [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: More Charney Declan, I believe that since I was offered an interview by a public official, for subsequent publication, and since the magazine formally rejected the feature and explicitly told me I could offer it elsewhere, I have the (copy)right to offer you the following excerpts for distribution. --- Below are a few excerpts from the interview that Scott Charney granted when he was head of the computer crime division of the Department of Justice. These quotes were offered to me for publication in Wired magazine, but the magazine chose not to use the feature. Subsequently, with Mr. Charney's permission, I adapted some of the material for a feature in the L. A. Times, and he made some additional statements at that time, during a telephone interview. I had the impression, while listening to Mr. Charney, that he was speaking personally. I didn't get the sense that I was receiving canned policy statements dictated via the Clinton administration. However I must add that although Mr. Charney saw his interview transcript shortly after the time I wrote it (more than six years ago), he has not seen it since then, and his personal views may have changed since then. --Charles Platt - Charney on key escrow: if you look at the debate at cryptography, are we better off with more privacy and less law enforcement? I think key escrow makes a lot of sense for many reasons, not just law enforcement reasons. We invade privacy under important constraints such as the fourth amendement. But if a judge says we can go into someone's home, this is to protect society, which is a right for society at the expense of the individual. Suppose you buy a bigger lock, we bring a bigger sledgehammer. But cryptography is a lock so strong, society cannot penetrate even if 1) everyone agrees it's very important, 2) it will save many many lives, and 3) a court has authorized it after a neutral judicial review. People communicating about blowing up an airline--we can't intercept, so 400 people die. There are those who say that's the price of privacy, but you have to be able to live with the choices you make, and I'd rather save the 400 people. Charney on data monitoring: There's a concern about law enforcement engaging in illegal wiretaps, and there's no doubt you can find cases in history to justify that concern. But there's no evidence for systematic abuse of that process. I'd rather think that if a judge orders access to data and it satisfies the fourth amendement test, it should be permitted. Charney's computer background: I was programming in Cobol when I was eight. My father went to MIT and got into computers in the vacuum tube days. Then he worked for Seligman[?], mutual fund co on Wall Street, he wrote one of the first programs for processing mutual fund checks by computer. He had me writing flow charts, then do the punch cards, go into the air conditioned room with a Honeywell computer, we'd process the cards. So I had a long informal history with computers. I had a PC relatively early on. The first machine was XT class. And I program as a hobby, for the department, mostly in FoxPro, dBASE IV. I've toyed with C but I don't have the time. Charney on influencing the evolution of net culture: It's fun to be a part of it and have some small impact on what the future's going to look like and whether we're going to like it. The players include civil libertarians, academics, policy makers--and law enforcement is an important part of that. You only have to look at the front cover of Time magazine to wonder if criminal law is going to drive the internet. The answer is, it should not. The goal is to minimize harm but allow the benefits to be maximized. I think it's really important that we find ways to protect children, but not paint with such a broad brush that we chill the use of the net. Computer crime is a very important thing. If people abuse the networks, that's trouble. But you don't want networks in the next century to be driven by the computer crime issue. There's so many social benefits in the net, the democratizing factor, the free speech factor, we need to preserve those benefits while minizing the harm. - - POLITECH -- Declan McCullagh's politics and technology mailing
[ISN] Microsoft taps former DOJ cybercop for top security slot
--- begin forwarded text Status: U Date: Mon, 4 Feb 2002 00:29:30 -0600 (CST) From: InfoSec News [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [ISN] Microsoft taps former DOJ cybercop for top security slot Sender: [EMAIL PROTECTED] Reply-To: InfoSec News [EMAIL PROTECTED] http://www.computerworld.com/storyba/0,4125,NAV47_STO67871,00.html By Dan Verton and Deborah Radcliff Jan. 31, 2002 Computerworld has learned that Microsoft Corp. plans to name Scott Charney, the former chief of computer crime at the U.S. Department of Justice (DOJ) and a partner at New York-based PricewaterhouseCoopers, as its new chief security strategist. He replaces Howard Schmidt, who left the company on Jan. 28 to join the Bush administration (see story). Charney confirmed his appointment in a telephone interview this morning. He assumes his new position on April 1. The change in title from chief security officer to chief security strategist does not indicate a major shift in responsibilities, said Charney. Rather, it's actually a more accurate description of the role Howard had been filling, he said. I will be working to secure products and services and developing domestic and international polices that support a more secure infrastructure. Microsoft officials declined to comment on the appointment this morning. Sources close to the interview process said that while they wouldn't necessarily place Charney on the short list of top IT security experts in the country, he landed the job because of his long career at the DOJ, where he earned a reputation as a skilled and staunch antihacking, cybercrime hardliner. I realized that [one Microsoft executive] in particular was looking for someone with significant [government] ties and current contacts, said a source close to the selection process. Microsoft saw Howard [Schmidt] as unique and wanted to define the position around their real needs and the strengths of the new [executive]. Schmidt left Microsoft to become vice chairman of the President's Critical Infrastructure Protection Board and is admired by many throughout industry and government for having a rare combination of technical and interpersonal skills, especially on Capitol Hill. However, the job search for a new security strategist hasn't gone as smoothly as the company would have liked, said a senior Microsoft executive, speaking on condition of anonymity. It's hard to find somebody who knows the technology and has a little bit of business sense and can talk to people on Capitol Hill, said the executive. Senior officials at Microsoft viewed many of the candidates that applied for Schmidt's position as being good at one aspect of the job but not others, the executive said. Eric Friedberg, a former computer crimes coordinator at the DOJ who reported to Charney indirectly, called him one of the shining lights in information security. He's got national credibility, said Friedberg, who credited Charney with developing the DOJ's computer crime and intellectual property division. He is responsible for building the federal prosecutorial infrastructure for computer crimes cases. Alan Paller, research director at the SANS Institute in Bethesda, Md., said Charney is the best candidate to carry on Schmidt's Trusted Computing initiative -- not because of his technical background but because of his experience at the DOJ. Remember the job [Charney] has to do. He has to get marketing-driven development people to delay, assess and correct their tools so they do not cause harm to the outside world, Paller said. [Charney] is probably the best guy in the country to pull that off, because he comes from the purest understanding of the damage that the bad guys do. What a brilliant choice, because you have to prove to some very strong-willed people that it's worth doing this right. And who better than someone who's been in the heat of the battles of computer crime? An executive said that Microsoft founder Bill Gates and CEO Steve Ballmer had considered restructuring the company's security organization in the aftermath of Schmidt's departure. One option on the table included hiring two executives to fill the slot, with one individual focusing strictly on product architecture and the other taking responsibility for business strategy as well as physical and executive security. According to the executive, Schmidt approached Gates and Ballmer last year with a proposal to change the role of chief security officer from one involving oversight of both product and physical security, including executive protection, to strictly product development. Although Ballmer initially balked at the idea, Gates eventually agreed to the proposal and Schmidt shed his physical security responsibilities, the executive said. A source with ties to the interview process who asked that his name not be disclosed confirmed that the issue of placement and emphasis was a primary topic of discussion within Microsoft. However, there were no indications, the
Re: Welome to the Internet, here's your private key
It's worse: it's even accepted practice among certain security specialists. One of them involved in the development of a CA service once told me that they intended the CA to generate the key pair. After regaining consciousness I asked him why he thought violating one of the main principles of public key cryptography was a good idea. His answer basically ran as follows: if the CA is going to be liable, they want to be sure the key is strong and not compromised. He said that the PC platform of an ordinary user simply wasn't secure/trusted enough to generate keys on. The system might not generate `good enough' randomness, or might have been compromised by a trojan. Jaap-Henk On Sun, 3 Feb 2002 15:09:57 +0100 [EMAIL PROTECTED] writes: It is accepted practice among security people that you generate your own private key. It is also, unfortunately, accepted practice among non-security people that your CA generates your private key for you and then mails it to you as a PKCS #12 file (for bonus points the password is often included in the same or another email). Requests to have the client generate the key themselves and submit the public portion for certification are met with bafflement, outright refusal, or at best grudging acceptance if they're big enough to have some clout. This isn't a one-off exception, this is more or less the norm for private industry working with established (rather than internal, roll-your-own) CAs. This isn't the outcome of pressure from shadowy government agencies, this is just how things are done. Be afraid. -- Jaap-Henk Hoepman | Come sail your ships around me Dept. of Computer Science | And burn your bridges down University of Twente | Nick Cave - Ship Song Email: [EMAIL PROTECTED] === WWW: www.cs.utwente.nl/~hoepman Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590 PGP ID: 0xF52E26DD Fingerprint: 1AED DDEB C7F1 DBB3 0556 4732 4217 ABEF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Losing the Code War by Stephen Budiansky
I read the article (in the dead tree edition), and despite it's technical inaccuracies, thought it was generally pretty good. Don't forget that the MITM attack (which Schneier claims takes 2^(2n) = 2^112 time), also requires 2^56 blocks of storage. That's a lot, and the attack ceases to be parallelizable, unlike the straight brute-force attack. In fact, it's utterly intractable at the moment. Here's why: 2^56 bytes = 72 petabytes, and I suspect you'd need 8 bytes per entry, or about 1/2 an exabyte. By contrast, all of morpheus is currently less than half of one petabyte. Google indexes about 3 billion documents + 700 million usenet postings. At a an estimated 100kb per item, that's roughly the same as morpheus. I don't lose sleep over MITM attacks on 3DES. Peter Trei -- From: Ben Laurie[SMTP:[EMAIL PROTECTED]] Sent: Saturday, February 02, 2002 8:57 AM To: marius Cc: [EMAIL PROTECTED] Subject: Re: Losing the Code War by Stephen Budiansky marius wrote: But there was an utterly trivial fix that DES users could employ if they were worried about security: they could simply encrypt each message twice, turning 56-bit DES into 112-bit DES, and squaring the number of key sequences that a code breaker would have to try. Messages could even be encrypted thrice; and, indeed, many financial institutions at the time were already using Triple DES. Not quite true. Encrypting each message twice would not increase the effective key size to 112 bits. There is an attack named meet in the middle which will make the effective key size to be just 63 bits. ?? 56 bits plus a little, surely. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Welome to the Internet, here's your private key
One other scheme I've seen, and which, while it doesn't give me warm fuzzies, seems reasonable, is to issue the the enduser a smartcard with a keypair on it. The SC generates the pair onboard, and exports only the public half. The private half never leaves the SC (there is no function on the card to export it). If you trust the above, then the only copy of the private key is on the SC, despite it having been generated without the end users participation. Peter -- From: Jaap-Henk Hoepman[SMTP:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 8:45 AM To: [EMAIL PROTECTED] Subject: Re: Welome to the Internet, here's your private key It's worse: it's even accepted practice among certain security specialists. One of them involved in the development of a CA service once told me that they intended the CA to generate the key pair. After regaining consciousness I asked him why he thought violating one of the main principles of public key cryptography was a good idea. His answer basically ran as follows: if the CA is going to be liable, they want to be sure the key is strong and not compromised. He said that the PC platform of an ordinary user simply wasn't secure/trusted enough to generate keys on. The system might not generate `good enough' randomness, or might have been compromised by a trojan. Jaap-Henk On Sun, 3 Feb 2002 15:09:57 +0100 [EMAIL PROTECTED] writes: It is accepted practice among security people that you generate your own private key. It is also, unfortunately, accepted practice among non-security people that your CA generates your private key for you and then mails it to you as a PKCS #12 file (for bonus points the password is often included in the same or another email). Requests to have the client generate the key themselves and submit the public portion for certification are met with bafflement, outright refusal, or at best grudging acceptance if they're big enough to have some clout. This isn't a one-off exception, this is more or less the norm for private industry working with established (rather than internal, roll-your-own) CAs. This isn't the outcome of pressure from shadowy government agencies, this is just how things are done. Be afraid. -- Jaap-Henk Hoepman | Come sail your ships around me Dept. of Computer Science | And burn your bridges down University of Twente | Nick Cave - Ship Song Email: [EMAIL PROTECTED] === WWW: www.cs.utwente.nl/~hoepman Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590 PGP ID: 0xF52E26DD Fingerprint: 1AED DDEB C7F1 DBB3 0556 4732 4217 ABEF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Welome to the Internet, here's your private key
You sound surprised? I recently asked my bank[1] for a solvency statement on a personal account and they responded that they were not allowed to provide such statements. When pressed for an explanation I was told that handing out those statements caused them too much litigation. Apparently when the bank states that Alice has been a customer since 23-01-1980 and as of 12-12-1999 her account is in good standing. they can (and have indeed been) be sued when Alice goes bankrupt in 2002. This despite the fact that the statement obviously does not make any claim about Alice in 2002. Now, the bank may very well win the court case, or they may not. Whatever the outcome, it will cost them. The moral of the story is: when the legal system allows for silly cases like this, alternative protective measures[2] will be put in place, such as not handing out solvency statements[3], or forcing a user to accept a CA-generated private key. The problem here is not with the technical competence of the CA but rather with the CA being held liable and being forced to mitigate the risk of losing lots of money. Technically speaking, having the CA generate the private keys allows the user to repudiate signatures made with the key. After all, the CA (or one of its employees) could have leaked the key or have signed stuff with it. Practically speaking this would probably be solved by passing an additional law that declares CAs trustworthy by definition. After all, if you don't pass such a law, the PKI cannot work in the current legal framework. And CAs are run by the good people, right? What is wrong with effective key escrow for signature keys!? ;-p We do not even want to think about the conflicts of interest: what incentive is there for a CA to report that it lost a user's private key? -J [1] ABN-AMRO. [2] Alternative because the legal system is supposed to protect the honest party here but obviously fails. [3] The bank does have provisions for providing solvency statements on business accounts. They have insurance and make you pay (indirectly). On Monday, February 4, 2002, at 08:45 , Jaap-Henk Hoepman wrote: It's worse: it's even accepted practice among certain security specialists. One of them involved in the development of a CA service once told me that they intended the CA to generate the key pair. After regaining consciousness I asked him why he thought violating one of the main principles of public key cryptography was a good idea. His answer basically ran as follows: if the CA is going to be liable, they want to be sure the key is strong and not compromised. He said that the PC platform of an ordinary user simply wasn't secure/trusted enough to generate keys on. The system might not generate `good enough' randomness, or might have been compromised by a trojan. Jaap-Henk On Sun, 3 Feb 2002 15:09:57 +0100 [EMAIL PROTECTED] writes: It is accepted practice among security people that you generate your own private key. It is also, unfortunately, accepted practice among non-security people that your CA generates your private key for you and then mails it to you as a PKCS #12 file (for bonus points the password is often included in the same or another email). Requests to have the client generate the key themselves and submit the public portion for certification are met with bafflement, outright refusal, or at best grudging acceptance if they're big enough to have some clout. This isn't a one-off exception, this is more or less the norm for private industry working with established (rather than internal, roll-your-own) CAs. This isn't the outcome of pressure from shadowy government agencies, this is just how things are done. Be afraid. -- Jaap-Henk Hoepman | Come sail your ships around me Dept. of Computer Science | And burn your bridges down University of Twente | Nick Cave - Ship Song Email: [EMAIL PROTECTED] === WWW: www.cs.utwente.nl/~hoepman Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590 PGP ID: 0xF52E26DD Fingerprint: 1AED DDEB C7F1 DBB3 0556 4732 4217 ABEF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Jeroen C. van Gelderen - [EMAIL PROTECTED] Economics is a theoretical science and as such abstains from any judgement of value. It is not its task to tell people what ends they should aim at. It is a science of the means to be applied for attainment of ends chosen, not, to be sure, a science of the choosing of ends. Ultimate decisions, the valuations and the choosing of ends, are beyond the scope of any science. Science never tells a man how he should act; it merely shows how a man must act if he wants to attain definite ends. -- Ludwig von Mises
RE: Welome to the Internet, here's your private key
ignoring for the moment the question of why certificates would be needed at all then public/private key technology is currently being used for (at least) two distinct different business processes 1) authentication 2) encryption The business process of human person authentication has some requirements about impersonation ... leading to a business requirement that only the person being authenticated should have access to the authentication material (aka only the specific person can originate an authenticated transaction). A hardware token that generates the key-pair inside the token and the private key can never leave the token can satisfy unique person authentication thru one-factor authentication something you have. The person is the only one with their specific token and that token is the only container for their specific private key. The business process for encryption can be totally different. The assets being encrypted may be corporate assets, not the individuals. In the case of using public/private key in conjunction with encryption of corporate assets, the business requirements totally change. The corporation has a valid requirement for recoverying valuable corporate assets under any condition (failure/loss of token, person leaves the company, etc). In the person authentication case, the impersonation issue typically is viewed as outweighing the failure/loss of token issue. In the case of encryption of corporate assets, the failure/loss of the token issue would typically outweight any issues of guarenteeing absolutely that the key can only occur in a single place not knonw by anybody. The requirement for a private key only existing in a single place under control of a single person isn't an attribute of the public/private key technology it is an attribute of a specific business process and associated business requirements related to that business process. However, there are other business process applications for public/private key technology than human person authentication which can have somewhat different requirements. aads chip strawman public/private key hardware token w/o any certificates http://www.garlic.com/~lynn/index.html#aads random refs: http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security http://www.garlic.com/~lynn/aadsm9.htm#pkcs12 A PKI Question: PKCS11- PKCS12 http://www.garlic.com/~lynn/aadsm9.htm#pkcs12b A PKI Question: PKCS11- PKCS12 http://www.garlic.com/~lynn/aadsm9.htm#pkcs12d A PKI Question: PKCS11- PKCS12 http://www.garlic.com/~lynn/aadsm10.htm#diskcrypt Looking back ten years: Another Cypherpunks failure (fwd) http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink) http://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0 http://www.garlic.com/~lynn/2001n.html#54 The demise of compaq http://www.garlic.com/~lynn/2002.html#7 The demise of compaq [EMAIL PROTECTED] on 2/4/2002 9:13 am wrote: One other scheme I've seen, and which, while it doesn't give me warm fuzzies, seems reasonable, is to issue the the enduser a smartcard with a keypair on it. The SC generates the pair onboard, and exports only the public half. The private half never leaves the SC (there is no function on the card to export it). If you trust the above, then the only copy of the private key is on the SC, despite it having been generated without the end users participation. Peter - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Unbreakable? (fwd)
There are plenty of 'thought experiment' crypto systems which are utterly infeasible in practice. Rabin's is one. It does have perfect forward secrecy in that if Eve doesn't know ahead of transmission time what part of the keystream to grab, she can't later decrypt the message. But, as Nicholas points out, it doesn't solve the key distribution problem, merely shifts it. Alice and Bob still have find some way to securely coordinate beforehand what part of the 'random' bitstream they will use as their OTP. There are many other problems: * The HW needed to generate cryptographically sound random data at the required rate is extremely expensive, if it exists at all. * The HW needed to recieve data at that rate is very expensive. * Since accuracy is required, error correcting codes will have to be included, increasing the data rate still further. *putting up a constellation of satellites is also very expensive - where's the revenue to do all this coming from? ...and the big one: Could you *trust* the 'randomness' of a bitstream handed you from a source you cannot check? Sorry, folks, this one is a non-starter. Peter Trei -- From: Nicholas Brawn[SMTP:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 1:47 AM To: Sean McGrath Cc: [EMAIL PROTECTED] Subject: Re: Unbreakable? (fwd) Correct me if I'm wrong, but isn't such a system feasible by: 1. Having the network infrastructure available to support the continuous traffic loads. 2. Having a suitable RNG source that can cope with the reseeding/etc requirements of encrypting bulk data. 3. Having a mechanism to insert genuine information into these massive streams of data. I suppose the issue is communicating to the third party which part of the data contains the interesting stuff. From what Rabin is saying, it appears that the increased security is achieved by the third party not knowing what is important and what isn't. How you communicate this with your trusted third party is the problem. You can't simply send a transmission when a new section of interesting stuff is coming through, because then the evil folk can simply watch for the notification, then capture that section of the traffic. Perhaps you could send a transmission that says in x bytes time for the next x bytes, is the next message. That would include some latency that the evil third party can't reliably interperet. But does that work for frequent transmissions? Seems interesting nevertheless. Nick -- Real friends help you move bodies. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unbreakable? (fwd)
This suffers from the same flaw as the last proposal: the security lies in the idea that you can't store the data for long enough to be able to decrypt the message that says where in the bitstream your data is. However, this is defeatable by a delay line of sufficient length, just like the last idea (where, if you remember, the keying material was in the fast random stream instead). Cheers, Ben. Sean McGrath wrote: -- Forwarded message -- Date: Sun, 3 Feb 2002 15:49:51 -0500 From: R. A. Hettinga [EMAIL PROTECTED] To: Digital Bearer Settlement List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Unbreakable? http://www.idg.net/crd_idgsearch_1.html?url=http://www.cio.com/archive/020102/et_development.html UNDER DEVELOPMENT Encryption Unbreakable? AS MYSTICS SEARCH for the lost island of Atlantis and UFO buffs seek out alien spacecraft, cryptologists are continuing their own quest to create an unbreakable code. Michael Rabin, a Harvard University computer science professor, believes he has moved cryptology a step closer to its Holy Grail by developing a code that's undecipherable, even by those who have access to both the cypher text and unlimited computing power. Advertisers Rabin's Hyper-Encryption technology, which uses a device that quickly generates a deluge of random bits, relies on both time and money to thwart even the most dedicated code breaker. A coded message would be hidden within the bits like raisins in a pudding, quips Rabin. While anyone can read the random bits, the transmission rate is so high that storing all of the stream for analysis would be either technically unfeasible or cost prohibitive. Hyper-Encryption has sparked the interest of several U.S. government agencies, says Rabin. He also claims to have received inquiries from some wealthy investors and at least one major venture capital fund. But Rabin states he's not currently interested in the technology's commercial potential. Right now, commerce comes second to science, he says. Hyper-Encryption, however, is not entirely trouble free. The chief concern is cost, since the technology requires users to send continuous, intense streams of high-speed data across already bandwidth-starved networks. Rabin's solution is to create a dedicated global satellite system. The cost could be shared by its users, he says. In any case, Hyper-Encryption is designed to safeguard highest-level government secrets, not routine commercial and personal transmissions. It's most appropriate for protecting national interests and large sums of money, says Rabin. Although Hyper-Encryption exists only on the blackboard, Rabin maintains that the technology is ready for use. There's mathematical proof the Hyper-Encryption provides everlasting security, so there's nothing left to do but implement it, he says. -John Edwards -- - 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] -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Welome to the Internet, here's your private key
At 10:20 AM -0800 2/4/02, Bill Stewart wrote: There are special cases where the user's machine doesn't have the CPU horsepower to generate a key - PCs are fine, but perhaps Palm Pilots and similar handhelds are too slow (though a typical slow 33MHz 68000 or Dragonball is faster than the 8086/80286 MSDOS machines that PGP originally ran on.) Cash machines may be too slow, but they normally run symmetric crypto. A smartcard-only system probably _is_ too limited to generate keys, but that's the only realistic case I see. It may depend on the public key system you are using. Where you have to search for numbers which have certain mathematical properties (like with RSA), then you can indeed use a bunch of CPU. For systems like DSA, where the private key is in essence a random number, there is not searching, and key generation is a lot faster. Cheers - Bill - Bill Frantz | The principal effect of| Periwinkle -- Consulting (408)356-8506 | DMCA/SDMI is to prevent| 16345 Englewood Ave. [EMAIL PROTECTED] | fair use. | Los Gatos, CA 95032, USA - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Welome to the Internet, here's your private key
I'm not the local expert on this, but there are SCs with built-in crypto accelerators. They are designed for the use I described: * Generate an RSA key pair on board, * export the public key, * re-import the certificate, * wrap/unwrap a data block (typically a session key or hash for signing) using the onboard key pair without ever exporting the secret half of the key pair. While they typically only use a PIN or passphrase for protection, they usually will commit electronic seppuku if too many (typically 3) bad PINs or passphrases are entered. With these, you can let your CA admin run the SW to create the keys and sign the public key, and still have reasonable assurance that he has not snagged a copy of the private key. Peter Trei -- From: Bill Frantz[SMTP:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 3:41 PM To: Bill Stewart; [EMAIL PROTECTED] Subject: RE: Welome to the Internet, here's your private key At 10:20 AM -0800 2/4/02, Bill Stewart wrote: There are special cases where the user's machine doesn't have the CPU horsepower to generate a key - PCs are fine, but perhaps Palm Pilots and similar handhelds are too slow (though a typical slow 33MHz 68000 or Dragonball is faster than the 8086/80286 MSDOS machines that PGP originally ran on.) Cash machines may be too slow, but they normally run symmetric crypto. A smartcard-only system probably _is_ too limited to generate keys, but that's the only realistic case I see. It may depend on the public key system you are using. Where you have to search for numbers which have certain mathematical properties (like with RSA), then you can indeed use a bunch of CPU. For systems like DSA, where the private key is in essence a random number, there is not searching, and key generation is a lot faster. Cheers - Bill - Bill Frantz | The principal effect of| Periwinkle -- Consulting (408)356-8506 | DMCA/SDMI is to prevent| 16345 Englewood Ave. [EMAIL PROTECTED] | fair use. | Los Gatos, CA 95032, USA - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Welome to the Internet, here's your private key
One could claim that one of the reasons for using RSA digital signatures with smart cards rather than DSA or EC/DSA is the DSA EC/DSA requirement for quality random number generation as part of the signature process. A lot of the RSA digital signatures have the infrastructure that creates the message to be signed to also generate and include a large random number (nonce) in the message. This was acceptable to a large class of smartcards that didn't have quality random number generation (either for the purposes of ken-gen and/or signatures). Effective because of the short-comings of the random number generation ... they had external source doing the key-gen and injecting the key ... along with no requirement for (on-card) random number during the signing process (typically a requirement that the external source include a random nonce in the body of the message). 1) A typical message would have a 20-byte nonce random number, which computed to a 20-byte SHA1 and then encrypted with RSA resulting in 20-byte signature (basic message plus 40-byte infrastructure overhead, signature plus nonce). 2) It is possible to compute a 20-byte SHA1 against the basic message, and then do a DSA signature resulting in 40-byte signature (basic message plus 40-byte infrastructure overhead). The difference between #1 and #2 is that a smartcard has eliminated any dependency in number #1 on the infrastructure providing the message with a random number. Cards with quality random numbers ... can 1) do on card key-gen 2) use DSA or EC/DSA 3) remove dependency on external source to include random number in message to be signed. DSA EC/DSA because they have a random number as parting of the signing process precludes duplicate signatures on the same message ... multiple messages with the same content same exact signature is a replay. DSA EC/DSA doing multiple signings of the same content will always result in a different signature value. I've heard numbers on many of the 8bit smartcards ... power-cycle the card each time it is asked to generate a random number do random number generation 65,000 times and look at results. For some significant percentage of 8bit cards it isn't unusual to find 30 percent of the random numbers duplicated. [EMAIL PROTECTED] on 2/4/2002 2:17 pm wrote: An 8-bit 1/2 MIP smart card can generate 1024 bit RSA key pair in about 20 seconds and 512 bit key pair in less than 5 seconds. Since this isn't typically done in the checkout lane this is certainly an acceptable time/security trade-off by many lights. A device that can't generate a key pair probably has other more compelling shortcomings as a security token. Cheers, Scott - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Losing the Code War by Stephen Budiansky
At 11:00 AM -0500 2/4/02, Trei, Peter wrote: Don't forget that the MITM attack (which Schneier claims takes 2^(2n) = 2^112 time), also requires 2^56 blocks of storage. That's a lot, and the attack ceases to be parallelizable, unlike the straight brute-force attack. In fact, it's utterly intractable at the moment. Here's why: 2^56 bytes = 72 petabytes, and I suspect you'd need 8 bytes per entry, or about 1/2 an exabyte. With 120GB drives starting at about $200, the storage requirements can be met today, albeit not cheaply. In four years or so, when we have 1TB drives, it will just be that much easier. But I'm not losing any sleep either. -Jon Simon -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Welome to the Internet, here's your private key
At 2:09 PM -0800 2/4/02, [EMAIL PROTECTED] wrote: One could claim that one of the reasons for using RSA digital signatures with smart cards rather than DSA or EC/DSA is the DSA EC/DSA requirement for quality random number generation as part of the signature process. A lot of the RSA digital signatures have the infrastructure that creates the message to be signed to also generate and include a large random number (nonce) in the message. This was acceptable to a large class of smartcards that didn't have quality random number generation (either for the purposes of ken-gen and/or signatures). Effective because of the short-comings of the random number generation ... they had external source doing the key-gen and injecting the key ... along with no requirement for (on-card) random number during the signing process (typically a requirement that the external source include a random nonce in the body of the message). 1) A typical message would have a 20-byte nonce random number, which computed to a 20-byte SHA1 and then encrypted with RSA resulting in 20-byte signature (basic message plus 40-byte infrastructure overhead, signature plus nonce). 2) It is possible to compute a 20-byte SHA1 against the basic message, and then do a DSA signature resulting in 40-byte signature (basic message plus 40-byte infrastructure overhead). The difference between #1 and #2 is that a smartcard has eliminated any dependency in number #1 on the infrastructure providing the message with a random number. The quality of random numbers available to a smart card is a very important point. Unless you can trust the external source of random numbers, DSA signatures (and elliptic curve DSA) don't strike me as very secure. In Applied Cryptography II, Schneier says, If Eve ever recovers a K that Alice used to sign a message, perhaps by exploiting some properties of the random-number generator that generated K, she can recover Alice's private key, X. If Eve ever gets two messages signed using the same K, even if she doesn't know what it is, she can recover X. I can easily imagine a POS terminal hacked to record both the random number, and the signature, as part of a card cloning scam. On the other hand, building a good source of random numbers into the card doesn't strike me as being that difficult. (Although running a FIPS-140 test every time a signature is generated (card is powered up), might be a performance problem.) It is probably worth examining the protocols for bad random number attacks on the nonces. Cheers - Bill - Bill Frantz | The principal effect of| Periwinkle -- Consulting (408)356-8506 | DMCA/SDMI is to prevent| 16345 Englewood Ave. [EMAIL PROTECTED] | fair use. | Los Gatos, CA 95032, USA - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unbreakable? (fwd)
With regards to the storage requirements in order to capture the massive amounts of data in Rabin's system, has anyone correlated the growth rate in mass storage devices against the network bandwidth speeds available? Ie, is there a point at which we'll have cheap enough storage to make such a system pointless (ie, we'll be able to capture all data and analyse at leisure)? Are we already at or close to that point today? Nick -- Real friends help you move bodies. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
