December 2003 - cypherpunks-legacy

Re: ViaCrypt PGP has arrived
by pierre＠shell.portal.com 17 Dec '03

17 Dec '03

> From: jim(a)bilbo.suite.com (Jim Miller) [...] > I realize that by not compiling the code myself on my own machine I basically > have to trust the ViaCrypt PGP implementation. So be it. If there is > something wrong with ViaCrypt PGP I believe it will eventually be discovered. > Somebody will no doubt disassemble it and look for backdoors. If someone finds > one, ViaCrypt's reputation will be worthless. It's in ViaCrypts best interest > not to put in any backdoors. Unfortunately, backdoors have not been the main security problem in commercial system software, bugs and "honest mistakes" have been. Unfortunately too, there has been very little pressure by customers to hold companies accountable for the software they ship. Usually somebody uncovers a bug, uses it for a while, is detected, and that causes (in the best case) the software company to issue a new patch. Some distribute the patches for free, some make you pay big bucks for it. But never is the company really harmed by the fact that it claimed some level of security (or functionality), and was not providing it. If, in the future, ViaCrypt says "ooops, there was a debugging switch left on when we compiled, here is a free patch." would you discard your ViaCrypt PGP, buy the competitor's version (there is none), and sue them? Did they include any disclaimer in the license? Call me cynical, Pierre. pierre(a)shell.portal.com

1 0

Re: PGP BUG/FEATURE: multi-platform keys
by dmandl＠lehman.com 17 Dec '03

17 Dec '03

> As long as I'm at it, here are some more macPGP2.3 bugs, for those who care. Trying to decrypt a message signed by a key I don't have causes a serious crash requiring reboot. Trying to select cancel in a signature dialogue just raises the same dialogue box instead of cancelling. I'm running on a powerbook 145 under system 7.0.1. > > Eternal!Optimist(a)anon.penet.fi (copyright 1993, Eternal Optimist [Ha Ha Ha]) > 0) 0) =:()]-< <na26436(a)anon.penet.fi> It's been a while since I beta-tested MacPGP 2.3, but I think that... The problem with quitting out of the pass phrase prompt was a "feature." When you pressed CANCEL, the interface told the pgp engine that you had typed in a bad pass phrase. I guess this was an easy quick and dirty way to handle it. The problem was, when you typed in a bad pass phrase, you were given two more chances to get it right. Therefore, when you pressed CANCEL, you were also prompted two more times. So, you had to press CANCEL three times to quit from that prompt. This was fixed in 2.3a, a beta version of which I've got. I guess the official 2.3a has been released by now, but I haven't checked. --Dave.

1 0

Sternlight
by Carl Ellison 17 Dec '03

17 Dec '03

I don't know who wanted to start reposting Sternlight posts to this list, but I have a good way in my news reader to avoid mail from him or in reply to him or talking about him -- but lack such facilities in my mail reader. Could any message mentioning Sternlight or reacting to something he said (however indirectly) include his name in the subject line so that I can kill it without reading? Thank you. - Carl

1 0

Re: trusting software
by doug＠netcom.com 17 Dec '03

17 Dec '03

ogr(a)wyvern.wyvern.com (Jason Plank) said: > Phil Zimmerman solved this problem by supplying the source code for >his product. You can see for yourself that there are no backdoors. This helps, but is imperfect. How many people will read their particular copy in sufficient detail to ascertain that there aren't any obvious backdoors added by e.g. a sneaky archive site maintainer, or some sneaky cracker who found a way to modify the archived copy? Furthermore, even close reading won't absolutely *guarantee* the lack of backdoors in all cases, even if the reader is an expert on relevant subjects. We'll all continue to use software despite lack of absolute assurances, but it's worth keeping in mind what the situation is. Doug

2 1

Re: trusting software
by doug＠netcom.com 17 Dec '03

17 Dec '03

greg(a)ideath.goldenbear.com (Greg Broiles) said: >It's not clear to me how you can trust systems not under your control to >report on themselves or local conditions accurately. As your program gets >more complex, aren't you going to run into an analog of the Turing >machine/halting problem? The idea is to encode the important-to-be-trusted features of the software and the inter-machine protocol handshake together into the equivalent of a Goedel number which acts as a public key during the protocol handshake, so that any change to that core encoding of the functionality would have the side effect that it was no longer able to communicate. >It's an intriguing idea, but it's still very unclear to me how it might >work on software of any real complexity. Yeah...I'm having strong difficulties with doing it in a way that is computationally feasible as well as theoretically sound. Several times I thought I'd found the right approach but then found holes in it. So I lied in implying that I really did have a final algorithm....I *thought* I did, but I was wrong. Doug

1 0

punk-net mailing list
by jdblair＠nextsrv.cas.muohio.EDU 17 Dec '03

17 Dec '03

To those interested in participating in a hardware specific cypherpunks list, (punk-net, net underground, whatever) e-mail me. My sysadmin is cool with the idea of setting the list up here, so if a decent number of people respond over the next week, I'll set it up. So, hardware fiends... time to bring a whiff of burnt flux and overheated resistors to the world of underground cryptography. -john. jdblair(a)nextsrv.cas.muohio.edu

1 0

Re: Hole in MD5 (Not)
by collins＠newton.apple.com 17 Dec '03

17 Dec '03

What follows is a private e-mail exchange with Burt Kaliski (posted with his permission), where he clarifies the 'hole in MD5' and shows that it does not afford the attack I described previously. Mike Ingle: >Recently there was a message here about MD5 having a hole in it. >Maybe this is what the person was talking about... Bruce Schneier: [ describes Bart Preneel's Ph.D. thesis, which cites the work of den Boer and Bosselaer ] Burt Kaliski: [ a LaTeX document noting the implications, or lack thereof, of den Boer and Bosselaers' work ] Scott Collins: [ describes an attack on (e.g.) Bellcore's timestamp system; wonders if den Boer and Bosselaers' work makes this attack possible ] Burt Kaliski (private response): >When operating on single blocks, MD5 computes a function z = f(x,y0), >where x is the 512-bit message block, y0 is a fixed 128-bit value, and >z is the 128-bit message digest. > >den Boer and Bosselaers found a way to construct a triple (x,y1,y2) >such that f(x,y1) = f(x,y2). The y1 and y2 values are not the same as >the fixed y0, so clearly this is different than an MD5 collision, >which would have different message blocks. > >I'm not sure how this relates to the attack you have in mind, although >I'd be interested in more details. Also, the attack you describe is >"after-the-fact" in the sense that the target value h_N is already >published. To forge a time-stamp at that point, what I need is not a >collision, but an inversion. (I have to find something that hashes to >h_N.) Collisions play a greater role "before-the-fact," where I might >give Eve something to sign, where I happen to know another message >with the same digest. > >-- Burt Kaliski >RSA Laboratories Scott Collins: > [ ... ] > >Ahh. This is not (even close to) a big enough foothold to support my >attack. :-) > > [ ... ] > >The attack does, in fact, require inversion. Since the verifier can't >compare the depth of the alleged hash tree to the actual one, the attack is >still possible even when only _some_ inversions are possible, as long as >the attacker can find one along the actual path to the root (the degenerate >case being when the attacker can find an inversion for the root itself). > >The attack only came to mind because the the depth cannot be verified, and >so the attacker is not limited in the number of steps (in case she can only >find inversions of a special form); the intermediate hash values are all of >minimal size; the intermediate hash values are expected to be 'random', and >so there is no constraint requiring human-readable inversions. Thus, it >seemed that if an the hash could be usefully inverted, this would be the >situation that allowed it. > >Thanks for the clarification. May I repost your answer, or at least _this_ >message which quotes it, to the original distribution list of my question? Permission was granted. Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins(a)newton.apple.com Apple Computer, Inc. 5 Infinite Loop, MS 305-2B Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024:669687 catalyst(a)netcom.com

1 0

Sarah's Bio
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

In article <199311051657.IAA20001(a)mail.netcom.com> doug(a)netcom.com writes: > ogr(a)wyvern.wyvern.com (Jason Plank) said: > > Phil Zimmerman solved this problem by supplying the source code for > >his product. You can see for yourself that there are no backdoors. > > This helps, but is imperfect. How many people will read their particular > copy in sufficient detail to ascertain that there aren't any obvious > backdoors added by e.g. a sneaky archive site maintainer, or some sneaky > cracker who found a way to modify the archived copy? Well, I did for one. Some of you may remember me posting to sci.crypt quite some time ago, because the one thing I wasn't happy about was the use of a probabilistic primality tester when there were completely certain primality tests available (albeit a bit more expensive in cpu). (especially since I didn't understand how the probabilistic one worked) I see from a posting on sci.crypt today that the probabilistic tests have been show to be possibly mildly weak in some infrequent cases. Probably not worth worrying about, but still, it's a sobering thought. The rest of the code I understood well enough to trust it, mostly :) G -- Personal mail to gtoal(a)gtoal.com (I read it in the evenings) Business mail to gtoal(a)an-teallach.com (Be careful with the spelling!) Faxes to An Teallach Limited: +44 31 662 4678 Voice: +44 31 668 1550 x212

1 0

dcnets and tcmay cartoon
by Matthew J Miszewski 17 Dec '03

17 Dec '03

I have just been reading d. Chaum's _Security without identification: Card Computers to make Big Brother Obsolete_ and have some questions. But Ill ask the serious ones in another post. For this one, and to satisfy the comparable conspiracy buffs on the list, look first at the Cypherpunks Wired issue. Now look at the comic in Chaum's paper. I guess that bearded guy with the longer hair could be....hmm....Jamie...no...Nick...no ITS TIM MAY! --Matt ______________________________________________________________________________ In defense of liberty, encrypt for all purposes, civil and professional. In defense of privacy, encrypt all correspondence, personal and professional. In defense of sanity, do not encrypt your dry cleaning invoice! ++++++++--------mjmiski(a)macc.wisc.edu (c)1993

1 0

ANON: random remailing
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >Exacltly how do you fake mail with telnet or use a newsgroup for >one-way anonymous email? Care to elaborate? Whoops, I think I was vague in my earlier response. In mail, either you know whoever your mailing to or you don't. If A wants to mail B and doesn't need a response: If A doesn't know B, A could use telnet to fake mail to B. This leaves more of a trail than an anonymous remailer, narrows down where the message could have come from, but obscures who actually sent it (I'm sure some logging facilities invalidate this). If A knows B, they could agree to use a newsgroup as an anonymous pool (sort of). A posts a message, B reads it. - From time to time, random remailing is suggested. I think I'll go re-read Chaum's paper and think about it more, but I'm nearly positive that this makes it easier to pair up sender and destination. Suppose remailers used random routing. Assuming one remailer can be trusted (the first hop) so linking A and mail sent to the trusted remailer is not possible, A could send to B via the trusted remailer. B's address will be made available to every remailer. Now when B replies, A's address is made available. Caching and padding messages may help, but all an eavesdropper has to do is monitor mail from B, a known address, and when mail hits any remailer, A's address is known. So is it reasonable to assume an eavesdropper can monitor a remailer (all remailers except the trusted remailer), they can also monitor an arbitrary address (B's)? Hm... -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLNrmyoOA7OpLWtYzAQHZxgP9HtoFrHh+grNuP3rG3jI+uXYRi36FzQ7f /BftSwec4ZGtJ/L14EB1fwP6j31m365VflUMzckJk0kViLcS3pMT85dCEK5pIduu kzzdhBGS/MRYaj2uHlSMdz2dtyzwtjYc7hLyAriPLCKcwLrCcc440G81Z0BSWOhj 5ECgPYSNsIM= =VKgV -----END PGP SIGNATURE-----

1 0