- cypherpunks-legacy - lists.cpunks.org

Re: Reusable hashcash for spam prevention
by Fearghas McKay 18 May '04

18 May '04

This was posted on the ASRG list - the IRTF Anti Spam Research Group list, which at first reading indicates that the future for Hashcash/Camram may be limited. Eric Johansson the camram developer has some different numbers which he has just run that I will dig out and forward. f --- begin forwarded text

1 0

Re: Reusable hashcash for spam prevention
by Fearghas McKay 18 May '04

18 May '04

This was posted on the ASRG list - the IRTF Anti Spam Research Group list, which at first reading indicates that the future for Hashcash/Camram may be limited. Eric Johansson the camram developer has some different numbers which he has just run that I will dig out and forward. f --- begin forwarded text

1 0

Re: Reusable hashcash for spam prevention
by R. A. Hettinga 18 May '04

18 May '04

--- begin forwarded text

1 0

Re: Reusable hashcash for spam prevention
by R. A. Hettinga 18 May '04

18 May '04

--- begin forwarded text

1 0

Re: Diffie-Hellman question
by Anonymous 18 May '04

18 May '04

Thomas Shaddack writes: > I have a standard implementation of OpenSSL, with Diffie-Hellman prime in > the SSL certificate. The DH cipher suite is enabled. > > Is it safe to keep one prime there forever, or should I rather > periodically regenerate it? Why? If yes, what's some sane period to do so: > day, week, month? > > If the adversary has a log of a passively intercepted DHE-RSA-AES256-SHA > secured SSL communication, presuming the ephemeral key was correctly > generated and disposed of after the transaction, will the eventual > physical retrieval of the DH prime (and the rest of the certificate) allow > him to decode the captured log? The DH prime is not secret, and will not in general allow an adversary to decode the message. Only the private parts of the ephemeral DH keys used by the two sides are secret, and they are destroyed after use. The only theoretical concern is that if the DH prime were small enough, an adversary at some time in the future might be able to break the DH key exchange by calculating discrete logs mod the prime. To within a few orders of magnitude, this is thought to be equally as difficult as breaking an RSA modulus of the same size. If your prime is 2000 bits, then that should be safe for the foreseeable future, unless quantum computers turn out to be practical for breaking moduli of this size. In the unlikely event that it becomes possible to break the DH exchange by attacking the DH prime in this manner, then all key exchanges that were done using that prime would be broken (assuming they were recorded for later analysis and attack). The main work of the break is directed towards the prime itself. Once that is done, there is little additional work to break a key exchange which used that prime. This is the only reason you might want to think about changing DH primes occasionally, so that if some super technology of the future were able to attack even your 2000 bit prime, at least they'd have to run their program a few times rather than just once. But really, that's not much of a security gain, as you're only increasing the attacker's costs by a relatively small factor. And at this point the attack would have to be viewed as extremely speculative anyway. So there's not much reason to change your prime. This is unlike the case with RSA moduli, where you not only have this very hypothetical risk of a future technology breakthrough to allow factoring, but you also have to face the genuine threat that the private key will be exposed or stolen. Once that happens, all past messages encrypted with the key will be revealed. There are good reasons to change RSA moduli regularly for this reason (of course, most people don't do it anyway, because of our poor key management tools). But with DH primes, that is not a concern, as there is no long-term secret to be lost. All you have to worry about is a discrete log breakthrough, and that's not something to lose any sleep over.

2 1

Reusable hashcash for spam prevention
by Anonymous 18 May '04

18 May '04

Recently someone proposed a system which combined ecash and hashcash for email postage. The effect is to get a form of reusable hashcash. Here is some analysis. There are already proposals and even some working code for hashcash email postage. See http://www.camram.org/. This is intended as an anti-spam measure. The idea is that to send email, the sender has to create a "proof of work" token, something which takes a relatively long time to compute but which can be checked quickly. The simplest proposal is a hash collision, as suggested by Adam Back at http://www.hashcash.org/. Spam filter software could be configured so that email containing a valid hashcash token would be presumptively viewed as non-spam. Most non-spammers have low volumes of outgoing mail and so they can generate the necessary hashcash at mail sending time, introducing only a modest delay. Spammers however rely on being able to send enormous volumes of email practically for free, so having to expend potentially several minutes of CPU time for each outgoing email would make their actions unprofitable. The alternative being proposed here is to let there be a way of exchanging hashcash tokens for ecash-like tokens at one or more trusted servers. These ecash tokens would not actually be "cash" any more than is hashcash, i.e. they would not have a specific monetary value, nor would the ecash servers exchange ecash tokens for cash. Rather, ecash tokens would be exchangeable only for other such tokens, and they could also be "purchased" with hashcash. These ecash tokens would then be used as a sort of postage stamp, instead of the straight hashcash tokens in Camram. There is not a particularly strong need for the ecash tokens to be blinded or unlinkable, since the value of them is so low. The servers just need a way to distinguish good and unspent ecash from bad or spent ecash. However if they are used and reused for email postage, allowing linkable tokens would show who was sending mail to whom, infringing email privacy. Hence it would be desirable for the tokens to be unlinkable, which will be possible after the Chaum patent expires in 2005. This is not a crypto anarchy system which would bring down the government and usher in a cypherpunk utopia. The value of these cash tokens would be small, pennies at best. However it represents an adaptation of ecash technology for a useful purpose and it would potentially introduce a limited form of cash-like tokens into widespread use. This system has pros and cons in terms of spam resistance, versus the straight hashcash approach. The biggest difference is that this system allows for effective reuse of tokens. You receive a token in an incoming email, you exchange it at the server for a new one (validating it in the process), and you use the new one to send out a message. Reuse is not possible with straight hashcash, because if people could reuse them, then people could double-spend them. If hashcash reuse were allowed, a spammer could generate a single hashcash token and put identical copies in all of his outgoing email. In order to prevent reuse, hashcash tokens must include enough information embedded in the hash collision to make them unique for a particular message. Typically this would include the recipient's email address, date/time information, and possibly even a message body hash. Hashcash verification involves checking not only the mathematical validity of the collision, but that these embedded fields are correct, as well. The implication of this requirement is that the hashcash token cannot be generated in advance, but must be created at the time the mail is sent. This reduces the acceptable amount of time required for a typical user to create it. If hashcash could be precomputed overnight, it might be okay to take even an hour to produce a token. But if it has to be done at mail sending time, only a much lower time limit will be acceptable. As a result, the size of hashcash collisions has to be set low enough for end users to generate a token in no more than a few seconds or minutes at most. And this increases the chance that spammers may be able to incorporate economies of scale and generate hashcash fast enough to make spamming still be economical. Some analyses suggest exactly this possibility - see for instance http://www.dtc.umn.edu/weis2004/clayton.pdf. Making hashcash reusable by exchanging it for ecash tokens would fix this problem. Instead of the hashcash including information within it to prevent double use, this would be handled by validating the ecash or hashcash at the server to make sure it had not been used before. Now, this means that the spam filter must make an Internet access to check validity, which was not necessary with straight hashcash. However, most spam filters today make many Internet accesses, to check black lists and other communal resources intended to fight spam. Adding a check to validate an ecash token would not change the basic functionality of the spam filter, or materially slow down its operation. Preventing reuse via this method means that hashcash will no longer have to embed the destination and mail-sending times as it does now. This will allow hashcash to be precomputed, and therefore much larger computation thresholds will be acceptable for widespread use. These larger thresholds will make the spammers' jobs that much harder. Another reason why a larger threshold will work is because people will have other ways of getting ecash tokens besides computing hashcash. The most obvious would be reusing tokens in incoming email. Anyone who gets about as many (non-spam) emails as he sends, which is probably the case for most people, would have little or no need to compute hashcash tokens. Spammers, however, send vastly more email than they receive, hence they would not be able to benefit from this shortcut. Switching from hashcash to ecash allows a single hashcash token to be the foundation for the ecash used to send many pieces of email, sequentially. This is another advantage of ecash: it is far less wasteful of compute resources. Hashcash is thrown away after each use. Ecash is conserved and reused. Eventually we may find that our computer cycles are important and valuable enough that wasting several minutes of computation on every outgoing email is unacceptable. In the long run we need something more like ecash than hashcash for email postage. If this system became widespread, it's likely that there will be another way of getting ecash tokens. You will be able to buy them. I proposed above that the ecash server would not be in the business of buying and selling, only exchange. But that wouldn't stop other people from selling ecash tokens. Initially this might be done on a small scale via eBay and Paypal, just like people sell virtual gold and armor from Everquest. Later companies could spring up which would sell tokens on a larger scale, all major credit cards accepted. The reason for such markets is that some people would have a need for many ecash tokens, and others would have a surplus of such tokens. People with extra tokens would include those who receive a lot of email; students and researchers who have access to unused server farms where they can generate many coins during off hours; and pirates who have broken into end user computers and commandeered them to compute coins, without the owners even knowing it. People who want to buy tokens would include legitimate businesses with opt-in email lists, and spammers. It may appear that this system will degenerate into one where hackers break into systems and generate coins, which are then sold to spammers. We would get the worst situation possible, where computer thieves have even more incentive than they do today to attack systems (since they will be able to make money at it), and spammers are still as much of a problem as ever. However, I don't see this outcome as likely. First, even if such a market appeared, the spammers wouldn't be getting their tokens for free. They'd still have to pay to get them from the computer hackers. Even a modest fee would enormously increase the per-message cost for the spammers, who are often sending tens of thousands of messages at a time. Spam is not going to be made profitable by such a market. And second, once people start to realize that their unused computer cycles are at least slightly valuable, they are more likely to take steps to protect them. Grad students who misuse server farms to generate stamps are going to get in trouble, once the Uni realizes that this is theft of something valuable. End user break-ins will be more noticeable if the system is busy all the time generating stamps, and owners will have more motivation to police their systems and keep them updated if they know they could be losing money. (I also believe that we will have much more secure end-user machines in a year or two with the next generation of software, which will make this even less of an issue.) What we are likely to see is that commercial email advertising will continue, but not in the form of the absurd, scatter-shot spam we see today, with ads for medications carefully misspelled to evade filters. For email advertising to be effective in the future, response rates must rise, which means it will be crafted and targeted. Your spam email will be on subjects that interest you, it will be legible and literate, and won't be such an annoyance. That seems like an acceptable balance between freedom of communication and efficient use of email. If we do see ecash postage being bought and sold for small sums, then it could evolve into a micropayment architecture good for other purposes as well. You're not going to be able to efficiently pay someone thousands of dollars for some illicit activity using two-penny stamps. But maybe you could send a few dozen stamps to a starving musician each time you download one of his songs, and that could make a difference for him if all his fans did that. There are other issues to consider, which are also discussed in the hashcash proposals. Over time the threshold for postage needs to be raised, as Moore's Law makes stamp generation cheaper. And users would have to instruct their spam filters to white-list any email lists they sign up for (a process which should be automated) as mailing list exploders wouldn't generate stamps for each subscriber. The biggest problem, of course, is belling the cat: convincing spam filter makers to include hashcash and/or ecash as a filtering mechanism, and providing options to include it in outgoing email. There is an IRTF (related to the IETF, the technical governing body of the Internet) task force studying anti-spam technology, http://asrg.sp.am/, and maybe someone could propose these ideas there for comment. It might be possible to write plugins based on the Camram work that could be used as a proof of concept. The technical implementation is not the hard part. The real work is in deciding whether this technology would accomplish our goals, and then convincing people that it is worthwhile installing it. Given that the spam problem shows no sign of abating, hopefully it will be possible to make progress on this issue.

1 0

EU seeks quantum cryptography response to Echelon
by R. A. Hettinga 17 May '04

17 May '04

<http://www.nwfusion.com/news/2004/0517euseeks.html> Network World Fusion EU seeks quantum cryptography response to Echelon By Philip Willan IDG News Service, 05/17/04 The European Union is to invest $11 million ($13 million) over the next four years to develop a secure communication system based on quantum cryptography, using physical laws governing the universe on the smallest scale to create and distribute unbreakable encryption keys, project coordinators said Monday. If successful, the project would produce the cryptographer's holy grail -- absolutely unbreakable code -- and thwart the eavesdropping efforts of espionage systems such as Echelon, which intercepts electronic messages on behalf of the intelligence services of the U.S., the U.K., Canada, New Zealand and Australia. "The aim is to produce a communication system that cannot be intercepted by anyone, and that includes Echelon," said Sergio Cova, a professor from the electronics department of Milan Polytechnic and one of the project's coordinators. "We are talking about a system that requires significant technological innovations. We have to prove that it is workable, which is not the case at the moment." Major improvements in geographic range and speed of data transmission will be required before the system becomes a commercial reality, Cova said. "The report of the European Parliament on Echelon recommends using quantum cryptography as a solution to electronic eavesdropping. This is an effort to cope with Echelon," said Christian Monyk, the director of quantum technologies at the Austrian company ARC Seibersdorf Research and overall coordinator of the project. Economic espionage has caused serious harm to European companies in the past, Monyk said. "With this project we will be making an essential contribution to the economic independence of Europe." Quantum cryptography takes advantage of the physical properties of light particles, known as photons, to create and transmit binary messages. The angle of vibration of a photon as it travels through space -- its polarization -- can be used to represent a zero or a one under a system first devised by scientists Charles Bennett and Gilles Brassard in 1984. It has the advantage that any attempt to intercept the photons is liable to interfere with their polarization and can therefore be detected by those operating the system, the project coordinators said. An intercepted key would therefore be discarded and a new one created for use in its place. The new system, known as SECOQC (Secure Communication based on Quantum Cryptography), is intended for use by the secure generation and exchange of encryption keys, rather than for the actual exchange of data, Monyk said. "The encrypted data would then be transmitted by normal methods," he said. Messages encrypted using quantum mechanics can currently be transmitted over optical fibers for tens of kilometers. The European project intends to extend that range by combining quantum physics with other technologies, Monyk said. "The important thing about this project is that it is not based solely on quantum cryptography but on a combination with all the other components that are necessary to achieve an economic application," he said. "We are taking a really broad approach to quantum cryptography, which other countries haven't done." Experts in quantum physics, cryptography, software and network development from universities, research institutes and private companies in Austria, Belgium, Britain, Canada, the Czech Republic, Denmark, France, Germany, Italy, Russia, Sweden and Switzerland will be contributing to the project, Monyk said. In 18 months project participants will assess progress on a number of alternative solutions and decide which technologies are the most promising and merit further development, project coordinators said. SECOQC aims to have a workable technology ready in four years, but will probably require three to four years of work beyond that before commercial use, Monyk said. Cova was more cautious: "This is the equivalent of the first flight of the Wright brothers, so it is too early to be talking already about supersonic transatlantic travel." The technological challenges facing the project include the creation of sensors capable of recording the arrival of photons at high speed and photon generators that produce a single photon at a time, Cova said. "If two or three photons are released simultaneously they become vulnerable to interception," he said. Monyk believes there will be a global market of several million users once a workable solution has been developed. A political decision will have to be taken as to who those users will be in order to prevent terrorists and criminals from taking advantage of the completely secure communication network, he said. "In my view it should not be limited to senior government officials and the military, but made available to all users who need really secure communications," Monyk said. Banks, insurance companies and law firms could be potential clients, Monyk said, and a decision will have to be made as to whether and how a key could be made available to law enforcement authorities under exceptional circumstances. "It won't be up to us to decide who uses our results," said Milan Polytechnic's Cova. -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> 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'

1 0

Iraq developments
by Justin 17 May '04

17 May '04

Politics in action... acting president of the Iraqi council is assassinated; coalition finds "small amounts of" sarin released from an exploding shell in Iraq. What's next, we steal all their remaining chemical weapons and bring them and our military home? -- "Not your decision to make." "Yes. But it's the right decision, and I made it for my daughter." - Bill, Beatrix; Kill Bill Vol. 2

1 0

Vulnerability in the WinZip implimentation of AES?
by Dave Howe 17 May '04

17 May '04

http://www.cse.ucsd.edu/users/tkohno/papers/WinZip/ Abstract: WinZip is a popular compression utility for Microsoft Windows computers, the latest version of which is advertised as having "easy-to-use AES encryption to protect your sensitive data." We exhibit several attacks against WinZip's new encryption method, dubbed "AE-2" or "Advanced Encryption, version two." We then discuss secure alternatives. Since at a high level the underlying WinZip encryption method appears secure (the core is exactly Encrypt-then-Authenticate using AES-CTR and HMAC-SHA1), and since one of our attacks was made possible because of the way that WinZip Computing, Inc.~decided to fix a different security problem with its previous encryption method AE-1, our attacks further underscore the subtlety of designing cryptographically secure software.

1 0

US to Collaborate With Interpol On Passport Data
by R. A. Hettinga 17 May '04

17 May '04

<http://allafrica.com/stories/printable/200405170340.html> US to Collaborate With Interpol On Passport Data This Day (Lagos) NEWS May 16, 2004 Posted to the web May 17, 2004 By Nneoma Ukeje-Eloagu Washington DC US Department of State weekend announced a new programme that would contribute substantially to worldwide travel document security and ability to impede the movement of terrorists and other criminals. To accomplish this, America is joining many other countries in providing current information on issued passports reported lost or stolen to the Interpol, lost and stolen document database which is available to border authorities worldwide. A statement from the department explained that under the programme, issued US passports, reported lost or stolen, are immediately invalidated, added to an electronic database, and may not be used for travel. However to protect the original passport holder's privacy, the name and biographical data from the passport would not be given to Interpol. Only the passport number, country of issuance and document type would be provided to Interpol. During the processing of travelers' documents at ports of entry, if a hit occurs against the Interpol database, the hit would be verified with US authorities before action is taken against the bearer of such a passport, the department further explained. Travel document fraud, including the fraudulent application and use of the US passport, represents a serious and growing threat to US national security and it is believe this new program is a significant step in the direction of curbing not only terrorism, but also identity theft and other types of identity fraud US citizens are encouraged to notify the department of the loss or theft of their passport at the earliest possible moment as a measure of preventing misuse of the document and identity theft. It said US citizens could obtain information on how to report a passport lost or stolen by consulting the Department's Bureau of Consular Affairs website http://travel.state.gov while US citizens traveling or residing abroad should contact the nearest Embassy or Consulate abroad to report loss or theft of their passport. -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> 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'

1 0