Re: jointly create a random value for corrupted party
Anna Rikova wrote:
maybe this is a silly question, but at the moment I
don't know how to solve it. Assume there are 4 partys
A,B,C,D. Now the parties B,C,D want to create a random
value r for A, so that each party B,C,D can verify
afterwards, that A uses indeed the random value r, but
doesn't know the value of r.
I thought of the following solution, but it has a
problem:
Each party I \in{B,C,D} broadcasts a value g^{r_i} mod
p, where r_i is random, p is a large prime and g is a
generator. After that each party sends to A the value
r_i secretly. Aftern that A can compute:
r= r_B + r_C + r_D. If A then uses this value in the
form of g^r everyone can verify that A uses every r_i
in g^r.
What does it mean A uses this value in the form of g^r?
A uses r not g^r, doesn't it?
This is a weak point: from A's use of r every party should be able to compute
g^r mod p with no knowledge of r.
I assume you know how to organize that.
This scheme has one problem (at least I think so): The
partys B,C wait till D braodcasts her value g^{r_D}.
Then they choose their values r_B and r_C so that g^r
has a special characteristic e.g. the last bit of g^r
is zero. Then r is not randomly disributed in Z_p,
cause only values are allowed for r, which yield to
g^r with last bit zero.
What's about the following modification?
Each party i\in{B,C,D} sends to A the value of r_i secretly.
Upon receiving all three values A broadcasts
q_1=g^{r_B} mod p, q_2=g^{r_C} mod p, q_3=g^{r_D} mod p.
The party i then verifies that the value r_i was used to produce one of q_1,
q_2, q_3.
From A's use of r every party computes g^r mod p and verifies that g^r=q1*q2*q3.
Max
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Only problem is that cell phones have become so utterly complex (hosting several processors and a plethora of software components) that it will never become the trusted device that we once thought it could be... Personal it is though Jaap-Henk On Sat, 09 Jul 2005 18:56:22 -0700 James A. Donald [EMAIL PROTECTED] writes: -- Ian Grigg [EMAIL PROTECTED] In the payments world we've known how to solve all this for some time, since the early 90s to my knowledge. The only question really is, have you got a business model that will pay for it, because any form of token is very expensive, and the form of token that is needed - a trusted device to put the application, display, keypad and net connection on - is even more expensive than the stop-gap two-factor authentication units commonly sold. Such a device sounds like a cell phone. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 5nMEZ3YWGEUKZWzEprv/E7vI+8j9jzBNX8GWiJiO 4nb4BSDrVGLfq42fHktPRSAfFO3N0uGBnezGRNWrS - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Jaap-Henk Hoepman | I've got sunshine in my pockets Dept. of Computer Science | Brought it back to spray the day Radboud University Nijmegen |Gry Rocket (w) www.cs.ru.nl/~jhh | (m) [EMAIL PROTECTED] (t) +31 24 36 52710/53132 | (f) +31 24 3653137 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Actually, Dutch banks already give users the option to recieve one-time pass-codes by SMS to authenticate internet banking transactions (instead of sending a list of those codes on paper by ordinary mail in advance). So it's less unrealistic than you think. Jaap-Henk On Sat, 09 Jul 2005 20:38:38 +0200 Florian Weimer [EMAIL PROTECTED] writes: You send the pass code in an SMS to the user's mobile phone, together with some information on the transaction. (If the SMS delay is a problem, use a computer-generated phone call.) The pass code is then entered by the user to authorize the transaction. This will eventually break down, once PCs and mobile phones are integrated tightly, but in the meantime, it's reasonably secure even if the client PC is compromised. I'm not sure if users will accept it, though. What's worse, the costs for sending the SMS message (or making the phone call) are so significant that it's unrealistic we'll see widespread use of such technologies. (Manually transferring cryptographic tokens which depend on the transaction contents seems to be infeasible, given the number of bits which must be copied.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Jaap-Henk Hoepman | I've got sunshine in my pockets Dept. of Computer Science | Brought it back to spray the day Radboud University Nijmegen |Gry Rocket (w) www.cs.ru.nl/~jhh | (m) [EMAIL PROTECTED] (t) +31 24 36 52710/53132 | (f) +31 24 3653137 -- -- Jaap-Henk Hoepman | I've got sunshine in my pockets Dept. of Computer Science | Brought it back to spray the day Radboud University Nijmegen |Gry Rocket (w) www.cs.ru.nl/~jhh | (m) [EMAIL PROTECTED] (t) +31 24 36 52710/53132 | (f) +31 24 3653137 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[Clips] Bellovin, et al., in WSJ: Where the Dangers Are
--- begin forwarded text Delivered-To: [EMAIL PROTECTED] Date: Sun, 17 Jul 2005 21:14:39 -0400 To: Philodox Clips List [EMAIL PROTECTED] From: R.A. Hettinga [EMAIL PROTECTED] Subject: [Clips] Bellovin, et al., in WSJ: Where the Dangers Are Reply-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] http://online.wsj.com/article_print/0,,SB112128442038984802,00.html The Wall Street Journal July 18, 2005 THE JOURNAL REPORT: TECHNOLOGY Information Security Where the Dangers Are By DAVID BANK and RIVA RICHMOND Staff Reporters of THE WALL STREET JOURNAL July 18, 2005 In the world of cybercrime, the bad guys are getting smarter -- and more ambitious. In recent months, hackers have carried out a flurry of increasingly sophisticated attacks, highlighting the vulnerability of key computer networks around the world. Criminals penetrated the database of CardSystems Solutions Inc., nabbing up to 200,000 Visa, MasterCard, American Express and Discover card numbers and potentially exposing tens of millions more. Leading high-tech companies in Israel allegedly planted surveillance software on the computers of their business rivals. British security officials warned of a computer attack aimed at stealing sensitive information from banks, insurers and other parts of that country's critical infrastructure.1 THE JOURNAL REPORT?See the complete Technology report2. ON GUARD What new threats do cyber criminals pose? How can computer security be improved? Listen to WSJ reporter David Bank's interview3 with Steven Bellovin, professor of computer science at Columbia University and a longtime researcher at ATT Labs. JOIN THE DISCUSSION Cybersecurity experts discuss how to keep personal data and information safe in the tech world. Readers can join the discussion4 or submit questions. Security experts fear things will only get worse. As technology gets more complex, more vulnerabilities are springing up in computer networks -- and more criminals, terrorists and mischief makers are rushing to exploit them. What people can do on computer networks and what they can find on them has increased tenfold from a few years ago, says Bill Hancock, chief security officer of Savvis Inc., a major Internet-service provider. Infiltrating those machines and using them for evil intent is easier than ever, he says. Some of the threats are well known; home-computer users for years have battled viruses and spam and more recently have been barraged with spyware, adware and fraudsters phishing for sensitive information. Less visible is the constant probing of corporate networks by would-be intruders seeking trade secrets or competitive intelligence, and the data breaches caused by disgruntled or dishonest insiders. Meanwhile, government authorities report that hackers are stepping up attempts to attack critical systems such as water, electricity, finance, transportation and communications. Last year, the Department of Homeland Security prepared a worst-case cyberdisaster scenario where criminals broke into financial-services facilities. Twenty million credit cards were canceled, automated teller machines failed nationwide, payroll checks couldn't be delivered, and computer malfunctions caused a weeklong shutdown of pension and mutual-fund companies. Citizens no longer trust any part of the U.S. financial system, the scenario concluded. Here's a look at the threats the security experts worry about the most -- and what businesses and consumers can do to protect themselves. TARGETED ATTACKS The mass mailings of worms and viruses that clogged email in-boxes and corporate networks in recent years have given way to less visible but more dangerous attacks aimed at specific business and government targets. In many cases, these invasions involve a Trojan -- malicious software that hides inside another, innocuous program. Once planted on a victim's computer system, the Trojan can, among other things, steal information at will and send it back to a criminal. Trojans that are customized for a specific target are particularly dangerous, since conventional antivirus programs are designed to spot and block previously identified threats. Because these things are one-off, the virus scanners do not recognize them at all, says Bryan Sartin, director of technology for Ubizen, a unit of Cybertrust Inc. of Herndon, Va. Criminals use a variety of methods to get Trojans onto their targets' systems. Often, they trick employees at a targeted company into installing the software. In the Israeli case, law-enforcement officials discovered that the alleged perpetrators gave victims floppy disks containing seemingly legitimate business proposals. The disks contained Trojans that used key logger software to record what users typed, and then transmitted that data, along with documents and emails, to a computer in London. Hackers also take advantage of security flaws in Web
Re: the limits of crypto and authentication
ref: http://www.garlic.com/~lynn/aadsm20.htm#10 the limits of crypto and authentication http://www.garlic.com/~lynn/aadsm20.htm#15 the limits of crypto and authentication http://www.garlic.com/~lynn/aadsm20.htm#17 the limits of crypto and authentication one of the issues raised in the x9.59 business rule case was whether there are sufficient PANs (account numbers) to be able to temporarily be able to issue two PANs for every account; one PAN useable against account in X9.59 transactions and one PAN useable against account in non-X9.59 (legacy, non-authenticated) transactions. there was some issues raised about having multiple PANs pointing at the same account ... but that is in wide-spread use already as normal business practice. Note that during any transition to secure x9.59 transaction ... the worst case scenario is that there would be two PANs in existance for every account. The issue raised whether the account number space is large enuf to have two PANs for every account (note that if this turns out to be a real issue ... it would also be a much larger problem for one-time-PAN implementations ... where you might have hundreds of PANs mapped to the same account number). The problem for an X9.59 transition is actually somewhat less severe. Part of the current PAN strategy is stacked against re-use of a PAN. However, in the x9.59 transition case, I would claim that PAN re-use is much less of a problem 1) re-use of any PAN for x9.59 use automatically disables the PAN for all non-x9.59 use (if the PAN had some lingering legacy attachment ... that woulc be disabled as soon as it was assigned for x9.59 use) 2) re-use of a previously assigned x9.59 PAN for x9.59 use ... could happen on somewhat accelerated schedule ... since the previous x9.59 PAN use would have been associated with a public key that was no longer active. the lingering issue as dangling business process associated with old transactions that are bound to a specific PAN. re-use of PANs need to after any such dangling business processes have been assured to have expired. the upside is that any transition to x9.59 would then give the consumer some choice and/or control ... strict use of x9.59 transactions would give the consumer some protection against most skimming, havesting and data breach threats and vulnerabilities. such a consumer might then want any non-x9.59 PANs to have very strict use limits (akin to some of the customer specified limits available on pin-debit accounts ... or what is available on dependent cards). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[Clips] Venona Ten Years Later: Lessons for Today
--- begin forwarded text Delivered-To: [EMAIL PROTECTED] Date: Sun, 17 Jul 2005 22:44:19 -0400 To: Philodox Clips List [EMAIL PROTECTED] From: R.A. Hettinga [EMAIL PROTECTED] Subject: [Clips] Venona Ten Years Later: Lessons for Today Reply-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] http://www.hnn.us/articles/12812.html History News Network July 17, 2005 7-18-05: News at Home Venona Ten Years Later: Lessons for Today By Steven T. Usdin Mr. Usdin, senior editor, BioCentury Publications, is the author of forthcoming book Engineering Communism: How Two Americans Spied For Stalin and Founded The Soviet Silicon Valley, Yale University Press). Ten years ago, on July 11, 1995, the U.S. intelligence community held an extraordinary press conference at CIA headquarters to break the seal on one of the most closely held secrets of the Cold War. The world learned that starting in 1946 American cryptologists had cracked Soviet codes and read portions of thousands of messages Soviet intelligence operatives sent each other during World War II. Most of the cables decrypted in a program that came to be known as Venona, one of numerous codenames used to cloak its existence, were sent or received by the Soviet head of foreign intelligence. Just as the ability to read Stalin's spymaster's correspondence dramatically altered the course of the Cold War, public release of the cables a half-century later altered our understanding of the dynamics of the conflict between the USSR and the West. Coupled with revelations from Soviet bloc archives, release of data gathered in the Venona program led to dramatic reassessments of decades of history. The revelations reverberated worldwide as members of the British, Australian and, above all, American communist parties who had protested their innocence were exposed as spies and liars. Two generations of Americans for whom the innocence of Julius Rosenberg and Alger Hiss was an article of faith were compelled to reconsider their mockery of those who had warned about widespread Communist espionage. Venona not only produced lessons about the past -- it also illuminated issues that governments and the public are grappling with today, including the risks and benefits of the disclosure of intelligence, the dangers of bureaucratic tunnel vision, and the ease with which ordinary people will commit crimes to advance Utopian ideologies. Venona was made possible because in 1942--during the darkest days of the war in Russia, when everything, including skilled manpower, was in short supply--Soviet code clerks produced and distributed to agents around the globe thousands of duplicate copies of one-time pads used to encrypt communications. As is clear from the name, the code tables were supposed to be used only once, and if this simple precaution had been heeded, the encryption system would have been impenetrable. But with Germans at the gates of Stalingrad, punctilious adherence to apparently arcane security rules must have seemed an unaffordable luxury. The chances of the shortcut being detected must have seemed vanishingly small. The Venona secrets were disclosed at the July 1995 press conference largely as a result of prodding from the late Senator Daniel Patrick Moynihan, who learned of the program when he headed the Commission on Protecting and Reducing Government Secrecy. The story of how a combination of extraordinary luck and tremendous talent led a small team working at a former girls' boarding school outside Washington, D.C. to detect and exploit the opportunity presented by the replicated one-time pads has been described in several books, notably Harvey Klehr and John Earl Haynes's Venona: Decoding Soviet Espionage in America (Yale University Press, 2000). That first batch of Venona decrypts released a decade ago included cables between Pavel Fitin, the Soviet head of foreign intelligence, and his officers in New York describing the espionage activities of an American engineer codenamed Liberal who worked for the U.S. Army Signal Corps. These cables were among the first that the Army Security Agency (ASA), which was later folded into the National Security Agency, partially decrypted and shared with the FBI. It took the FBI a couple of years to discover that Rosenberg was Liberal, and another four decades for the National Security Agency to share with the American public the documents that removed all doubt that he was a spy. A 1956 internal memo to FBI Director J. Edgar Hoover revealed three major reasons why the Bureau didn't reveal its smoking-gun evidence during the Rosenbergs' 1951 trial. There was a fear that disclosing the existence of the Venona program could help the Russians minimize the damage to its U.S. spy networks. Although Hoover didn't know it at the time, this concern was largely unwarranted because Fitin and his colleagues already knew a great deal about the Venona program. A
Re: ID theft -- so what?
John Kelsey [EMAIL PROTECTED] writes: One nontrivial reason is that many organizations have spent a lot of time and money building up elaborate rules for using PKI, after long negotiations between legal and technical people, many hours of writing and revising, gazillions of dollars in consultants' time, etc. So, anytime you start doing anything involving public key cryptography, all this machinery gets invoked, for bureaucratic reasons. That is, you've now trespassed on PKI turf, and you'll have to comply with this enormous set of rules. I've seen this happen on many occasions, one example being the posting I made to this list a few months ago where an organisation had spent so much money setting up a PKI that they then had to use it (even though it was totally unnecesary for what they were doing) simply because it was there. I know of a couple cases where this led to really irritating results. In one, a friend of mine was using a digital signature to verify some fairly trivial thing, but was told it was against policy to use a digital signature without the whole PKI. Been there, seen that. You're well into layers 8 and 9 whenever anything related to PKI is involved. I think the fact that PKI is so strong at enabling layers 8+9 is its great appeal to the inhabitants of said layers. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Jaap-Henk Hoepman wrote: Actually, Dutch banks already give users the option to recieve one-time pass-codes by SMS to authenticate internet banking transactions (instead of sending a list of those codes on paper by ordinary mail in advance). So it's less unrealistic than you think. there is also the EU bank challenge/response scenario (requires two-way communication protocol chatter). the customer initiates a transaction ... on the internet or even over (voice) phone. the bank responds with a challenge which is entered into a calculator sized device and the display comes back with the response. the response then is either typed or the keyboard (or the phone keypad). basically it is a relatively dumb pin-pad sleave that a chipcard slips into ... some old post visiting the company that makes the devices: http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ID theft -- so what?
James A. Donald [EMAIL PROTECTED] writes: The PKI that was designed to serve no very useful function other than make everyone in the world pay $100 a year to Verisign is dead. Yet the technology is potent, and the problems of identity and authenticity are severe. We shall, bye and bye, see reliance on public keys. Other things just don't work. What makes you so sure of that? When I looked at this (Plug-and-play PKI: A PKI your Mother can Use, available from my home page), I found that by the time you'd hidden enough of the PKI complexity to make it user-friendly, you had something that was indistinguishable from a username-and-password interface. Conversely, as soon as you start surfacing any of the PKI arcana, it becomes unusable by the majority of users. Currently the best way that I know of securing an SSL link is through the use of TLS-PSK, which provides mutual authentication of client and server as part of the TLS handshake without requiring any public-key technology at all. This also happens to be the most usable security technology around - even your mother can use it, and since the TLS handshake will fail in a very obvious manner if she connects to a spoofed site, there's no need to rely on users mastering PKI/PKC arcana for the security to work. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
