November 1992 - cypherpunks-legacy

Re: Electronic Banking
by Richard Childers 28 Nov '92

28 Nov '92

"Using the net, the 'banker' could easily be 'offshore' and not subject to US law in these matters." Feds busted some folks doing just this with modems in Puerto Rico, I think it was, within the past year ... heard it on NPR, maybe it was BBC or CBC ... -- richard ===== -- richard childers rchilder(a)us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration Klein flask for rent. Inquire within.

1 0

re: Re: How far is to far?
by Tom.Jennings＠f111.n125.z1.FIDONET.ORG 28 Nov '92

28 Nov '92

U> From: karn(a)qualcomm.com (Phil Karn) U> I must concur with George Gleason's remarks about U> "sneaking around in the shadows of legality". I find U> myself getting a little uncomfortable with some of the U> more anarchistic ideas expounded in this and similar U> groups. I agree, even though I'm interested in uses of encryption other than privacy, implementation of privacy systems is a baseline to a lot of it, and the other stuff drags us off topic... --- ReadMail * Origin: tomj(a)fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET - Tom.Jennings(a)f111.n125.z1.FIDONET.ORG

2 1

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

28 Nov '92

>The way I envision it, the host must NOT have the ability to turn it on >or off or do any of the other things you mentioned. The assumption is >that you DON't trust the host. If you don't trust the host, then why are you running your plaintext through it? As I said earlier, my decision whether to trust a particular machine depends heavily on how much I would lose if that trust were abrogated. I might be willing to take the chance that this particular borrowed or public PC has been hacked if the worst that can happen is that the only slightly sensitive plaintext I'm working on at the moment is compromised. Heck, I might even be signing or decrypting totally public information, just to help raise the amount of encrypted traffic on the net. In this case I might not care at all if my plaintext is secretly recorded or sent somewhere. But I would probably NOT be willing to trust the same PC with my secret key, because it would compromise EVERYTHING I have ever protected (or will protect) with that secret key. Including THE most sensitive stuff I might have, the plaintext to which I might entrust only to a RAM disk on my own home PC. Do you understand the distinction here? >So if the host does not even need to know the dongle exists, it is >automatically independent of what type of computer, operating system, >communications program or terminal you are using. I seriously doubt this will be practical, even with constant interaction with the dongle's keyboard. Most palmtop keyboards are a real pain to use, so I would definitely prefer to limit my use of it to truly sensitive things, like typing in my pass phrase to decrypt my RSA secret key, or perhaps hitting a key to re-enable the device after every N secret key operation requests from the host, or to restart a timer that would otherwise exit the program and clear RAM after a timeout in the event the device is lost or stolen. >Again, you are trusting the host. What if the decryption program on >the host has been modified to quietly write the plaintext to a hidden >file. As I said earlier, your "fully-functional dongle" fails to prevent this attack. If it sits on a serial port between your possibly hacked PC and the outside world, then it clearly must pass decrypted plaintext to the PC where it could still be quietly written to disk. >Once the host decrypts the file (at a high speed, as you say), you want >to view the file, right? That means the plaintext is transmitted from >the host to you. Anywhere in the link (which could be a simple RS-232 >connection, or a chain of network links, modem connections, etc., >someone may be watching. With my design, the decryption takes place at >the very last step, just before showing up on your screen. Eh? The model I have is a local PC, possibly hacked, with a serial port connected to my personal dongle sitting right beside it. Obviously it would not do to have an insecure link between the PC and the dongle (unless you had encryption on that link, as I suggested in the case of using a remote machine in place of the dongle.) It should be fairly hard to inject your own traffic on my 1-foot RS-232 link, especially if I provide my own cable. >I have thought of that too. I would need one with two serial ports >though. If you know of a good, cheap (can something have these two >properties simultaneously? :-) notebook computer with (option of?) two >serial ports, please let me know. The "basic dongle" would only need one RS-232 port, and it would not have to be fast. This is a definite advantage. >That is just one of the reasons. The others are convenience, lack of >trust in the host or the network, use of a terminal (which can't run any ^^^^^^^^^^^^^^^^^ This is the one valid reason I can see for your approach. But dumb terminals are getting pretty rare these days, at least in the places I hang out. Phil

2 1

Re: Random numbers
by George A. Gleason 28 Nov '92

28 Nov '92

Vanguard's posting about a friend of his in the Air Force telling him some things about Air Force crypto devices may be of some theoretical interest, but posting it here really gets me majorly uncomfortable. Current military crypto practices are probably very highly guarded secrets. Posting that kind of thing, even in a general way, could be very dangerous; if not to national security then at least to ours. I'd like to ask we have a general agreement to not post things which may be classified. No point giving the govt a good excuse to stop our R&D projects cold. -gg

1 0

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