Bridge
The following is a message I originally posted to coderpunks. The article it refers to can be found at http://www.iacr.org/newsletter/curr/bridge.html The last IACR newsletter mentions that bridge tournaments are having trouble generating random deck shuffles, and suggests that the cryptographic community should in a show of good faith (and, in my opinion, a display of competence,) help them out. The most interesting thing about the threat model mentioned for bridge shuffles is that there is mention of allegations of manipulations to ensure that there are ample opportunities for both north-south and east-west, which is very much not in the spirit of the game. This shoves the threat model into the same category as digital picking of lottery numbers - it is necessary not only that it be random, but that outside parties be able to ensure it's randomness. I believe there is significant published literature on picking of lottery numbers, but I will give my thoughts on it anyway. Essentially what's needed is the creation of a single seed. To keep a single party from manipulating that seed it's necessary for it to be a composite of randomly chosen seeds from several different counterparties, done in such a way that any conspiracy of counterparties which misses even a single one will be incapable of any manipulations. The simplest way of generating a composite key is to have all counterparties which participate in seed creation generate their own random seeds and then xor the results. Doing this verbatim results in a potential attack in which a counterparty manages to see all other counterparties's seeds before sending in their own. That can be fixed by requiring all counterparties to pre-publish the secure hash of their seeds in a highly public and pre-specified manner, such as putting them on a web page. That technique works, but it introduces a potentially herculean task of keeping track of who published what seeds and for what hands of what tournaments. That can be fixed by requiring that all seeds be the result of taking a secure hash of a message describing what they're used for. An example of such a message might be 'this is the seed message from the chicago player's bridge club for use in the tournament held in sydney on august 11, 1999 hand #4, some entropy generated by banging on the keyboard is: snaoteuhsaoedu, some entropy spat out by my computer's random number generator is: .lcrid;qzkidrl, the current time is january 3, 1999 12:45 pm and this generation was done by John Smith.' (my apologies if my fake bridge vernacular sounds hopelessly inaccurate.) I believe that technique makes the clerical task of tracking seeds manageable. The number of times the process needs to be run makes a human-readable format perfectly reasonable, and doing so adds a considerable amount of flexibility for altering the requirements of what be stated in it as processes are modified. In exchange for requiring human intervention, the need for scrupulous tracking of what seed value goes to what hand is done away with. In particular repetition of hands across tournaments is made easily avoidable - a disaster which has actually happened. Happily, all the technology I mention here is freely exportable from the united states. It is interesting to note that the bit of analysis in the IACR newsletter said much about how to use the seed to generate a hand and nothing about the threat model, while I said much about threat model and nothing about how to use the seed to generate a hand. I will say, however, that feeding the seed into a pseudo random number generator which isn't cryptographically secure would be just plain stupid. -Bram (yes I use a dvorak layout)
Re: personal encryption? (fwd)
-- At 04:39 PM 6/22/99 -0400, Dan Geer wrote: > >Do you imply having a machine with PCR's for some unique >string in the authenticator's DNA? I see two problems. >First, twins. Second, it's possible to grow DNA from >fingernail clippings, hair, etc. It would be like >habitually writing your password down on everything you >touched :-) > > 1. quoting Schneier verbatim, "BIOMETRICS ARE NOT SECRETS" >2. for the ordinary Joe, never understimate the lure of > convenience There are a host of cool little computers on a button that can do public key operations. They can fit on a key ring, and some of them on a pinky ring. They can be used to open electronically controlled doors for secure access. The great weakness of these wonderful gadgets is that they cannot tell the user what he is signing, or what he is decoding. For this to be truly secure, the hardware in the computer that talked to the button would have have its ROM code take over the computer display to display to the user what he was signing, or what he was decoding. Trouble is, it would still need to use the same video drivers as everyone else, but it is likely to be kind of hard to deploy a trojan video driver, as most operating systems, for example NT, have special case arrangements for installing video drivers. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG U20SaZ235QUB5lUnY24ItVsiUbFEzExg6PPMj8V+ 489/PK+GY0K4sifcQETcgjkW0sBCGhdVpVz7Tdvyz
Re: personal encryption? (fwd)
Do you imply having a machine with PCR's for some unique string in the authenticator's DNA? I see two problems. First, twins. Second, it's possible to grow DNA from fingernail clippings, hair, etc. It would be like habitually writing your password down on everything you touched :-) 1. quoting Schneier verbatim, "BIOMETRICS ARE NOT SECRETS" 2. for the ordinary Joe, never understimate the lure of convenience --dan
[ANNOUNCE] PureTLS: A free Java TLS implementation
http://www.rtfm.com/puretls/ Claymore Systems, Inc. is pleased to announce the availability of PureTLS 0.9a1. PureTLS is a free pure Java implementation of TLS and SSLv3. This is the initial release of PureTLS, and we consider the code quality to be late Alpha. That is to say, it's undergone some testing, including interoperability testing with OpenSSL, and we think it's a useful product, but there are certainly still bugs. We expect to produce a beta-quality release by the end of July, but to do that we need people to try it and send us bug reports. PureTLS is released under a BSD-style license. Quite simply, we feel that basic network security should be a commodity, and this is our contribution to that end. Ciphers supported are: TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA Client authentication is supported both for DSS and RSA. For details and to download, see: http://www.rtfm.com/puretls/ Please note that this software was developed in the US. It is export controlled. Moreover, RSA is patented in the US until mid-2000. As PureTLS gets its RSA implementation from Cryptix, this isn't an issue for distribution, but if you wish to use RSA inside the US, please see RSA DSI for licensing terms. Please feel free to distribute this message to other appropriate mailing lists. -Ekr [Eric Rescorla [EMAIL PROTECTED]]
CHES Accepted Papers
We are pleased to announce the following papers will appear at the Workshop on Cryptographic Hardware and Embedded Systems. Information about the conference is found at http://ece.wpi.edu/Research/crypt/ches. A. Shamir Factoring large numbers with the TWINKLE device J. H. Silverman. Fast multiplication in finite fields GF(2^n) B. Kaliski and M. Liskov Efficient finite field basis conversion involving dual bases H. Wu, M. A. Hasan, and I. F. Blake. Highly regular architectures for finite field computation using redundant basis H. Wu Low complexity bit-parallel finite field arithmetic using polynomial basis K. Itoh, M. Takenaka, N. Torii, S. Temma, and Y. Kurihara Fast implementation of public-key cryptography P. J. Lee, E. J. Lee, and Y. D. Kim How to implement cost-effective and secure public key cryptosystems J. Lopez and R. Dahab Fast multiplication on elliptic curves over GF(2^m) without precomputation L. Gao, S. Shrivastava, and G. E. Sobelman Elliptic curve scalar multiplier design using FPGAs Y. Han, J. Zhang, and P.-C. Tan Direct computation for elliptic curve cryptosystems J.-S. Coron Resistance against differential power analysis attacks for elliptic curve cryptosystems L. Goubin and J. Patarin DES and differential power analysis P. Fahn and P. Pearson IPA: A new class of power attacks T. S. Messerges, E. A. Dabbish, and R. H. Sloan Power analysis attacks of modular exponentiation in smartcards H. Handschuh, P. Paillier, and J. Stern Probing attacks on tamper-resistant devices V. Bagini and M. Bucci A design of reliable true random number generator for cryptographic applications D. Maher and B. Rance Random number generators founded on signal and information theory W. P. Choi and L. M. Cheng Modelling the crypto-processor from design to synthesis R. R. Taylor and S. C. Goldsteiny A high-performance flexible architecture for cryptography A. F. Tenca and C. K. Koc A scalable architecture for Montgomery multiplication E. Mosanya, C. Teuscher, H. F. Restrepo, P. Galley, and E. Sanchez CryptoBooster: A reconfigurable and modular cryptographic coprocessor I. Hamer and P. Chow DES cracking on the Transmogrifier 2a M. Hartmann, S. Paulus, and T. Takagi NICE - New Ideal Coset Encryption - D. C. Wilcox, L. G. Pierson, P. J. Robertson, and E. L. Witzke A DES ASIC suitable for network encryption at 10 Gbps and beyond E. Hong, J.-H. Chung, and C. H. Lim Hardware design and performance estimation of the 128-bit block cipher cRYPTON T. Horvath Arithmetic design for permutation groups O. Jung and C. Ruland Encryption with statistical self-synchronization in synchronous broadband networks Invited Talks: -- Brian Snow, National Security Agency, USA We Need Assurance Eberhard von Faber, Debis IT Security Services, Germany Security Evaluation Schemes for the Public and Private Market with a Focus on Smart Card Systems Dale Hopkins, Compaq - Atalla, USA Design of Hardware Encryption Systems for e-Commerce Applications Colin D. Walter, Computation Department - UMIST, U.K. An Overview of Montgomery's Multiplication Technique: How to make it Smaller and Faster David Naccache, Gemplus, France Significance Tests and Hardware Leakage --- Workshop on Cryptographic Hardware and Embedded Systems Worcester, Massachusetts, August 12-13, 1999 --- Information:http://ece.wpi.edu/Research/crypt/ches E-Mail: [EMAIL PROTECTED] Program Chairs: Cetin Kaya Koc & Christof Paar [EMAIL PROTECTED] & [EMAIL PROTECTED] ---
Re: personal encryption? (fwd)
Dan Geer <[EMAIL PROTECTED]> writes: >> this does not lead to secret messages. >> >> this leads to the ultimate in biometrics. Do you imply having a machine with PCR's for some unique string in the authenticator's DNA? I see two problems. First, twins. Second, it's possible to grow DNA from fingernail clippings, hair, etc. It would be like habitually writing your password down on everything you touched :-) Marc
CipherClerk
CipherClerk is a Java applet "implementing a collection of historic ciphers. Most ciphers are "paper & pencil" types, e. g. to use them you wouldn't need more than a sheet of paper and something to write." http://members.magnet.at/users/wilhelm.m.plotz/ Udhay -- __ http://www.unimobile.com/ http://pobox.com/~udhay sign up for the Unimobile beta today!
Re: Justice Dept asks Court of Appeals to reconsider ruling in Bernstein case
In message <[EMAIL PROTECTED]>, Declan McCullagh wri tes: > I have a more detailed report on Wired News: > > http://www.wired.com/news/news/politics/story/20333.html > > My favorite part of the brief (I quote it): > > > > > Another argument: That this type of > > regulation is an executive-branch policy > > decision involving "extraordinarily > > sensitive" info that's too secret to > > disclose publicly. Gee -- did they happen to mention that the CRISIS report concluded that the question could be discussed without reference to classified info?
Re: Justice Dept asks Court of Appeals to reconsider ruling in Bernstein case
I have a more detailed report on Wired News: http://www.wired.com/news/news/politics/story/20333.html My favorite part of the brief (I quote it): > > Another argument: That this type of > regulation is an executive-branch policy > decision involving "extraordinarily > sensitive" info that's too secret to > disclose publicly. "Judicial review is > particularly unworkable [since] decisions > always involve an appraisal of the > potential impact of proposed encryption > exports on the government's [signals > intelligence] and cryptoanalysis > capabilities." The brief also talks about how the case affects NSA SIGINT capability. -Declan At 07:26 PM 6-21-99 -0400, Steven M. Bellovin wrote: >According to the AP, the Justice Department has asked the 9th Circuit Court >of Appeals to reconsider its decision in the Bernstein case >(http://www.nytimes.com/aponline/w/AP-Encryption.html). The article didn't >say so, but I assume that they've asked for a rehearing by the full >court, instead of just a three-judge panel. >
RE: Could Open Source Software Help Prevent Sabotage? (fwd)
On Mon, 21 Jun 1999, Michael Cervantes wrote: > Most open source software is distributed in a tar file with just makefiles, > docs, and source. You compile the object directly from the source code that > is provided. However, binary packages are becoming more common as package > management apps like Redhat's RPM become ubiquitous, and it is important > that sys admins recognize the significance of this. RPMs and other modern binary package formats include signatures (PGP in RPM's case). In most cases you can also obtain source packages. In RPM's case a source package consists of a "pristine" source archive, zero or more patches to the the source and a "spec" file which describes the package and build procedure. Having the modification seperate from the original source, and thus the ability to verify the integrity of the original source helps quite a bit. Regards, Damien Miller -- | "Bombay is 250ms from New York in the new world order" - Alan Cox | Damien Miller - http://www.ilogic.com.au/~dmiller | Email: [EMAIL PROTECTED] (home) -or- [EMAIL PROTECTED] (work)
Re: Justice Dept asks Court of Appeals to reconsider ruling in Bernstein case
On Mon, Jun 21, 1999 at 07:26:11PM -0400, Steven M. Bellovin wrote: > According to the AP, the Justice Department has asked the 9th Circuit Court > of Appeals to reconsider its decision in the Bernstein case > (http://www.nytimes.com/aponline/w/AP-Encryption.html). The article didn't > say so, but I assume that they've asked for a rehearing by the full > court, instead of just a three-judge panel. They've asked for both, which is how this sort of thing works. They advance two arguments in their petition - "The EAR's Export Controls on Encryption Source Code Are Not a Facially Unconstitutional Prior Restraint" (arguing that the crypto export controls aren't targeted at expressive activity, and hence not properly subject to a facial challenge on prior restraint grounds) and "The Export Controls on Encryption Source Code are Severable From the Export Controls on other Encryption Products". (arguing that the Supreme Court, in _ACLU v. Reno_ 117 S.Ct. 2329, establishes that it is appropriate for a court to sever part of a statute or regulation where there is a "textual manifestation" of a distinction between constitutional and unconstitutional regulation.) -- Greg Broiles [EMAIL PROTECTED]
