- cypherpunks-legacy - lists.cpunks.org

latest procmail and recipes.
by J. Michael Diehl 17 Dec '03

17 Dec '03

Hi all! I just thought I'd post to let you know that I can send any interested parties the latest version of procmail and my pgp recipes for procmail. Send me a message with the subject: send help for more details. Lagers, J. Michael Diehl ;^) |*The 2nd Amendment is there in case the mdiehl(a)triton.unm.edu | Government forgets about the 1st! <RL> Mike.Diehl(a)f29.n301.z1 |*God is a good Physicist, and an even .fidonet.org | better Mathematician. <Me> al945(a)cwns9.ins.cwru.edu|*I'm just looking for the opportunity to (505) 299-2282 (voice) | be Politically Incorrect! <Me> Can we impeach him yet? |*Protected by 18 USC 2511 and 18 USC 2703.

2 1

Re: All our eggs in one basket?
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

> What would happen if your bank suddenly told you that it had no proof that > you really had an account there? > > Wonderer > Theoretically, this problem is prevented by using protocols that incorporate non-repudiation mechanisms. The bank wound not be able to make such a claim. Or, another way of saying it, were the bank to make such a claim, you would be able to prove them wrong. However, proving them wrong while also retaining your anonymity may be a trick. It would depend on the design of the non-repudiation mechanisms. How do you prove to a third party that someone is falsely repudiating a valid contract or transaction without revealing any information about yourself? Conversely, how do you defend yourself against false claims of repudiation without revealing any information about yourself? After all, someone might try to discover your identity by making false claims about you, and forcing you to defend yourself. (Sound familiar?) Jim_Miller(a)suite.com

2 1

ytalk help
by erc＠khijol.yggdrasil.com 17 Dec '03

17 Dec '03

Help! I got ytalk from soda.berkeley.edu and compiled it. Now it complains it can't find the ytalk daemon! There's a ytalkd.c, but it won't compile, and there's no target in the Makefile for ytalkd. Help!!! The documentation is a big lose, and the author doesn't answer his email :( :( -- Ed Carp, N7EKG erc(a)wetware.com 510/659-9560 an38299(a)anon.penet.fi, anon-1157(a)twwells.com If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever"

1 0

Duress Passwords/PINs/Combinations
by baldwin＠LAT.COM 17 Dec '03

17 Dec '03

Having a separate authentication mechanism that is used under duress is a very good idea that some existing systems already employ. I'll pass along the ones I have had contact with. From a systems point of view, it is hard to figure out exactly how the system should respond when it recognizes a duress authentication. There are competing interests as I'll explain after some examples. The safe inside the ATM machines used by BayBanks (Boston Mass) can be opened with two combinations. One combination sends an alarm to the bank via a separate phone line (not the one used to perform the ATM transaction). The alarm phone line is also connected to a conventional panic switch. A fellow I know has a central-office alarm in his home. When the alarm goes off, the office calls his house to ask if it was a false alarm. They ask for a password to verify, and no matter what password you give they say "OK, I'll log it as a false alarm." If you gave the wrong password, they call the police and notify them of a crime in progress with hostages. If no one answers the phone, they send one of their patrol cars. The challenge-response token that Attalla sells (which is a repackaging of someone else's token) supports a fixed or variable duress pin. In the fixed duress pin mode, a special PIN, usually "1111", causes the device to use a fixed different key to compute the response to the challenge. The code that authenticates the response checks for a use of the duress key if the response does not correspond to the value expected for the user's key. The variable duress PIN approach is a feature of the card where the user can set which PIN value causes the card to use the alternate key. From a software point of view, the authentication procedure returns Yes/No/Duress. Note it is possible to have a collision between a duress response and a regular response. The competing interest problem is illustrated by the following possibility: A criminal makes an ATM money-filler open the safe at gun point (the ATM repair people do not know the safe combination). The criminal says that she knows about the duress combination and threatens to shoot the kneecaps off the person if they use the duress combination. The criminal will take the money-filler hostage for a few minutes to guarantee a clean get-away. So what does the money-filler do? To use the duress combination requires faith that the bank will handle the situation in a subtle way and thus avoid major knee surgery. For the bank, why risk loosing any money or loosing the criminal. In fact, why not just refuse to open the safe in the first place? What is the right balance between these interests? How does each party trust that the other will behave as expected? What is the benefit of this approach when the criminals already know about it? It works well against criminals that don't know about it, but is that enough to justify the overhead? These questions are not show stoppers. Individual organizations can and do answer them in order to make rational choices about duress authentication. In the cases of communicating cells, the key benefit is giving the adjacent nodes time to cleanup their surroundings of evidence or to totally "leave town". --Bob

2 1

Re: The Republic of Desire (anonymous organizations)
by owen＠autodesk.com 17 Dec '03

17 Dec '03

> > My only problem with this is knowing how to organize the > >"guerilla cell structures" or whatever it was he mentioned. Anyone have > >a ref for something that discusses guerilla cell organizations? > > The classic Russian model (late 1800's through the October Revolution) was > to have three-person cells, each of which had one person who knew one > person above them in the hierarchy and someone who knew one person below > them. This makes for good security as there is no redundant information in > the network and one failure breaks the chain. Which was also adopted by the weather-underground in the early seventys. I think a better, and non-political, model is the Astrum Argentum. The A./.A./. is a masonic style hermetic organisation. A secret society if you will. Yes it was headed by Aleister Crowley, yes it still exists today, no I cannot tell you how to contact any part of it. Thats your task to accomplish, if that is your will. I happen to believe that the philosophical basis of the A./.A./., and the OTO, otherwise known as THELEMA, offers us a glimpse of how the future is unfolding. To those pragmatists and engineering types who scoff at Magickal organisations and its members, I can only say that I truley believe if you look without prejudice - suspend disbelief - and recognise the key nature of the basic underpinnings of hermetic philosophy, you will see that *the mysterys* are laid bare all the time, and are no mystery at all, but rather good common sense. Cypherpunks above all others should easily understand that it is possible to code information in such ways that only those who have the key can understand the hidden message (esoteric) while all others see only the filler text ( exoteric). Protect the mysterys, reveal them daily. LUX ./. owen

1 0

unsubscribe
by Thomas J. Merritt 17 Dec '03

17 Dec '03

Please remove me from the cypherpunks mailing list and add me to the cypherpunks-announce mailing list. I don't have time to filter through all this stuff. Thanks, TJ Merritt tjm(a)netcom.com

1 0

UNSUBSCRIBE
by michael＠sdl.hitachi.co.jp 17 Dec '03

17 Dec '03

Please remove me from your cypherpunks mailing list. Could you add me to the cypherpunks-announce mailing list instead? Thanks, M.B.

1 0

Re: hohocon
by hfinney＠shell.portal.com 17 Dec '03

17 Dec '03

Regarding the issue of telnet'ing through an insecure system: A general solution to this problem is to have the system you are attaching to engage in some dialog with you to establish your identity. However, the dialog must be such that even if it is monitored by the system you are going through, that will not allow them to later claim to be you. This is the same basic problem as entering a PIN for a credit or debit card in an environment where the PIN can be seen or recorded. If someone sees your PIN they can steal your ATM card (or dcash card, in the future) and access your money. Cryptographic solutions involve zero-knowledge proof systems but they are too complicated to work in your head. For the hohocon case you could have a calculator programmed with some one-way function (DES is available for the HP48); the remote system could generate a challenge number and you would use your calculator to DES-encrypt it with a fixed secret key, then type the result in, and the remote system would check it. This would not help the hohocon people because next time they tried to log in as you the challenge number would be different. There was a paper in the Eurocrypt 91 proceedings called "Human Identification Through Insecure Channel" which attempted to address this problem. The authors proposed a system which was supposed to be simple enough that you could work the response in your head, but which would be complex enough that eavesdroppers would not be able to figure it out, even after seeing many examples. The idea was that the remote system would issue a challenge as a string of letters or digits: 1982043765. You will give a response of the same length, but only certain positions matter. Those positions are identified by one of two secret words that you memorize. Suppose the first secret is 1246. You will produce a response which embeds the 2nd secret word in the positions where 1,2,4, and 6 appear. Suppose the 2nd secret word is 3124. Your response, written below the challenge, would be: 1982043765 3421223142 - - - - Only the marked positions matter; the others are random. This sounds simple enough, but the problem is that for true security the authors require a much longer string with a much larger set of characters, 40 or 50 characters long. I tried implementing their algorithm, without even memorizing the secrets, just writing them down (they had to be about 10 letters long), and entering in a reponse given a challenge, and I couldn't do it. It was extremely difficult to locate the checked positions and put in the next letter. It took forever to do it, and I kept making mistakes. Maybe with practice it would get easier. Or, perhaps the technique would still be useful with a smaller question size to provide less security but still more than you would get without it. It would be interesting to see if other people come up with approaches to solve this problem. I really don't think that protecting my smart card with a 6-digit PIN is going to be adequate. Hal Finney hfinney(a)shell.portal.com

6 5

axe me
by Timothy Finin 17 Dec '03

17 Dec '03

Please remove me from cypherpunks. I can't handle the volume, it seems. Tim

1 0

unsubscribe
by Robert Harder 17 Dec '03

17 Dec '03

Please unsubscribe me from (to?) your mailing list Thank you. Rob

1 0