December 2003 - cypherpunks-legacy

Re: Request: tamper-proofing executables
by jamiel＠sybase.com 17 Dec '03

17 Dec '03

At 1:19 PM 07/08/94 -0400, Michael Handler wrote: > OTOH, if anyone else has come up with a scheme that is hard to >break / unbreakable, *please* come formward and correct me. I have a few >applications that I'd like to apply this to. :) The only method I have heard (and this is merely hard to break) is to put the hash value in a dongle. Then everyone will hate your program. Another method that could provide interesting results is to throw code in that will cause the program to function *differently* if hacked. I'm thinking of (I think- correcttions wecome) AutoCad, which was dongled and hacked, but the hack caused some math funciton or another to return erroneous results. This is just obfusification, but could give a hacker some major headaches. -j -- "Blah Blah Blah" ___________________________________________________________________ Jamie Lawrence <jamiel(a)sybase.com>

1 0

Re: Question: Key Distr. in realtimeo applications?
by kentborg＠world.std.com 17 Dec '03

17 Dec '03

adam(a)bwh.harvard.edu writes: >Sending your otp by RSA reduces the security of your OTP to that of RSA Who said anything about sending a one time pad under RSA? I was talking about a session key. Sorry not to use the buzz word "session key", but neither did I use the buzz word "otp", I just said "random"... -kb -- Kent Borg +1 (617) 776-6899 kentborg(a)world.std.com kentborg(a)aol.com Proud to claim 31:15 hours of TV viewing so far in 1994!

1 0

ON-LINE SOURCES
by Sandy Sandfort 17 Dec '03

17 Dec '03

C'punks, I'm editing a special report on privacy. The publisher wants a chapter on how to use our computer to access on-line, privacy information. What I'd like are the names and address of privacy-related newsgroups, mailing lists, BBSes, on-line services, etc. Please send me your candidates (plus descriptions and contact information) to me via private e-mail. I'll collate the information and post the final version to Cypherpunks. Thanks in advance, S a n d y P.S. Of course, Cypherpunks will be prominently mentioned in the report.

1 0

Bit counting
by Ian Farquhar 17 Dec '03

17 Dec '03

>Why bother when you can simply do an eight line function? >int bitcount(char b) >{ >register int retval=0; > if (a & 1) retval++; > if (a & 2) retval++; > if (a & 4) retval++; > if (a & 8) retval++; > if (a & 16) retval++; > if (a & 32) retval++; > if (a & 64) retval++; > if (a & 128) retval++; >return retval; >} [...] Because on a lot of architectures this implementation may be hideously inefficient. All the world is not an Intel chip, thank god. Ian.

3 2

Re: BSD random() - any good (source included)
by John Young 17 Dec '03

17 Dec '03

Jim: This seems not to have made it through c'punks system. Keep up your clear and reasonable responses. Cheers, John Forwarding mail by: cypherpunks(a)toad.com () on 7/8/94 10:06:32 AM ------------------- Responding to msg by ravage(a)bga.com (Jim choate) on Fri, 8 Jul 8:33 AM >While it is true that some of my questions are off the >wall, I will continue to ask them. If they bother then >.kill me. As an aside to this I will continue to >remail articles of technical interest (what c-punks is >about last I heard anything) that I feel have a good >case of being lost. [Stuff deleted] >If we are really going to continue this thread then a >serious discussion relating to c-punks and some form >of submission standard needs to be agreed upon. Good points. I appreciate Jim's dauntless rejoinder. John

1 0

Re: Request: tamper-proofing executables
by Patrick G. Bridges 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- The best I can think of (right now) is embedding digital signatures in the file. One way or another, the program is going to have be decrypted to run (unless you're using NSA`s patented EES4400 2500 MHz 0.1 micron run-encrypted CPU :-) ). Anyone with a debugger and a disassembler could then derive a version of the program as it decrypts and make a hacked up version. At least if a digital signature is in the program and it verifies _with a program you trust_ (a very important point), then you know who last signed it. (and who to blame if it does something wrong or vindictive) Doing verification inside the program is just too messy, since a good cracker could set up your program to always act like verified correctly even if it was modified. It may be more difficult if the program is encrypted, but it is still doable... Since you almost always trust the kernel (you sort of have to on most machines, since it can f*ck with you in so many ways, by stealing your PGP passphrase, for example), the kernel loader might be a good place to do this verification for important programs. (It would slow the machine down to much to do this for _every_ program, IMHO) If a user wants to verify his program, make the external verification program be checked by the kernel... In the end, you have to trust someone. Just choose very carefully who you trust. I guess I sort of got off on a tangent, but, oh well... I guess I need to go revise (perhaps rewrite) my signature-embedding program, since "cypherpunks write code." :-) -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLh3FtkoL7Aaetl5pAQF2awP/WANyuh8Ivdyn226/qo2ndzRW30VA5SuO 0x5/CsSHXWYvk1VrFYzBtZtYLcADuqJdwF0dI76+yROJ7S8kKvky5ALoWudh0sSq IT+0L0ufaL40gklSp2SulqHrNrhfoVNiVb3xImCVCUIW68nsAgwHWyRVCmcjMHJ+ zjS9KhsYo20= =QPfM -----END PGP SIGNATURE----- -- *** Patrick G. Bridges patrick(a)CS.MsState.Edu *** *** PGP 2.6 public key available via finger or server *** *** PGP 2.6 Public Key Fingerprint: *** *** D6 09 C7 1F 4C 18 D5 18 7E 02 50 E6 B1 AB A5 2C *** *** #include <std/disclaimer.h> ***

1 0

Re: BSD random() - any good (source included)
by John Young 17 Dec '03

17 Dec '03

Responding to msg by sandfort(a)crl.com (Sandy Sandfort) on Fri, 8 Jul 3:0 PM >Not a flame here, but a slight difference of opinion. >The admonition, "Cypherpunks write code," should be >taken metaphorically. I think "to write code" means >to take unilateral effective action as an individual. >That may mean writing actual code, but it could also >mean dumpster diving at Mycrotronx and anonymously >releasing the recovered information. It could also >mean creating an offshore digital bank. Don't get too >literal on us here. What is important is that >Cypherpunks take personal responsibility for >empowering themselves against threats to privacy. Well said. John

1 0

EFF Privacy Principles commentary available
by Stanton McCandlish 17 Dec '03

17 Dec '03

Thought this might be of immediate interest: [from ftp.eff.org, /pub/README.changes; path refers to ftp.eff.org] 07/08/94 - Added EFF's comments on the IITF draft Privacy Principles document (in short: "Needs work!") - there are serious flaws in the document, which could lead to policies that would compromise privacy and security on the NII. - /pub/EFF/Policy/Privacy/ Email_NII/iitf_principles_comments.eff -- Stanton McCandlish * mech(a)eff.org * Electronic Frontier Found. OnlineActivist F O R M O R E I N F O, E - M A I L T O: I N F O @ E F F . O R G O P E N P L A T F O R M O N L I N E R I G H T S V I R T U A L C U L T U R E C R Y P T O

1 0

Re: (fwd) Re: BSD random() - any good (source included)
by lefty＠apple.com 17 Dec '03

17 Dec '03

Jim Choate favors us with > >Why should a couple of dozen people who scream because they don't get >exactly what they want dictate to a list that is 700 long? > >Lump me in where you feel justified. That classification and a dollar will >by you a cheap cup of coffee. > >If there was a vociferous return on this I would be much more responsive, but >what I see is the same small group of a dozen or so bitching and bitching and >bitching and bitching....(you get the point) > >What is really funny is that they bitch about crypto stuff but seem completely >happy to blather on endlessly about pedophiles, off-shore banking, and a whole >host of other topics that are completely and uterly unrelated to "c-punks >write code". > >So far I have recieved no reasoned responces to these issue, a lot of opinion >and emotionaly driven wailing has shown up in my box... I wasn't going to contribute to this, but Jim is apparently impervious to reason unless _everyone_ on the list screams at him. Don't forward reams of stuff available elsewhere to the list. If you like, mention where it is; offer to send copies to those who specifically request it. Don't post it to the list. Add me to your "couple of dozen who scream". On a more personal note, digging your heels in and sobbing "I won't, I _won't_, I WON'T!" at the perfectly reasonable suggestions that have been made to you make you seem like a puerile and self-centered preadolescent. Grow up. -- Lefty (lefty(a)apple.com) C:.M:.C:., D:.O:.D:.

2 1

Re: (fwd) Re: BSD random() - any good (source included)
by sidney＠taurus.apple.com 17 Dec '03

17 Dec '03

Jim Choate wants to hear from the silent majority before he'll believe that a significant number of people were not interested in 65k of fortran code and seeing the same message quoted 0, 1, 2, and 3 levels deep. (I thought that was a really nice touch, even better than the Fortran code). I'll add my two cents, and we'll see if we can get all 698 other people on the list to respond. I won't be elitist and try to use statistics to prove the point (As in, if 11 people bother to respond, 10 against and 1 supportive of the mailings, and there are 700 people subscribed to the list, than what is the probability that there are at least 600 people who not only aren't interested in having the stuff dropped in their mailbox, but don't even want to waste time writing about it or waste other people's time by have them read stuff about it.) After all, we saw how useless simplified explanations of the relationship between breaking RSA and factoring of large numbers were at convincing certain people in other discussions, or reasoning about the uselessness of making keys that take trillions of universe lifetimes to break instead of mere millions of years. This discussion has been very useful to me. It got me to finally read up on Eudora Mail's filtering facility, so now I know how to kill e-mail automagically based on various specified criteria. Thank you, Jim. It's always good to learn new things. By the way, referring to a random number generator as "cryptoweak" does not mean that it is somehow relevant to cryptography. A cryptoweak something is a thing that is *not* useful for cryptography. Well, I suppose an article on how cryptoweak RNGs could be used in a cryptographically strong system would be of interest to this list, but so would an article on how Twinkies and taco sauce could be used to create strong cryptography. But please don't forward any usenet articles about Zippy's diet on the theory that cypherpunks should be interested in it because of its strong non-relationship to the purpose of this list. -- sidney <sidney(a)apple.com>

1 0