December 2003 - cypherpunks-legacy

One time pads, Next question?
by AaronH4321＠aol.com 17 Dec '03

17 Dec '03

Okay, with the intel I have gotten from the responses let me modify and clarify. So, I now know that you can't use a PRNG to create a OTP. If I did have a RNG that could create a "cryptographically" random, million character OTP and I physically loaded the data onto each computer I wanted to communicate with(e.i. group of laptops all loaded at the same location, same time), how cryptographically secure would the data be. I know that physical security would be a nessescary to the system. If I add some type of error checking to make sure someone that knows the plaintext doesn't modify specific characters, an attacker knows what the message is (e.g. "Send $10 to Bob") the message can be altered (to "Send $99 to Bob") even though it is encrypted. So, lets recap. If the keyig material is kept secure, and if the OTP is cryptographically random, and if error checking is implemented then would this be considered a secure(however encumbering it may be) system. Aaron.....

1 0

Re: Keyword scanning/speech recognition
by Lucky Green 17 Dec '03

17 Dec '03

At 03:34 AM 1/19/97, pgut001(a)cs.auckland.ac.nz wrote: >I was talking to someone recently about the feasibilty of keyword-scanning >phone conversations. He thought it was probably still beyond the reach of >current technology, I thought it wasn't. I once met a fellow who's company makes high performance key word scanning and speaker recognition products for use by governmental entities in analyzing voice communications. Unfortunately, I lost his business card. -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred Make your mark in the history of mathematics. Use the spare cycles of your PC/PPC/UNIX box to help find a new prime. http://www.mersenne.org/prime.htm

1 0

RE: One time pads and randomness?
by Blake Coverett 17 Dec '03

17 Dec '03

> I want to use a one time pad pased crypto system. I understand that the > randomness of the pad genorator is key to security(other than lossing the > keys). What I want to know is if I use a psuedo-RNG that maybe repeats its > self every 1000 characters and use it to only encrypt messagase that are > 100's of charaters long, will this be a major security risk? I'm afraid you've fallen into one of the standard traps. A PRNG can *not* make a OTP no matter how you use it. The total amount of entropy in a PRNG is the amount of entropy in the seed you use to key it. All the other bits are directly derived from that seed. A true OTP is completely secure from an information-theory point of view because every byte has a full eight bits of entropy. A PRNG can never have this. Having said all this, it is possible to make a good cipher from a PRNG. RC4, for example, is exactly that and the variable sized key is the seed for the PRNG. It is however very difficult to come up with a good algorithm for that cryptographically sound PRNG and you would be much further ahead to use an existing one rather that trying to roll your own. > Say I create a 1 million character one time pad that passes all of the > randomness tests. It is "truely random". I place it on two computers. Now > when these two computers want to send email computer "A" grabs a chunk of the > one time pad starting at a random point and encrypts it. It labels the email > with the random starting point and sends it to "B". There "B" moves to the > random point and begins decryption. During to process both computers mark > that section of the OTP used so that they don't retransmit with it. I realize > this has a limited amount of messages before it is used up. But would this be > secure? Any suggestions, complaints, big gapping holes I missed? I don't see anything wrong as such, but there is nothing to be gained either. If your random data is real OTP material there is no need to skip to a random byte within it, just start at the beginning and use it in sequence. If your random data is the output of a PRNG like the above then random starting point doesn't buy you much additional security because the entire set of keying material can be recreated from the seed. It may increase the work-factor of searching for the key, but it also imposes the practical problem of keeping all that keying material secure. More importantly don't confuse statistically random with cryptographically random. Just because a bunch of bits passes all the randomness test you can think of doesn't mean it contains 100% entropy. Consider the digits of an irrational number like sqrt(2) or pi, the digits appear statistically random but they can be recreated from just a tiny bit of knowledge. A good litmus test is to ask yourself if there is any way you can reproduce those bits. If there is, they aren't a one time pad. (Of course even if you can't it doesn't mean they are good. :-) regards, -Blake

2 1

Concerned about Pretty Safe Mail for Mac
by nobody＠replay.com 17 Dec '03

17 Dec '03

I'm concerned about the product "Pretty Safe Mail" for the Macintosh, by a company called Highware. I was wondering whether anyone here had tried evaluating it at all. It is a complete PGP implementation (not a front-end). They claim to have licensed some of PRZ's code from PGP. However, as far as I can tell, they are not making any of the source code available. As someone on the comp.security.pgp newsgroups pointed out, writing a wonderful user interface on a PGP trojan horse that either crippled the session key generator or used the session key to leak random portions of secret key primes would be a perfect tactic for a government wishing to penetrate PGP security. With such a great interface, compared to the original PGP, it can't help but become widely used. I realize that without the source code, it's a major hassle, but has anyone looked at Pretty Safe Mail (previously called Safemail) at all for suspicious behavior? For example: 1) non-random session key generation? 2) non-random key pair generation? 3) unnecessary disk access to secret keys? 4) anything else? Any findings, positive or negative, would be appreciated.

1 0

Gilmore and Sandfart suck big dicks
by dlv＠bwalk.dm.com 17 Dec '03

17 Dec '03

Someone wrote to me: >Did you not mean any homo who has ever shaffted Gilmore and Sandy can >write what the fuck they like but straight or intelligent or NORMAL >people will have to be filtered. Yes, that's precisely how Sandfart's moderation will work. Homosexuals like Jason Durbin will continue to post personal attacks on Gilmore's many "enemies", but the victims of the libel will not be able to respond and refute their lies. The concept of "the best response to speech you don't like is more speech" is totally alien to the homosexual subculture on the Internet. These control freaks are into censorship and B&D. >I realize that normal people are few and far between in cypher punks. There may be quite a few normal and knowledgeable people left among the subscribers, but most posters are indeed militant homosexual censors who don't care about crypto except to drop a few "kewl" phrases - like Paul Bradley's infamous "brute-force attack on one-time pads". >I am NOT a cypher-punk and I hope that you do not class me as one, I am >merely interested in cryptography and believe it or not I actually pick >up tips every now and again from the list. I'm sure you're not a "cypher punk" - you're both too smart and too straight. :-) A while back I saw an announcement of a "cypher punks" meating where Jim Bell was explicitly disinvited, and I announced that I don't consider myself a "cypher punk". Jim Bell is a pro-censorship asshole, but I will defend his freedom of speech nevertheless. Occasional tidbits of useful information do still appear on this list. >I am against moderation on the list and I aggree that Gilmug is a lying >cocksucker. Please bear in mind that not everyone on the list is a >"jew-hating" faggot with nothing but shit between their ears. I wholeheartedly agree - however anyone who describes himself as a "cypher punk", after John Gilmore's dishonorable actions, probably is. --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

7 15

GSM technology
by azur＠netcom.com 17 Dec '03

17 Dec '03

GSM DATA FEATURES GSM is particularly suited for mobile data communications. All GSM base systems support 9.6kbit/s circuit-switched data services, soon many will increase transmission speed up to 28.8kbit/s. A new part of the GSM standard, known as High Speed Circuit Switched Data (HSCSD), is being developed which will boost user capacity up to 64 kbit/s, and higher. Interconnecting this 64 kbit/s wireless capability with public ISDN networks, for example, will give mobile users complete end-to-end digital connectivity with the attendant benefits of very fast set-up times and high link quality. Technically, HSCSD requires a new radio link protocol; a modification of the existing protocol used to provide the GSM voice channel. GSM uses TDMA (Time Division Multiple Access) technology, which divides each 200 kHz carrier into eight timeslots. To provide a single voice channel, one timeslot is used; one timeslot is also used to provide a single 9.6 kbit/s data circuit. However, all eight slots will be used to provide one 64 kbit/s circuit. The main benefit of this approach is that it is designed for the existing GSM infra-structure. There is no need for operators to change their entire network infrastructure in order to implement it. Operators will therefore be able to implement HSCSD in a quick and efficient way, once the specification has been ratified. ENCRYPTED GSM LINKS If the GSM phone includes a data port, as some already do, just connect your laptop, dial your ISP and 'push' the encrypted traffic over that link (e.g., using TCP/IP and PGPfone). REFERENCES If you really want to dive headfirst into GSM, the following is a resource list generated in 1994: @article(rahn, author = {Rahnema, Moe}, title = "Overview of the {GSM} System and Protocol Architecture", journal = {IEEE Communications Magazine}, month = {April}, year = 1993) @incollection(chee, author = {Cheeseman, David}, title = "The pan-{European} cellular mobile radio system", booktitle = {Personal and Mobile Radio Systems}, editor = {R.C.V. Macario}, publisher = {Peter Peregrinus}, address = {London}, year = 1991) @incollection(bals1, author = {Balston, David M.}, title = "The pan-{European} cellular technology", booktitle = {Personal and Mobile Radio Systems}, editor = {R.C.V. Macario}, publisher = {Peter Peregrinus}, address = {London}, year = 1991) @article(moha, author = {Mohan, Seshadri and Jain, Ravi}, title = "Two User Location Strategies for Personal Communication Services", journal = {IEEE Personal Communications}, volume = 1, number = 1, year = 1994) @inproceedings(haug, author = {Haug, Thomas}, title = "Overview of the {GSM} Project", booktitle = {EUROCON 88}, month = {June}, year = 1988) @inproceedings(mall, author = {Mallinder, Bernard J. T.}, title = "Specification Methodology Applied to the {GSM} System", booktitle = {EUROCON 88}, month = {June}, year = 1988) @inproceedings(aude, author = {Audestad, Jan A.}, title = "Network Aspects of the {GSM} System", booktitle = {EUROCON 88}, month = {June}, year = 1988) @incollection(bals2, author = {Balston, D. M.}, title = "The pan-{European} System: {GSM}", booktitle = {Cellular Radio Systems}, editor = {Balston, D. M. and Macario, R.C.V.}, publisher = {Artech House}, address = {Boston}, year = 1993) @incollection(wats, author = {Watson, C.}, title = "Radio Equipment for {GSM}", booktitle = {Cellular Radio Systems}, editor = {Balston, D. M. and Macario, R.C.V.}, publisher = {Artech House}, address = {Boston}, year = 1993) @incollection(harr1, author = {Harris, I.}, title = "Data in the {GSM} Cellular Network", booktitle = {Cellular Radio Systems}, editor = {Balston, D. M. and Macario, R.C.V.}, publisher = {Artech House}, address = {Boston}, year = 1993) @incollection(harr2, author = {Harris, I.}, title = "Facsimile over Cellular Radio", booktitle = {Cellular Radio Systems}, editor = {Balston, D. M. and Macario, R.C.V.}, publisher = {Artech House}, address = {Boston}, year = 1993) @article(dech, author = {D\'echaux, C. and Scheller, R.}, title = "What are {GSM} and {DCS}", journal = {Electrical Communication}, month = {2nd Quarter}, year = 1993) @article(feld, author = {Feldmann, M. and Rissen, J. P.}, title = "{GSM} Network Systems and Overall System Integration", journal = {Electrical Communication}, month = {2nd Quarter}, year = 1993) @article(bezl, author = {Bezler, M. and others}, title = "{GSM} Base Station System", journal = {Electrical Communication}, month = {2nd Quarter}, year = 1993) @article(schm, author = {Schmid, E. H. and K\"ahler, M.}, title = "{GSM} Operation and Maintenance", journal = {Electrical Communication}, month = {2nd Quarter}, year = 1993) @article(lobe, author = {Lobensommer, Hans and Mahner, Helmut}, title = "{GSM} -- a {European} Mobile Radio Standard for the World Market", journal = {Telcom Report International}, volume = 15, number = {3-4}, year = 1992) @article(hube, author = {Huber, Josef--Franz}, title = "Advanced Equipment for an Advanced Network", journal = {Telcom Report International}, volume = 15, number = {3-4}, year = 1992) @book(winc, author = {Winch, Robert G.}, title = "Telecommunication Transmission Systems", publisher = {McGraw-Hill}, address = {New York}, year = 1993) @inproceedings(natv, author = {Natvig, Jon E. and Hansen, Stein and de Brito, Jorge}, title = "Speech Processing in the pan-{European} Digital Mobile Radio System ({GSM}) --- System Overview", booktitle = {IEEE GLOBECOM 1989}, month = {November}, year = 1989) @inproceedings(vary, author = {Vary, P. and others}, title = "Speech Codec for the {European} Mobile Radio System", booktitle = {IEEE GLOBECOM 1989}, month = {November}, year = 1989) @inproceedings(sout, author = {Southcott, C. B. and others}, title = "Voice Control of the pan-{European} Digital Mobile Radio System", booktitle = {IEEE GLOBECOM 1989}, month = {November}, year = 1989) @unpublished(nils, author = {Nilsson, Torbjorn}, title = "Toward a New Era in Mobile Communications", note = {http://193.78.100.33/ (Ericsson WWW server)}) PGP Fingerprint: FE 90 1A 95 9D EA 8D 61 81 2E CC A9 A4 4A FB A9 --------------------------------------------------------------------- Steve Schear (N7ZEZ) | Internet: azur(a)netcom.com Lamarr Labs | Voice: 1-702-658-2654 7075 West Gowan Road | Fax: 1-702-658-2673 Suite 2148 | Las Vegas, NV 89129 | --------------------------------------------------------------------- Internet, electronic currency and wireless development 1935 will go down in history! For the first time a civilized nation has full gun registration! Our streets will be safer, our police more efficient, and the world will follow our lead in the future! --Adolf Hitler

3 2

Re: [Fwd: Re: Victory Party]
by dlv＠bwalk.dm.com 17 Dec '03

17 Dec '03

Dale Thorn <dthorn(a)gte.net> writes: > aga wrote: > > Date: Sat, 18 Jan 1997 13:34:37 GMT > > On Sat, 18 Jan 1997, SB wrote: > > From: J Durbin <slothrop(a)poisson.com> > > > Forward on the good Dr. Vulis from ne.internet.services. > > > Newsgroups: ne.internet.services, alt.fan.speedbump, alt.god.grubor > > > Steve Subject: Re: Victory Party > > > hannigan(a)shore.net (Martin Hannigan) wrote: > > >Steve/Grubby/Vulis/Aga: You can come too. Of course. > > > The Cypherpunks mailing list people invited Vulis to come speak > > at one of their CA meetings. They even offered to pay for his airfare > > and lodging, but he was too afraid to show up. > > What a coward, just like Boursy and Grubor. > > > Hey you fucker; you pay my expenses and I will come. > > You get a one hour lecture and one hour of questions and > > answers afterward. Everybody gets frisked for guns at the door, > > since we do not trust some of those cypherpunks. > > Picture the typical cypherpunk (especially Sandfort, who organized the > whole thing): Old, out of shape, ignorant, lonely, perverted, ugly, > etc. etc. Dr. Vulis actually brightened up their "life" for a few > moments, then, when he didn't take the bait for the roast, they felt > rejected, like a love spurned. It's so transparent. It just wasn't worth the time. I found F2F contact with the likes of Hughes and Gilmore pretty boring and unproductive. But if Dr. Grubor wishes to address a Cypherpunks meating, and expose them as a bunch of homosexual censors, I think it would be a neat idea. --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

2 1

mailing list
by roamer.fau 17 Dec '03

17 Dec '03

Please place me on your mailing list. Thank You, Mark

1 0

I beg you, PLEASE prove that 0.123456789101112131415 is IRRATIONAL
by Secret Squirrel 17 Dec '03

17 Dec '03

Dear Cypher Punks, I BEG YOU TO HELP ME!!! Is it possible to prove that number 0.1234567891011121314151617181920... iz irrational? Or may be it is rational? Also, another question for math geniuses here: Is it REALLY true that there are real numbers that cannot be generated by any algorithm? Some guy said that since the set of algorithms is countable, but the set of real numbers is more than countable, there must be some numbers for which there is no algorithms that generate them. But I still do not believe him. Also, is it true that the sequence of digits in e is random because the ONLY way to get to the p'th digit is to calculate the p-1'st digits? Also, is it the correct definition of a real number: ``A real number is the class of numbers which can represent the length of an arbitrary line.'' I AM REAL DESPERATE FOR YOUR ASS ISTANCE.

2 1

microcurrency: Netscape vs. Microsoft
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

it seems that microcurrency has still not hit the "big time" yet. or perhaps some people see otherwise. what is the evidence for how far it has penetrated ala DigiCash etc? I haven't seen much myself. I predict that microcurrency will not catch on in a big way until it is integrated with browsers, and when it is, it will be adopted in an insanely large rush like the way the web itself caught on with the GUI (and was mostly comatose before it). I'd like to have seen microcurrency catch on like a brushfire at this point, and was trying to figure out why it hadn't, and focused on the above key aspect. hence, I wonder: WHO WILL BE THE FIRST TO INCORPORATE A MICROCURRENCY FEATURE IN THEIR BROWSER, MICROSOFT OR NETSCAPE? why am I shouting? because I hope that we can create a buzz around this question, to the point that both manufacturers begin to realize how much is at stake in this single little feature. I'd like to see speculation and articles about it in the trade press. let it turn into a hot topic of conversation.. do either MS or Netsacpe have plans to do so right now? I suspect the future of the browser wars will belong to he who does the microcurrency feature. here's how it might work: the browser has an internal piggyback that can be filled up with cash. it has various features that prohibit a charge of greater than some fixed limit of being made, per time, per site etc... also in no case can more money than is currently in the piggy bank be charged. once the charge hits, there is no contesting allowed, because the charge is so low. a little bar on the user interface could indicate how much cash is left. the idea would also be to invent some new html tags that indicate the charge on a link. the charge is incurred when 1/2 of the page is sent (there would be all kinds of hacks in which people could retrieve only part of a page to avoid the charge, hence this limit or some variation thereof). so when I move my mouse over a link in the browser, I see not only its address as with Netscape's, but also some charge that will incur when I hit it. there could be color coding and little graphics for costs also. notice how much crypto really caught on when Netscape incorporated it, and how this action alone did more for the proliferation of crypto in cyberspace, almost, than all prior efforts combined. I think that microcurrency will be unleashed in a very similar way. the system I describe above can be built up pretty easily from existing technology such as DigiCash. pretty much all the major ingredients are available.. it's just a matter of time before some enterprising programmers plug it all together in an easy to use way. (as far as I know the Digicash software is not easily integrated with any browser, am I correct?) by framing the question as I have above, the question is no longer "how should microcurrency be implemented", or "should it be", but "who will be the first to do it?", a nice competitive incentive to the key companies involved. so, Netscape, Microsoft, are either of you listening? do you have any idea how much is riding on this option? are you working on it right now? if not, are you prepared to face the consequences? has anyone heard any rumors about their intention to implement microcurrency? I've long predicted some pretty revolutionary strides in cyberspace that will make all development up to now look pretty sickly and pale, when microcurrency is invented and brought into a trivial-to-use GUI. in a sense it is the the economic system that the whole industry (or even the whole world) has been waiting for ever since its beginning. it will unleash a torrent of frenzied innovation and reorganization beyond what anyone has ever seen or thought possible. p.s. has anyone done a plugin that handles cash in the way I am referring to? this may be a really neat way for third-party developers to cash in on this, but I suspect that it's so crucial that the browser manufacturers will eventually incorporate it themselves.

3 3