- cypherpunks-legacy - lists.cpunks.org

More comments on dongles
by karn＠qualcomm.com 28 Nov '92

28 Nov '92

George Gleason says "I believe that carrying out the entire crypto operation in the dongle is preferable to having it only do the secret key RSA processing" and argues for this position mainly on the basis of host compatibility issues. I still disagree. Even if all the crypto operations were done in the dongle, it wouldn't be a "turnkey" device that could operate totally automatically. You'd still need a way for your host computer to turn it off and on, to select a public key for encryption or signature verification, to load new public keys, etc. I.e., you'd have to run special driver software on the host anyway. So why not limit the dongle to the specific purpose for which it was designed (protecting your RSA secret key) and do the less sensitive operations where memory and cycles are far more plentiful, i.e., on the host? Limiting the dongle's function to RSA secret key operations also minimizes the dongle's communication requirements. The only data you'd have to send to it in normal operation would be short blocks to be run through your RSA secret key operation, a heavily compute-bound process. If I want to decrypt a file, I'd send the dongle the IDEA (or DES) key that had been encrypted with my public key. Once the dongle responds with the decrypted IDEA key, I can perform the actual IDEA decryption on my host computer with no further dongle interaction. Regardless of the file size, this would go at host CPU and/or disk speed, not the speed of the port that's talking to the dongle. Similarly for signing -- the MD-5 hashing of the file would proceed at near disk speed (since MD-5 is so fast) and only the resulting hash code would have to be passed to the dongle for the RSA secret key step. A palmtop DOS machine like the HP-95 or Atari Portfolio would make a good platform for a prototype dongle. Most have serial ports (standard or optional), and you could just plug them into a spare serial port on a PC (again, speed is not critical). The palmtop's keypad would be used to control the dongle, e.g., by accepting a pass phrase to decrypt the stored copy of your RSA secret key, so you wouldn't have to type it into a possibly compromised PC. And they're small enough to carry around with you, thus making it harder for somebody to hack. The only drawback I can see to all of this is that palmtops are not exactly speed demons, and RSA secret key operations are pretty slow to being with (much slower than the public key operations, which are less sensitive). But secret key operations are the heart of RSA, so you don't have much choice if you want real security. Since it is a sensitive step, RSA key generation could also be done on the palmtop (although it would probably take hours) or it could be done on an external, trusted PC and loaded into the palmtop. If your main reason for using the dongle is to limit the trust you have to place in a borrowed PC (as opposed to protecting against your own home PC being hacked), this may be a reasonable thing to do. Another idea just occurred to me. If you have a trusted machine (e.g. your home PC) available to you over the net, you could use it as a "remote dongle". You'd send it data to be run through the RSA secret key operation and it would return it. Obviously, to be secure the network exchanges would have to be encrypted in both directions, otherwise anybody could either pick up the "remote dongle's" responses or worse, send it data of his own choosing. A simple symmetric cipher (IDEA, DES) would be adequate here since you control both ends of the link. The main drawback of this approach (other than the need for network connectivity) is the physical vulnerability of your unattended home PC. Phil

2 1

Re: Random numbers
by donb＠netcom.com 28 Nov '92

28 Nov '92

> > > > It has lately been discussed different ways to construct pure > > random number generators by means of radiactive decay. I must admit > > that this is a very good way to produce such numbers, but for a > > number of reasons it is impractical to use such a device. (High > > radiation levels are needed too produce a significant amount of data.) > > > The way to make good random numbers is to take about 20 stages of flops > and feedback 2 or three terms. Clock the thing as fast as you can, Say > 50 mhz, and asychronously to your main processor clock. The shift register > needs its own crystal. The selection of feedback points is based on > Linear Congruential Method of Pseudo random numbers generated by most > machines. > > The numbers generated are very, very uniform. > > The way to test random number generators for randomness is to generate > the numbers in pairs and plot them on a scatter plot. This simple > cross check will show up many poor generators. Checking for uniform > density in higher dimensions will uncover even more subtle variations > from uniformity. There is an enormous literature on this topic. Obviously > you can screw it up, but it isnt that hard to get right either. There > is an excellent book just out on simulations that covers this. If > anyone wants the reference, I can dig it up. > > Bottom line is that you don't need anything exotic. But the 8 or simple 16 > bit methods on the small processors are no good. > > Don Bellenger > donb(a)netcom.com > > > > > > --

1 0

Random numbers
by VANGUARD＠gribb.hsr.no 28 Nov '92

28 Nov '92

It has lately been discussed different ways to construct pure random number generators by means of radiactive decay. I must admit that this is a very good way to produce such numbers, but for a number of reasons it is impractical to use such a device. (High radiation levels are needed too produce a significant amount of data.) What I have been thinking of is a way to reduce the amount pure random data needed to produce good random sequences. The way to do this would too have a weak random number generator like: R(n+1)=(17*R(n)+1)mod256, and then inject the pure random into this function giving the result R(n+1)=(17*R(n)+1+PR(t))mod256 or something of the like. Would this constitute a sufficiently secure stream of data for use in one time pads? Has this been thought of before ? THE REST OF THIS MESSAGE CAN BE SAFELY INGNORED: A friend of mine now serving in the air force gave me a report of the cryptographic devices used for communicating on permanent lines. (Twisted pair or something dug down). The machines used till now are huge totaly outdated mostly mechanical monsters. While not transmitting data the machines produce random data to hinder traffic analysys (like how many messages are sent), these data are produced by cookiebox sized thing, and I strongly suspect it to be of a very mechanical nature. Thats how a came up with the idea of a very inexpensive way to produce random data by mechanical means: Use a contaner filled with marbles some made of conducting, and some of non- conducting material. Then mix them in some way or another (this is bound to make a lot of noise) and in the container there should be a few closely placed points of contact that would be able to send a small current through a steel ball if it where to pass over the pair of contacts, and what do we have: Random Data ! (I know this is not very practical at all)

1 0

Re: How far is to far?
by karn＠qualcomm.com 27 Nov '92

27 Nov '92

I must concur with George Gleason's remarks about "sneaking around in the shadows of legality". I find myself getting a little uncomfortable with some of the more anarchistic ideas expounded in this and similar groups. My interest in cryptography is very simple. I'm not interested in overthrowing the government by force. Although I find "digital cash" to be an interesting concept worthy of pursuit at least as an academic exercise, I'm not trying to evade income taxes, establish an underground economy or conceal criminal activity. And although I do believe that drugs, gambling, prostitution and other vices ought to be legalized on both practical and philosphical grounds, I am not particularly interested in using cryptography to protect the lowlifes who inhabit these professions. I am *very* interested, however, in cryptography's enormous potential to protect individual privacy. With widely available strong cryptography, the average individual will finally have the technical means to draw a tight circle around the private aspects of his or her life. The individual need let no one, especially the government, enter without his or her permission. Until now, we have had to depend entirely on the goodwill of government to respect and obey those provisions of the Bill of Rights that deal with privacy. Often this "good will" has been sadly lacking. But now we can finally put some real teeth into the guarantees of the First, Fourth and Fifth Amendments. If you want to plot political strategy for an upcoming election, or if you want to talk to your attorney about some legal action, or even if you just want to discuss your sex life with your spouse or SO, cryptography can guarantee you an unprecedented degree of privacy. Just as good fences make good neighbors, we may well find that in the hands of the people, good cryptography will make for good government. That's why I find cryptography so interesting, and that's how we should sell it to the public. Phil

1 0

More cypher bank
by donb＠netcom.com 27 Nov '92

27 Nov '92

No one else's account would be disclosed except to the owner. Handle, hash, or the full key itself is all the same. The point is that some shortened identifer is needed. This is not a technical matter, the customer can cook up anything he wants, There is no relation to the mechanics of PGP, I don't want to bother scanning in and verifying long strings of codes, and I need some short I.D. so the owner can identify his balance for verification (checking balances). There are obviously plenty of fancy variations on this, and I would be happy to set up whatever any body wants. Maybe the easiest way is to setup mail addresses for each depositor of the form: handle_of_depositor(a)digibank.com. So send signed email to that address, and I will respond with your balance. A couple of other addressees would be used for overall bank status report, and current operating rules. The digital cash account is represented by the escrow balance. If Sam wants me to take his collected funds and turn them into digi-cash, I can sign a voucher that I have segregated X amount of Sam's money into an escrow account pending receipt of the digi-cash voucher and instructions to move the escrow amount elsewhere. This is all that any bank is going to do. Basically, this looks like a very good thing to do. If handled properly and within the banking regulations, it could be a great advance. Does anybody here remember pre-ATM days? Standing in line at the bank to get cash? In 3rd world countries they don't even have checking. This means you have to walk around every month and pay your bills in cash. I haven't been in a bank in years since the ATMs came in. And this is at another, much higher level of abstraction. > > > address; and offer to accept deposits by cash, check, or what have > > you. With the deposit, write on it your PGP handle. Email me your > > public key corresponding to the handle on the deposit. > > A better way would be to mail the public key itself, or a short > hash of it along with your payment. That is all the information that > would be required. A "handle" would be completely optional. > If only the hash value is mailed, then the full key can be e-mailed > or anonymously posted to a newsgroup that you montitor. If the full key > is mailed, you should invest in a scanner and some simple OCR software. > > This way, someone may print out the public key and mail it to you. > > > I will maintain a public list showing handles vs. Amount received, > > in collection, and in escrow.(Set Subject = "BANK" to get the list) > > You should not disclose someone's balance to anyone else, and certainly > no to the public. Someone requesting their balance should send the > request by any communications channel (anonymous mail, newsgroup, anything) > and sign it with the private key corresponding to the public key used > when making the deposit. Then you should encrypt your reply (the account > balance & any other info) using the public key, and send it back through > any channel. > > > Funds will be paid out based on instructions encyphered with your > > private key. > > I would make it: funds will be transferred based on instructions _signed_ > with the private key corresponding to the public key used for deposit. > > P.S. this would be equivalent to digital checking accounts. Do not confuse > this scheme with the much more interesting Digital Cash ideas. > > -- > Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek > this address preferred -->> yanek(a)novavax.nova.edu <<-- this address preferred > Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood > (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 > > --

1 0

...
by daver＠tfs.COM 27 Nov '92

27 Nov '92

please remove me from this list. as interesting and important as i think the discussions are, i cannot keep up with the volume of mail. thanks.

1 0

Welcome message for cypherpunks-announce
by hughes 27 Nov '92

27 Nov '92

We've created a secondary list, cypherpunks-announce(a)toad.com. If you want to keep in touch, but don't want the volume of mail the full list produces, get yourself switched over. And remember not to post such requests to the whole list. Thanks. The welcome message follows. Eric ----------------------------------------------------------------------------- Date: Fri, 27 Nov 92 10:44:31 PST From: hughes(a)toad.com (Eric Hughes) To: cypherpunks-announce Subject: Welcome Welcome to the cypherpunks-announce list. This is a low-volume list for announcements, news, and meeting schedules. It is not a digest. It is moderated by Eric Hughes, also the maintainer of the full list. Each of you has at some point been on the full list and asked to be dropped for mail volume. If you really don't want to be even on the announce list, send mail to cypherpunks-announce-request(a)toad.com and ask to be removed from the announce list. Eric

1 0

Re: ping
by cordones＠IMAGE.CS.NYU.EDU 27 Nov '92

27 Nov '92

Me too. In fact, I am insecure my message ever got through because no one has said anything about it. It was regarding "The NSA backsdown". I was asking how could point me to thse so called "secret" documents that are available at some libraries. Did that get through Boys? Thanks

2 1

List is partially broken
by donb＠netcom.com 27 Nov '92

27 Nov '92

The message below was received in response to a ping sent to this list. However I know that it got some distribution because Yanek answered it. donb(a)netcom.com Forwarded message: > From Mailer-Daemon Fri Nov 27 09:03:27 1992 > Message-Id: <MAILQUEUE-102.921127120540.672(a)newschool.edu> > From: Postmaster(a)newschool.edu > To: donb(a)netcom.com > Subject: Rejected Mail > Date: Fri Nov 27 12:05:03 1992 > > > Unable to deliver message because: > > @ : Insufficient Disk Space > > Returned Text follows > ------------------- > Received: From relay2.UU.NET by newschool.edu > via Charon 3.4 with SMTP id 102.921127120528.384; > 27 Nov 92 12:04:51 +0500 > Received: from toad.com by relay2.UU.NET with SMTP > (5.61/UUNET-internet-primary) id AA03427; Fri, 27 Nov 92 11:56:15 -0500 > Received: from netcom2.netcom.com ([192.100.81.108]) by toad.com id AA01076; Fri, 27 Nov 92 08:55:12 PST > Received: by netcom2.netcom.com (5.65/SMI-4.1/Netcom) > id AA09053; Fri, 27 Nov 92 08:51:00 -0800 > Date: Fri, 27 Nov 92 08:51:00 -0800 > From: donb(a)netcom.com (Don Bellenger) > Message-Id: <9211271651.AA09053(a)netcom2.netcom.com> > To: cypherpunks(a)toad.com > Subject: ping > > This is a test. I am seeing mail rejected due > to mail spool full @ newschool. > > --

2 1

Re: Mac PGP report and Rander progress
by tony＠morgan.demon.co.uk 27 Nov '92

27 Nov '92

In message <9211270003.AA20577(a)napa.TELEBIT.COM> you write: > Has anyone given any thought to generating random numbers by counting > particle emissions from a radioactive source? This might be more > reliably random than using purely electronic means. > I don't think that for any given length of random bit string, you'd be practically happy carrying around a suitable source. Thermal noise, which is what you get from a diode, is just as good a random source as radioactive decay. Tony ------------------+-------------------------------+--------------------------+ | Tony Kidson |`morgan' is an 8MB 486/33 Cat-| Voice +44 81 466 5127 | | Morgan Towers, |Warmer with a 670 MB Hard Disk.| E-Mail | | Morgan Road, |It resides at Morgan Towers in| tony(a)morgan.demon.co.uk | | Bromley, |Beautiful Down Town Bromley. | tny(a)cix.compulink.co.uk | | England BR1 3QE | -=<*>=- | 100024.301(a)compuserve.com| +=================+===============================+==========================+

1 0