December 2003 - cypherpunks-legacy

SmartGate
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

This looks like they're using Diffie-Hellman. Does anyone know anything further? -Allen --------------------------- > Reuters New Media _ Tuesday December 12 6:33 AM EST _ V-One Unveils Internet Security Technology ROCKVILLE, Md. (Reuter) - V-One Corp. says it has introduced security technology called SmartGate that enables companies to build a secure system to conduct transactions on the Internet computer network. SmartGate is transaction-based software that uses encryption to ensure protection over an open network, the privately held company said Monday. Encryption scrambles the data and in the SmartGate system, a key to decode the data is generated that is unique to a specific transaction session. V-One, which stands for Virtual Open Network Environment, said SmartGate is available now directly from the Rockville, Md.-based company. It said SmartGate can be purchased in either a hardware-software or software-only form. The SmartGate server retails for $9,995 and the software-only version is $4,995. A server is computer that manages the flow of data in a network. SmartGate licenses are priced at $79, with reductions offered for volume purchases.

1 0

Re: Blinding against Kocher's timing attacks
by Hal 17 Dec '03

17 Dec '03

From: ljo(a)ausys.se (Johansson Lars) > Does anyone know whether David Chaum's patent on > blind digital signatures extends to this application? I don't think it would. Chaum's blinding protocol has one major difference: the blinding factor is applied by a different person than the one doing the signing. The purpose of the blinding is different, too; in Chaum's case the idea is to end up with a signature which is unknown to the signer, while with Kocher's "defensive blinding" the signature (or decryption) is an ordinary RSA one, and the blinding is just done internally by the signer to randomize the timing. (I gather BTW that the idea of the blinding is for the server to have pre-chosen a random r and pre-calculated r^d mod n, and then when he is given c to decrypt he first does c*r mod n and then decrypts this, then takes the result and divides by r^d.) It's conceivable that Kocher's blinding would be a patentable technique in itself, and not impossible that he has already applied for a patent before publishing. Probably he would have said so if that were his intention, though. Hal "Blind defensively - watch out for the other guy..."

1 0

Re: NT Password Security Update. Registry values changed!
by Peter Trei 17 Dec '03

17 Dec '03

> Ted Cabeen wrote: > > > Well, I did some more research into the NT password security issue and I > > discovered that I can get access to the Security section of the registry > How did you do that? The SECURITY section is always greyed out and the > operating system will not allow you to change the permissions on it. > If you did indeed gain access to that area then you've probably found a > flaw in the tamperproof capabilities of NT. > - Andy Andy, do you have Administrator privs on your NT system? I too seem to have full access to all registry entries, including all under Security. M$ may have some hidden areas in the registry (security by obscurity), but I can't see anything that says 'sorry, you can't look here'. Speaking for myself. Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

2 1

Re: e-Cash: CAFE vs. Mondex
by Matthias Schunter 17 Dec '03

17 Dec '03

At 9:46 Uhr 13.12.1995, Adam Shostack wrote: >Matthias Schunter wrote: > >| The CAFE system is a cheque based system. This means that the >| customer receives an electronic chequebook, where each cheque is >| (blindly) signed by the bank. >| During each payment the customer has to use one of these signed cheques. > >| privacy-protecting >| The privacy of the user is protected. > > How do checks protect the privacy of the user? The bank >knows who is spending how much with whom for each check. No. The cheques are certified blindly. I.e., the bank does not see them during signing/withdrawal and therefore doe not re-recognize them. However, the bank does know how much money each participant receives or spends, but not who's paying whom. m % Matthias <Schunter(a)acm.org> Uni Hildesheim +49(5121)883-788 fax-732

1 0

Re: Timing Cryptanalysis Attack
by Mark Twain Ecash Support 17 Dec '03

17 Dec '03

At 09:39 AM 12/13/95 -0500, you wrote: >Armadillo Remailer wrote: > >| >My gut & scribble-on-the-back-of-a-napkin feeling about this class of >| >attack is that it could be a problem for smartcards (almost certainly) >| >| Is it a problem to create smartcards that do their calculations in >| fixed time? I'd guess it should be easier than on multi-purpose >| hardware. > > Not if the fixed time is in weeks. > > If you read the Crypto proceedings, you'll find a number of >papers on using an (untrusted) CPU, such as that in a cash machine, to >aid a smartcard. This is because the CPUs in smartcards are very >slow. DigiCash has been aware of the timing problem for years. Especially as it relates to smartcards, for which you can get timings down to the clock cycle. Cosequently, both DigiCash's smartcards and DigiCash's Ecash use fixed timings. --Lucky at work --Mark Twain Bank Ecash Support Ecash. The secure Internet payment system that protects your privacy. <http://www.marktwain.com/ecash.html>

1 0

Re: Timing Cryptanalysis Attack
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 8:30 12/13/95 -0500, Josh M. Osborne wrote: >In message <199512120056.QAA16055(a)mage.qualcomm.com>, Peter Monta writes: >>> Of course, this works against a remote adversary, but not against one >>> on the same machine who can look at actual CPU consumption (which doesn't >>> increase when the target is blocked). >> >>Maybe this is a good reason to spinwait, rather than sleep, until >>the timer expires. It would be pretty subtle to distinguish that >>from "real" computation. > >Across a net it should be hard. On the same CPU it may be easy. Some >CPUs with hardware branch prediction keep track of how many branches were >correctly and incorrectly predected. These registers are not allways >protected, and not allways "made virtual" by the OS. Of course you can spend the time doing exponentiation of random (pseudorandom would probably do) numbers, and when the timer pops, longjump out to return your answer. ----------------------------------------------------------------- Bill Frantz Periwinkle -- Computer Consulting (408)356-8506 16345 Englewood Ave. frantz(a)netcom.com Los Gatos, CA 95032, USA

1 0

OSF security announcement
by Bob Bruen, MIT Lab for Nuclear Science 17 Dec '03

17 Dec '03

The following is part of an OSF announcement. Most of the marketing hype has been deleted, but I thought the security part would be of interest. Bob ------------------------------------------------------------------ CAMBRIDGE, MA, December 12, 1995 -- The Open Software Foundation (OSF) today announced the DCE-Web Advanced Technology Offering (ATO). The goal of this software project is to provide all of the essential capabilities of the distributed computing environment (encryption, ^^^^^^^^^ --snip--- * Secure Local Proxy - provides secure DCE-Web access using standard off-the-shelf browsers. It is possible to access DCE-Web using any browser without any modification. The Secure Local Proxy functions as protocol switch, forwarding proxy requests either as standard http or using the secure DCE-Web protocol. * Secure Gateway - integrates the DCE-Web with other secure Web protocols. The Gateway provides secure access to the Multi-protocol Server, providing DCE authentication based on public key identities. The gateway is designed to allow plug-in access for multiple public key Web protocols. --snip-- For more information on this ATO please refer to the project home page at http://www.osf.org/www/dceweb/. --snip--- CONTACT: Jane Smeloff Open Software Foundation (617) 621-8997 Email: jane(a)osf.org

1 0

Re: Usability of Cryptography (was Re: More FUD from First Virtual)
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: IN%"jamesd(a)echeque.com" "James A. Donald" 13-DEC-1995 03:44:41.99 >If we stick to a lesser goal -- constancy of identity -- this is not so hard. In general it is impossible to prove that Bryce is the "real" Bryce, but it is trivial to prove that Bryce is the same Bryce who has a certain Web page, and the same Bryce who posted a certain article in archives. ----------------- I have been considering all the pieces of information that ought to be automatically linkable to a particular public key. They include: 1. Email address(es) from which mail signed with it is customarily received, to save on lookup time. 2. Web pages put up by this person. 3. Web pages/ftp files/etcetera authored by this person (i.e., the hks archives of cypherpunks). 4. Phone number if using a crypto-capable phone with a key-download capacity from a computer. 5. A declared name or alias. 6. In my files, whatever name I want to give the person. Ultimately, if I receive something signed by somebody, I would want to have hypertext links from that file to all of these- to remind me of whom I'm talking to and his/her/its/their past behavior. -Allen

1 0

Re[2]: e-Cash: CAFE vs. Mondex
by David Klur 17 Dec '03

17 Dec '03

>Matthias Schunter Said [snip] >The CAFE system is a cheque based system. This means that the >customer receives an electronic chequebook, where each cheque is >(blindly) signed by the bank. >During each payment the customer has >to use one of these signed cheques. [snip] If the CAFE card contains cheques (which are not digital cash, and therefore must be tied back to a customer's checking account), how can the bank blindly sign them? The merchant will have to deposit the cheque in order to transfer the money out of the customer's account and into the merchant's account. I don't see how the bank can not know the identity of the customer. This is why digital cash can be anonymous - because once the bank (blindly) signs the cash tokens, these tokens ARE money. They are not pointers (in the case of cheques) to customers' bank accounts. However, if Alice (the customer) contacts her bank and requests a cheque be made out to Bob (the vendor) for, say, $12.50 then the bank can withdraw $12.50 from Alice's account and blindly sign a cheque for $12.50 payable only to Bob. Then the bank would not know Alice's identity. I don't think this is how CAFE works, since CAFE is designed as an off-line smart card system. Therefore, Alice cannot requests bank cheques from her bank made payable to Bob when she walks into Bob's store. Maybe your definition of a cheque is different than mine? ______________________________ Reply Separator _________________________________

1 0

Re: Spotty c'punks service due to network outages
by Alan Olsen 17 Dec '03

17 Dec '03

At 02:35 PM 12/12/95 -0800, you wrote: >Our network service is going up and down, probably due to the storms >in San Francisco. If you see delays, that's the reason why. As far >as I know, NSA has not figured out how to control the weather, so it's >not their fault :-). This is not just in San Francisco... Portland, OR has been having some pretty bad problems with power outages. (My ISP was offline all last night.) I expect that Seattle will be having similar problems due to the storm front that just went through. As for the NSA controlling the Weather Orginization... That only counts as a successfull attack if they have the Evil Geniuses for a Better Tommorrow assisting in the attack. (And they are controlled by at least one computer group.) Sorry... Been catching up on my mail from the Illuminati mailing list. | Remember: Life is not always champagne. Sometimes it is REAL pain. | |"It's only half a keyserver. I had to split the | Disclaimer: | |other half with the government man." - R. Rococo | Ignore the man | |`finger -l alano(a)teleport.com` for PGP 2.6.2 key | behind the keyboard.| | http://www.teleport.com/~alano/ | alano(a)teleport.com |

1 0