Re: RPOW - Reusable Proofs of Work
Bear writes: I'm wondering how applicable RPOW is. Generally speaking, all the practical applications I can think of for a proof-of-work are defeated if proofs-of-work are storable, transferable, or reusable. Once they're storable, tranferable, and reusable, aren't we restricted to applications already nailed down by digital cash schemes? Well, there are no digital cash implementations that I am aware of. I think of RPOWs as a sort of play money that might be usable in some applications that would otherwise use digital cash. I have some code to play online games with cryptographic protection, cards and dice, and I am planning to modify it to let people make bets with RPOWs as the betting chips. Another way to think of RPOWs is as an implementation of Nick Szabo's concept of bit gold. These are made of bits but have the rarity and verifiable costliness of a commodity like gold. Of course they lack gold's appeal and attractiveness. Perhaps they could be better thought of as bit copper. Why doesn't this scheme give rise to a POW server that just sits there, generating proofs-of-work in advance of need and dispensing them at request? Or even to a company that sells POW's to people who can't be bothered to run their own server? And doesn't such a device or service defeat the use of POWs for real-time load balancing, traffic control, etc? It's possible that these things could happen, but that's not necessarily bad. After all, if people ever got to where they would buy and sell RPOWs for money, they could serve in place of ecash. The main question is whether there will be any use for them so compelling that people would buy them. Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[Publicity-list] DIMACS Workshop on Mobile and Wireless Security
* DIMACS Workshop on Mobile and Wireless Security November 3 - 4, 2004 DIMACS Center, Rutgers University, Piscataway, NJ Organizers: Bill Arbaugh, University of Maryland, [EMAIL PROTECTED] Presented under the auspices of the Special Focus on Communication Security and Information Privacy. CALL FOR PAPERS DEADLINE: September 1, 2004 The rapid growth of both voice and data wireless communications has resulted in several serious security problems in both the voice and data spaces. Unfortunately, many of the early security mistakes made with wireless voice communications were repeated with data communications, i.e. the use of flawed authentication and confidentiality algorithms. For example, the standards committee for 802.11 left many of the difficult security issues such as key management and a robust authentication mechanism as open problems. This has led many organizations to use either a permanent fixed cryptographic variable or no encryption with their wireless networks. Since wireless networks provide an adversary a network access point that is beyond the physical security controls of the organization, security can be a problem. Similarly, attacks against WEP, the link-layer security protocol for 802.11 networks can exploit design failures to successfully attack such networks. This workshop will focus on addressing the many outstanding issues that remain in wireless cellular and WLAN networking such as (but not limited to): Management and monitoring; ad-hoc trust establishment; secure roaming between overlay networks; availability and denial of service mitigation; and network and link layer security protocols. We will seek to extend work on ad hoc networking from a non-adversarial setting, assuming a trusted environment, to a more realistic setting in which an adversary may attempt to disrupt communication. We will investigate a variety of approaches to securing ad hoc networks, in particular ways to take advantage of their inherent redundancy (multiple routes between nodes), replication, and new cryptographic schemes such as threshold cryptography. ** Call for Participation: Advances in wireless technology as well as several other areas are changing the way the world does business and as a result computing is becoming more mobile, and users are demanding continuous access to the Internet. At the same time, the number of devices with embedded networking technology is growing exponentially--from boxes with RFID tags to Wi-Fi capable refrigerators since they destroy the notion of a static defensive perimeter. Furthermore, these trends make the ease of use and management of wireless based networks more important since naive consumers in the future will be establishing and using wireless networks on a scale significantly larger than today. This workshop will focus on identifying the current and future problems in wireless security and privacy and discuss possible solutions. The three day workshop will be organized around a series of talks on subjects related to mobility, wireless, and security and privacy technologies. There will be a mix between invited talks and talks selected from extended abstracts with plenty of discussion time between talks. Authors are encouraged to submit an extended abstract on any topic related to wireless and mobile security. Example topics of interest are Interworking security, mesh network security, sensor network security, the privacy of RFID networks, and the security of community networks. These topics are examples only and authors are encouraged to submit extended abstracts on other topics related to the workshop as long as the abstract is of a technical and research nature. Authors are also encouraged to submit early work, and new or outlandish ideas as the primary goal of the workshop is to allow researchers from the networking and security communities to meet in a workshop environment where ideas can be exchanged and discussed in an inter-disciplinary environment. Authors should submit a two page extended abstract in a font no less than 11pt with reasonable margins by midnight (Eastern time) September 1, 2004. Submission instructions will be posted at http://www.missl.cs.umd.edu/dimacs-workshop. Workshop Program: The following is a list of invited speakers: * Bernard Aboba, Microsoft * Nancy Cam-Winget, Cisco * David Johnston, Intel * James Kempf, DoCoMo USA Labs * Insun Lee, Samsung Electronics * Jari Malinen, Nokia * Jesse Walker, Intel ** Registration: Pre-registration deadline: October 27, 2004 Please see website for registration information.
Re: HMAC?
More on the question of HMAC. As mentioned before, the potential attack
would be to find a collision on the inner hash, even without knowing the
key. Since the key is exactly one hash block in length, the effect is
identical to finding a hash collision without knowing the IV.
Discussing this issue with Niels Ferguson, he pointed out that it
might turn out that the new attacks do provide some slight advantage for
guessing a hash collision even without knowing the IV values. There might
be some differential, and conceivably even some choice of inputs, which
would have an enhanced collision probability. If that were greater than
the one in 2^64 chance of a collision one would ordinarily expect with,
say, MD5, then technically that would be called a break of HMAC-MD5,
even if it were not possible to exploit it in practice.
Another point that was mentioned in the presentation on the new MD4
collisions was that they were so easy to find that the work factor was in
the range from 4 to 64. It's not entirely clear what that means, but the
claim was that the work was so simple that it could be completed by hand.
I thought it was conceivable that this meant that some substantial
fraction of random inputs to MD4 would collide when using the differential
described in the eprint posting, so I tested that. I wrote some code
to choose a random 512 bit block and then hash both it and a block
with the published differentials using MD4, and check for a collision.
I let it run for 1.7 billion tries without finding any. The code is
below, but note that it will only run on a little-endian machine since
their differentials are for 32-bit blocks in that form.
So at least it's not just a matter of finding the right differential.
You've got to be somewhat smart in choosing the data values, which would
make it harder to attack HMAC since you presumably would not be able to
choose the data without knowing the IV. It may still be that you could
do something with HMAC built on one of the broken ciphers, but we will
have to wait for a fuller description of the technique.
Hal Finney
===
/* Experiment with random MD4 values to see if the Wang differentials
* work just getting lucky.
*/
#include stdio.h
#include string.h
#include openssl/rand.h
#include openssl/md4.h
typedef unsigned char uchar;
unsigned wang[16] = {
0x4d7a9c83, 0x56cb927a, 0xb9d5a578, 0x57a7a5ee, 0xde748a3c, 0xdcc366b3,
0xb683a020, 0x3b2a5d9f,
0xc69d71b3, 0xf9e99198, 0xd79f805e, 0xa63bb2e8, 0x45dd8e31, 0x97e31fe5,
0x2794bf08, 0xb9e8c3e9
};
unsigned buf1[16];
unsigned buf2[16];
uchar md1[16];
uchar md2[16];
void
memdump (unsigned char *buf, int buflen)
{
int i;
for (i=0; ibuflen; i++)
printf (%02x%s, buf[i], ((i+1)%16)==0?\n: );
if (buflen%16)
printf (\n);
}
main ()
{
int i;
int d1, d2, d12;
d1 = 1UL31;
d2 = (1UL31) - (128);
d12 = -(116);
/* Try an actual Wang collision the first time through for testing */
memcpy (buf1, wang, sizeof(buf1));
for (i=0; ; i++)
{
memcpy (buf2, buf1, sizeof(buf1));
buf2[1] += d1;
buf2[2] += d2;
buf2[12] += d12;
MD4 ((unsigned char *)buf1, sizeof(buf1), md1);
MD4 ((unsigned char *)buf2, sizeof(buf2), md2);
if (memcmp (md1, md2, sizeof(md1)) == 0)
{
printf (Collision on iteration %d\n, i);
memdump ((unsigned char *)buf1, sizeof(buf1));
printf (\n);
memdump ((unsigned char *)buf2, sizeof(buf2));
if (i 0)
exit (0);
}
if (i % 10 == 0)
{
printf (Iteration %d\n, i);
}
RAND_bytes ((unsigned char *)buf1, sizeof(buf1));
}
}
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RPOW - Reusable Proofs of Work
I'm wondering how applicable RPOW is. Generally speaking, all the practical applications I can think of for a proof-of-work are defeated if proofs-of-work are storable, transferable, or reusable. I have some code to play online games with cryptographic protection, cards and dice, and I am planning to modify it to let people make bets with RPOWs as the betting chips. If you think of POW as a possible SPAM mitigation, how does the first receiving MTA assure the next MTA in line that a message was paid for? Certainly the mail relay doesn't want to do new work, but the second MTA doesn't know that the first isn't a spambot. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
