December 2003 - cypherpunks-legacy

RSA Question
by charliemerritt＠BIX.com 17 Dec '03

17 Dec '03

an56238 on Jan 19: >what I was asking is the _list of possible values for d_. The list is all the numbers less than N that are relatively prime to ((p-1*(q-1)). These are all possible D's for N - the list is smaller for a given e. See below. >Any general formulas giving the probability of solutions for the d's ? The number of D's for a given N and E is gcd((p-1),(q-1)) Some messages can be spoofed with more D's but the gcd is the number of D's for all messages. The distribution of these D's is one every ( (p-1)*(q-1) )/ gcd ((p-1)*(q-1))

1 0

Re: Internet Banking
by mcb＠net.bio.net 17 Dec '03

17 Dec '03

(First of all, I just wanted to say hello, especially to those of you I met for the first time at the Cypherpunks BOF last night at Usenix.) I caught up on the digital banking thread and have a few thoughts about future banks, financial privacy, and nonregulation issues, especially how they relate to the way things are done now. What is important to me in an ideal bank, in roughly descending order: 1. Security. The bank will not disappear, steal my money, allow others to steal my money, or unwarrantedly cut off my access to it. 2. Convenience. I can easily and reliably spend the money I have on deposit, deposit funds from elsewhere, and communicate with the bank regarding my accounts. 3. Privacy. The bank will not (or, possibly, cannot) reveal details of my financial situation or transactions to others including the government. 4. Credit. The bank will loan me money for appropriate purposes if needed (and my credit rating is acceptable). The financial institutions I currently deal with do a pretty good job of all of these except (3), which is not their fault but is the government's. (Except for crud like banks that use trivial keys like your SSN for access to banking by phone.) No. 1, security, is a problem with anonymized, offshore, network banking. Today we rely on a combination of reputation and regulation to provide bank security -- the banks we deal with stress size, longevity, permanence, etc., in their marketing campaigns, and there are mandatory reserve requirements and mandatory deposit insurance. Reputation should translate pretty well in our idealized banking world -- what is better than the electronic word of mouth of the Internet? But in a nonregulated environment, there will have to be private deposit insurance which could easily have some bootstrap problems in building the initial market. Convenience, #2, should be a vast improvement. Freed from the necessity and cost of maintaining a network of impressive physical edifices of Federal-style architecture, and coupled with more-or-less ubiquitous networking and computing, banks can concentrate on giving ultra-fast, efficient transaction services via authenticated e-mail and customer services via a Web-like server. I envision transactions ending up in two big buckets: card services and "cheque" services. Cards are for when you are wandering around, and e-mail "cheques" are for paying regular bills. The card system, insecure at it is, is fast becoming universal; I stopped carrying a checkbook around years ago and use credit cards for all possible transactions: you get a comprehensive statement at the end of the month with the names of all your vendors, and you also get a nice premium for using their transaction services (mine is airline frequent-flyer miles). In any future banking system one must assume that card-based transaction service will be the main, if not only, means of casual transaction, and it will be up to us to to build in the ncessary privacy and authenticating schemes to make this a trustable system. I find it difficult to imagine large-scale displacement of institutions like VISA, MasterCard, and Amex, simply because they do what they do (provide instant POS credit authorization, guarantee merchants quick payment, etc.) very well. While e-mail "cheques" are attractive because the mail infrastructure is almost entirely there already, I wonder if they will ever become more than a small percentage of total transactions, possibly limited to pre-authorized direct drafts for such things as utility bills, and maybe mail orders and transactions between individuals. #3, privacy, is a very difficult issue because of the regulatory role of the government. Because of the degree to which strong financial privacy threatens government power (especially taxing power; see previous messages on this) I can easily imagine that (1) banks doing business in or "touching" the US and most politically similar sovereignties will not be able to prevent themselves from disclosing identity and transaction information about their customers, and (2) people will probably be prohibited from dealing with these banks if they are in fact beyond the reach of legal process. This leads to the key question: should one trust (i.e., disclose one's identity to) or not trust one's bank? It would certainly be nice to be able to trust your bank, as it makes things much easier for all parties. They would be able to freely grant you credit (#4 above), since you could verifiably prove your assets, real property, employment, etc. But if you trust your bank, then they may be forced to disclose your identity to the government under legal process. Thus it is probably best to postulate a banking system that does not require trust. This complicates #4, credit. I can envision a system of vouched-for indirection (not unlike signing PGP-keys) that would allow you (the borrower) to disclose assets/earning capacity to a trusted third party that would certify to a lender that you (known to the lender only as a numbered account) are credit-worthy. If it can be made possible to break the traceability link between the credit-vouching agency and the lender, privacy may be possible. One problem may be that credit-vouching agencies cannot easily be "offshore", since they may need to examine your real estate (or whatever) though this could be done, perhaps, by appraisers or other local agents. Comments? -- Michael C. Berch mcb(a)net.bio.net / mcb(a)postmodern.com / mcb(a)remarque.berkeley.edu

1 0

verilog decryptor
by an53004＠anon.penet.fi 17 Dec '03

17 Dec '03

A few months ago someone posted a verilog decryptor perl script to comp.lang.verilog. Does anyone have a copy? If so, would you send it to me. Thanks in advance ------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi.

1 0

Re: faster code for neural network
by Ron Davis 17 Dec '03

17 Dec '03

>> Recently I received the code for a neural network. It is written in >> standard ANSI-C. However, running it on the Mac gives me a lot of coffee >> breaks ( it takes 10 min on a IIci, 3 hrs on an LC ). I was wondering if >> anybody out there has experience with this and knows of ways to make the >> code faster ( replacing ANSI routines with Mac-based routines. >> >> If you are the woman or man with this experience mail me! I really need the >> help ( it's all for my master's thesis ). > >You might want to get a match coprocessor for the LC. The ci has one, >and that's probably your problem. (I'm not sure if the LC can take one, >though!) If my memory still works after the two pints I just had, the LC >has a 68020 without any FPU. You might want to upgrade to an LC III and >find out if it has an FPU. I believe neural nets use floats, no? If so >you will most certainly need and FPU if you want decent speed. > The LC does lack a FPU, but you can get one on a card. I'm not sure if this would help though, because it would depend if your compilier would generate FPU code. I know you can with Think. You also might need to take into account which compiler you are using for this kind of program, there seems to be a vairation in efficency between Mac Compilers. As for using toolbox calls, using Apple's SANE library might help. I haven't had much experience with it, but it would probably take advatage of the FPU. E-mail me if I can help anymore. (I'll run the program on my Q700 if you just need a quick speed test.) ___________________________________________________________________________ "I want to know God's thoughts...the rest are details." -- Albert Einstein _________________________________________ Ron Davis rondavis(a)datawatch.com Datawatch, Research Triangle Park, NC (919)549-0711

1 0

AI code speed up !!!!
by Scott Bence 17 Dec '03

17 Dec '03

> >> Recently I received the code for a neural network. It is written in > >> standard ANSI-C. However, running it on the Mac gives me a lot of coffee > >> breaks ( it takes 10 min on a IIci, 3 hrs on an LC ). I was wondering if > >> anybody out there has experience with this and knows of ways to make the > >> code faster ( replacing ANSI routines with Mac-based routines. > >You might want to get a match coprocessor for the LC. The ci has one, > >and that's probably your problem. (I'm not sure if the LC can take one, > >though!) If my memory still works after the two pints I just had, the LC > >has a 68020 without any FPU. You might want to upgrade to an LC III and > >find out if it has an FPU. I believe neural nets use floats, no? If so > >you will most certainly need and FPU if you want decent speed. > The LC does lack a FPU, but you can get one on a card. I'm not sure if > this would help though, because it would depend if your compilier would > generate FPU code. I know you can with Think. You also might need to take > into account which compiler you are using for this kind of program, there > seems to be a vairation in efficency between Mac Compilers. I have done a lot of optimization work on Mac and PC - Fractal generations & ray tracing both in C. 1.) Don't use SANE unless accuracy becomes a major issue. 2.) CHANGE ALL FLOATS TO DOUBLE!!!! Better speed & better accuracy!!!!! (MOST IMPORTANT due to Motorola design!) 3.) Think & MPW both can create FPU code as well '030 code. Use em. 4.) Fall back from system 7.x to newest 6.x with no multitasking. Then try to structure your object code size to fit in the cache of 680x0. 5.) Use register variables where needed. 6.) Don't re-code in assembler - the gain usually isn't worth it. 7.) If there is alot of screen updating - stop it until the final/desired result is achieved. 8.) Don't make System Task calls inside critical loops like Apple says to do, it slows down completion time, it will invalidate your code in the cache (see #4). There is alot more stuff but this should speed you up by a significant factor. 9.) Mac's are wonderfull but for number crunching '486/66 can smoke the mac due to 256k cache(secondary) and 8K cache (internal -Primary). Don't know your budget but the POWER PC looks sweet. I don't know when the compilers will opimize for this chip but look for mega mega mega increase in performance. > > As for using toolbox calls, using Apple's SANE library might help. I > > haven't had much experience with it, but it would probably take advatage of > > the FPU. Yup, but it's s...l...o....w....... Hope this helps. Write back and let me know. BENCE :-) #include <std_disclaimer.h> ---------------------------------------------------------------------- ------ Scott Bence * Texas State Technical College @ Waco, Texas ----- --- Computer Networking & Systems Administration * sbence(a)tstc.edu --- ----------------------------------------------------------------------

1 0

alternative to Fair Cryptosystems
by Carl Ellison 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I'm slow reading my cp mail and saw a reference to Micali's Fair Cryptosystems (what a name!). There is a simple alternative -- also to Clipper. You can have your surveillance agency (or agencies which need to cooperate) publish their own RSA keys (big ones, presumably), and all the good little boys and girls who want to prove how obedient and conformist they are can include those keys as recipients when they encrypt messages. If there are to be multiple agencies which have to cooperate, the PGP or RIPEM software would have to change to split the message key by XOR with ranno pieces, but in the meantime, you could just include the FBI in your list of recipients and save everybody the hassle of having to get pieces to put together. Simple -- direct -- speaks right to the gov't desire. What could be wrong with this? - Carl -----BEGIN PGP SIGNATURE----- Version: 2.4 iQCzAgUBLT6w6njfNbIrNWRxAQH7gQTvS3ZzwSMfzbE6XjWaHmNxVqPt7QPPGlqi pkMwF1IX/AyZ6VSOsETPGANwgMjk9NBDQNutNvpmZHnCm90smz+Z1q70/Pg5wY9F mY19U68G38qrYvv6YIAYTcW38O3vDpDnpqeltnrZ2yf7WR9ujfiEJZdPOdgkMJ7r KEqWTkvP36yxOBaZ0ozORDgZrnDJmHuRCWLYlWSiZsr5laI4NSo= =63Vw -----END PGP SIGNATURE-----

2 1

RSA: questions
by an56238＠anon.penet.fi 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Karl Lui Barrus writes: > >I believe if p and q are well chosen (p-1 and q-1 have large prime >factors, for example p = 2p'+1 and q=2q'+1 with p' and q' prime) then >only two values of d will work as the decryption exponent. This makes >guessing d as "easy" as guessing either p or q in the first place. > That was the answer I was lookin for. Any more maths available ? (formulas!, formulas!) My paranoia hates the ``I believe'' part. >For example: p = 11 (p' = 5), q = 23 (q' = 11), n = 253, phi(n) = 220 >I picked e = 7, gcd(e,n) = 1, solve for d = 63 >The message 20 encrypts to 20^7 mod 253 = 136 >I make a brute force search for d by raising C to all possible values >of d, from 1 to 253, looking for what decrypts to the original message. I did a brute force search too in my first example. However, this is the story of the snake biting its tail:if you choose p and q with the ``nice'' properties you describe, you then restrict yourself to a subset of all possible values of p and q, thus shrinking the key space search for the possible attacker. So, to completely answer the question, you need to figure out the distribution of prime number couples (p,q) that verify: p=2p'+1, p' prime q=2q'+1 q' prime, p'!=q' This way you'll be able to know how much you're shrinking key space. - -zap -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCUAgUBLT5QWCk+9PttYUp1AQFwHwP3T+DoLsQQf9C/LBWKv62AhGBxFIk/h1Zl HnCtDwuJvbAG10RJ1Hg4uetdvtqyo+T3vfeFzExsdEBnPljGTNptpnJF5CXqVjB/ lbPAmxrFPUjOnSU0NbJcxfU73QTwq5Ep2Nj3uQu1RAdi0JptZ2wjIGnngrlXqCwT RlLXRAMVAw== =XuUd -----END PGP SIGNATURE----- ------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi.

1 0

postmaster@lance.colostate.edu speaks
by Steve Dempsey 17 Dec '03

17 Dec '03

So far I have replied individually to complaints about the noise coming from L. Detweiler. My response has been, and continues to be, that he has the right to post in public any opinion he may construct. Some of you have begun to conclude that these postings constitute real threats and libel. I have been reluctant to get involved, but these claims of illegal activity force me to respond. Most of the complaints refer to a document recently posted to many public mailing lists via remailer services. This document apparently describes a fictitious contest or game called SQUISH. Individuals named in this document have written to me claiming that L. Detweiler <ld231782(a)lance.colostate.edu> is the author and is responsible for posting it. They also claim it is libelous and threatening. These folks are understandably offended at the references to themselves and to the invasive method of distribution. But the connection to Mr. Detweiler and to the systems I administer is indirect and assumed. I have spoken with Mr. Detwiler and he claims he did not post it. I have seen no evidence that he posted it. His name was not attached to the document in any copy I've seen. It was distributed by remailers that remove the source of the message. If you're going to claim libel, you better be able to prove the source. I've seen no proof; I have seen only finger-pointing. As to the substance of the document, it appears to be a joke. The reference to entry deadline of April 1 should tell you to check your sense of humor before taking it verbatim. As for the other references cited, including Usenet postings from anonymous addresses and mailing list articles delivered by anonymous remailers, I find it difficult to accept these at face value. It's possible that Mr. Detweiler composed these. It's equally possible that someone else did so. There are plenty of copycats on the net and they're not easy to separate or identify. I won't even try to sort out the anonymously posted or remailed data. And here's what you've all been waiting for: Regarding Mr. Detweiler's other activities on the usenet and other public lists, he concedes that his crusade of the past 2+ months has been less than productive. He has agreed to cease the postings that have yielded so few results other than inflammatory debate. I expect the noise to quiet. I expect to receive from users at large no further complaints of disruptive data coming from his account here. Finally, I will announce to everyone who wants to file additional complaints that I do not enjoy playing the part of net.policeman, nor net.complaint-dept; that really is not my job. Unless you can show some direct evidence that one of my users is harassing you or otherwise violating your rights, or breaking some law, I don't want to hear about it. Complaints about anonymous posts and remailed data should go to persons administering those services. ================================================================== Steve Dempsey Engineering Network Services steved(a)longs.lance.colostate.edu Colorado State University root(a)longs.lance.colostate.edu Fort Collins, CO 80523 postmaster(a)longs.lance.colostate.edu +1 303 491 0630 ==================================================================

2 1

Barriers to offshore banking
by m＠BlueRose.com 17 Dec '03

17 Dec '03

szabo(a)netcom.netcom.com (Nick Szabo) writes: >The middle class avoids current offshore banking because it >is user-hostile and puts their life savings at high risk. They may be user hostile, but they are not necessarily risky. And the middle class uses offshore banks a great deal. Offshore means any bank outside the US. Swiss banks are quite reliable, though they occasionally provide information to the US government and they withhold taxes on interest earned. Austrian banks are just as reliable and offer not just numbered accounts, but password protected, numbered accounts, and do not tax interest earned. There are many other places with reliable banks that will protect one's privacy. The Channel Islands have a system of government that dates to 1066, numbered bank accounts, and the largest bank on the Islands is the tenth largest bank in the world. >An offshore bank often takes a week or more to service requests for >statements sent by snail-mail. That's why most people use faxes to communicate with offshore banks. I would be surprised if email didn't follow soon. >Offshore banks are notorious for obsconding with customers' money. In a few jurisdictions, this is true. For example all that is required to set up a bank in Grenada is to form a corporation with the word "Bank" in the name. That's it! No regulations at all. Most jurisdictions in which offshore banking take place regulate several different types of banks. Class A banks are the type one finds in the US, with tellers, etc. Class B banks are typically run by a company which sets up the bank and are almost always prohibited from doing any business with the local residents. Class B banks are usually divided into restricted and unrestricted. An unrestricted bank can do business with anyone not a resident of the country in which the bank exists, while a restricted bank can do business only with parties named at the time the bank is formed. Reserve and capitalization requirement vary from country to country but unrestricted banks must nearly always meet tougher requirements than restricted banks, and Class A banks must meet tougher requirements than Class B banks. For example, in the Bahamas, a restricted Class B bank must have a minimum capitalization of $100,000 and pay an annual license fee of $5000. For an unrestricted Class B bank, it is $1,000,000 and $25,000 respectively. I don't have figures available for a Class A bank but they are much higher and the Class A bank would be subject to regulation. >Reputation information on these banks is hard to find to >nonexistant. It's not that hard to find. Many offshore banks are more than 100 years old. >The typical offshore bank customer spends $1,000's on legal fees to >obtain information on reputable banks, the legality of what they are >doing in both the local and offshore jurisdictions, and to set up >obscure, sophisticated legal entities. True but misleading. The typical offshore bank customer spends about $1000 to $2000 to set up a corporation, so that the bank acount is not in his own name. This obviates the requirement to tell the IRS when an American opens a bank account in a foreign country. >There aren't any good statistics, but I'd guess that most of the >money saved by going offshore is lost to legal fees and fraud. If that were true, there wouldn't be offshore banks. The tax savings probably outweigh the legal fees by 10 to 1 or more in most cases, and fraud exists, but is not so rapant that people stay away. M Carling

1 0

Re: Internet Banking
by Matthew Bernardini 17 Dec '03

17 Dec '03

> (First of all, I just wanted to say hello, especially to those of you I > met for the first time at the Cypherpunks BOF last night at Usenix.) > > I caught up on the digital banking thread and have a few thoughts > about future banks, financial privacy, and nonregulation issues, > especially how they relate to the way things are done now. > > What is important to me in an ideal bank, in roughly descending order: > > 1. Security. The bank will not disappear, steal my money, allow others > to steal my money, or unwarrantedly cut off my access to it. > > 2. Convenience. I can easily and reliably spend the money I have on deposit, > deposit funds from elsewhere, and communicate with the bank regarding > my accounts. > > 3. Privacy. The bank will not (or, possibly, cannot) reveal details > of my financial situation or transactions to others including the > government. > > 4. Credit. The bank will loan me money for appropriate purposes if > needed (and my credit rating is acceptable). > > The financial institutions I currently deal with do a pretty good job > of all of these except (3), which is not their fault but is the > government's. (Except for crud like banks that use trivial keys like > your SSN for access to banking by phone.) > > No. 1, security, is a problem with anonymized, offshore, network > banking. Today we rely on a combination of reputation and regulation > to provide bank security -- the banks we deal with stress size, > longevity, permanence, etc., in their marketing campaigns, and there > are mandatory reserve requirements and mandatory deposit insurance. > Reputation should translate pretty well in our idealized banking world > -- what is better than the electronic word of mouth of the Internet? > But in a nonregulated environment, there will have to be private > deposit insurance which could easily have some bootstrap problems in > building the initial market. > > Convenience, #2, should be a vast improvement. Freed from the > necessity and cost of maintaining a network of impressive physical > edifices of Federal-style architecture, and coupled with more-or-less > ubiquitous networking and computing, banks can concentrate on giving > ultra-fast, efficient transaction services via authenticated e-mail > and customer services via a Web-like server. > > I envision transactions ending up in two big buckets: card services > and "cheque" services. Cards are for when you are wandering around, > and e-mail "cheques" are for paying regular bills. The card system, > insecure at it is, is fast becoming universal; I stopped carrying a > checkbook around years ago and use credit cards for all possible > transactions: you get a comprehensive statement at the end of the month with > the names of all your vendors, and you also get a nice premium for > using their transaction services (mine is airline frequent-flyer miles). > In any future banking system one must assume that card-based > transaction service will be the main, if not only, means of > casual transaction, and it will be up to us to to build in the > ncessary privacy and authenticating schemes to make this a trustable > system. I find it difficult to imagine large-scale displacement of > institutions like VISA, MasterCard, and Amex, simply because they do > what they do (provide instant POS credit authorization, guarantee > merchants quick payment, etc.) very well. > > While e-mail "cheques" are attractive because the mail infrastructure > is almost entirely there already, I wonder if they will ever become more > than a small percentage of total transactions, possibly limited to > pre-authorized direct drafts for such things as utility bills, and > maybe mail orders and transactions between individuals. > > #3, privacy, is a very difficult issue because of the regulatory role > of the government. Because of the degree to which strong financial > privacy threatens government power (especially taxing power; see > previous messages on this) I can easily imagine that (1) banks doing > business in or "touching" the US and most politically similar > sovereignties will not be able to prevent themselves from disclosing > identity and transaction information about their customers, and (2) > people will probably be prohibited from dealing with these banks if > they are in fact beyond the reach of legal process. > > This leads to the key question: should one trust (i.e., disclose > one's identity to) or not trust one's bank? It would certainly be nice > to be able to trust your bank, as it makes things much easier for all > parties. They would be able to freely grant you credit (#4 above), > since you could verifiably prove your assets, real property, > employment, etc. But if you trust your bank, then they may be forced > to disclose your identity to the government under legal process. Thus > it is probably best to postulate a banking system that does not > require trust. > > This complicates #4, credit. I can envision a system of vouched-for > indirection (not unlike signing PGP-keys) that would allow you (the > borrower) to disclose assets/earning capacity to a trusted third party > that would certify to a lender that you (known to the lender only as a > numbered account) are credit-worthy. If it can be made possible > to break the traceability link between the credit-vouching agency and > the lender, privacy may be possible. One problem may be that > credit-vouching agencies cannot easily be "offshore", since they may > need to examine your real estate (or whatever) though this could be > done, perhaps, by appraisers or other local agents. > > Comments? > > -- > Michael C. Berch > mcb(a)net.bio.net / mcb(a)postmodern.com / mcb(a)remarque.berkeley.edu > > I am new to this list, so excuse me if this topic has already been discussed, but I think you need to take a 200 level course in economics called Money and Banking. I think the idea is so obsessed with tax-evasion and privacy protection that you have ignored all the economic consequences of the ideas you are proposing. 1) Who will insure your money ? Can you trust anyone but the US gov't to back your funds ? Even in the S&L scandal the gov't refunded money to people that weren't insured by the FDIC. Do you think they would come to the cypher-punk rescue if your money up and flew to Brazil ? 2) A doctoral thesis could be written about this one, but what about the Federal Reserve ? You would wreak havoc on interest rates, inflation, international balance of payments, and international trade. How would this electronic bank adjust for inflation or an expanding/shrinking electronic money supply ? Take a look at some historical texts that describe the problems that the Early American Revolutionaries had in breaking from the British Currency. It took several failed efforts, and the currency of the United States has been constatnly evolving ever since. 3) Interest Rates and Inflation ... 4) Interest Rates and Inflation .... 5) You guessed it, Interest Rates and Inflation. What about Capital Markets ? What about foreign labor unit exchanges? Is mexican labor worth as much as US labor? I think there are more economic issues than encryption issues to be considered in this case. Matt ----------------------------------------------------------------------------- | Rutgers University Computing Services Matthew Bernardini | Hill Micro/Graphics Center 7804 McCormick | Site-Manager (908) 878-0946 | 017 Hill Center | (908) 932-3129 (908) 932-4921 -----------------------------------------------------------------------------

2 1