December 2003 - cypherpunks-legacy

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

(fwd) Re: BSD random() - any good (source included)
by an65＠vox.hacktic.nl 17 Dec '03

17 Dec '03

> At 3:20 PM 07/07/94 -0500, Jim choate wrote 69K of forwards > (so far) that I would much rather look at in sci.math or > sci.stat.math than in my mailbox, unrequested. Didn't we have > a little forwarding talk recently enough for your avarage > televangelist viewer to remember it? > Kindly cut it out. I guess cypherpunks would rather not write or even read code, but simply gossip about usenet kooks and pedophiles. > ___________________________________________________________________ > Jamie Lawrence <jamiel(a)sybase.com> > c@lib@n -------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)vox.hacktic.nl Please report any problems, inappropriate use etc. to admin(a)vox.hacktic.nl Direct replies to the sender of this message are -not- anonymised..<YuK>..

9 15

Re: All the free energy in the universe
by doug＠OpenMind.com 17 Dec '03

17 Dec '03

Tim May writes: >Not to split universes here, but it is interesting to consider that >some ciphers may not be breakable in _our_ universe, in any amount of >time. > >Our universe presumably has some finite number of particles (currently >estimated to be 10^73 particles). This leads to the "even if every >particle were a Cray Y-MP it would take..." sorts of thought >experiments. > >But I am considering _energy_ here. Ignoring reversible computation >for the moment, computations dissipate energy (some disagree with this >point). There is some uppper limit on how many basic computations >could ever be done with the amount of free energy in the universe. (A >rough calculation could be done by calculating the energy output of >stars, stuff falling into black holes, etc., and then assuming about >kT per logical operation. This should be accurate to within a few >orders of magnitude.) The above analysis may be incorrect... there may be no limit to the amount of computation that can be done with a given finite amount of energy. The late Nobel laureate Richard Feynman became very interested in the subject of computation and physics towards the end of his life. My understanding is that he concluded that there was no apparent limitation to the amount of computation that could be completed with a given amount of free energy. Computation may indeed always dissipate energy, but Feyman's conclusion was that this dissipated energy can be made arbitrarily small -- that there is no fundamental quantum limitation on the amount of computation that can be performed at any given mass-energy scale. The kT per logical operation can always be reduced to finer and finer scales. Presumably, this would require advances to ever new technologies, based on new physical forces that are relevant at finer scales (down to computation based on the interactions of quarks as in QCD, gravitons, etc.) Of course, since I can't give you references, you have to take this with a brick of salt... can anyone else comment on whether they have heard this about Feynman's conclusions? This is distinct from the issue of "quantum computers" and Shor's recent results... that issue has to do with whether quantum mechanics can be used to produce *qualitatively* different types of computation. In the above, I am simply discussing the use of quantum mechanical principles to produce fully "classical" computers, but with every greater computational powers using a given amount of energy, based on physics of the ultra-small. In fact, classical computers today rely on quantum mechanics, as the transistor cannot be described without it (electron tunneling, etc.) __ __ __ __ Doug Cutrell / ) /__) /_ /\ / /| /| / /\ / / ) doug(a)OpenMind.com \_/ / (_ / \/ / |/ | / / \/ /__/ ===================================================================

2 1

Request: tamper-proofing executables
by Dan Marner 17 Dec '03

17 Dec '03

I would appreciate any pointers to documents, source code or programs that deal with using cryptographic techniques to detect or prevent modification of executable code. I am looking for something that uses either a signature or a one-way hash to detect modifications at run time. Of particular interest is information on signing a file that includes the signature as part of the file. Is this possible with any of the common algorithms? Thanks! Dan -- Dan Marner dmarner(a)mis.nu.edu Network Weasel National University "Not on MY network!"

7 6