December 2003 - cypherpunks-legacy

Problems with certificates.
by A. Padgett Peterson P.E. Information Security 17 Dec '03

17 Dec '03

I suspect the real danger would come from issuance of duplicate certificates. MasterCard conrols MarterCard numbers by issuing all of them (and I suspect that there is coding to separate MC from Visa from AmEx). Today, each person generates their own PGP key. While it is unlikely that any two will match, it is likely that at some point some two will match (see matching birthdays in a bar - number is less than you would think). Next rage might well be "vanity" PGP keys. While at the moment it is not known how to create a specific match key to a sequence, if you generate enough keys, there will be some interesting sequences found. Possibly some PGP signatures will even be in violation of the CDA (now that should start a rush 8*). For some time I have been concerned about the scalability of PGP. It works well in small groups but after trying once to create a 6,000 member keyring (took over three days on a 386 & was several meg when done) I decided that areas were going to need work to be a real anyone/anywhere/anytime mechanism. Not saying I have a good answer, just that at some point there will be a problem. Warmly, Padgett

2 1

Re: a brief comparison of e-mail encryption protocols
by A. Padgett Peterson P.E. Information Security 17 Dec '03

17 Dec '03

Derek rites: >Oh, of course the central keyserver model would disappear, but I'm >still trying to design a system which is as compact as possible. I disagree but then my worldview is different. For personal use the compact distributed system is workable however when you start thinking in terms of a large distributed organization, the quanta changes. Mention was made of the difficulty of handling 20,000 keys. I am looking at over 80,000 today and over 200,000 tomorrow *for a single organization*. For quantities like this, a hierarchial system of management seems inevitable. First, I am not about to give up my personal PGP key, it is trustworthy and effective for my needs. It is not necessarily incompatable with an organizational structure. However *for the organization* something else is needed. I can see a future in which the bulk of the population has only two keys: their own and the punlic key of their post office (not talking USNail - private ones though not saying the US might not operate one as well). Messages are composed with addressing and encrypted with the PO key. PO decrypts message key (NOT necessarily message but that will have to rely on trust - nothing will stop double wrapping anyway), checks address list, retrieves key for each adressee, adds header & sends copy (may use single mailing for group at distant post office but that is getting ahead). If recipient key is not found, adressee wil be removed from list and notice sent back to originator. If plaintext is desired, special operation will be required. As noted, a hierarchal mechanism will be needed for key retrieval - only local keys and "frequent fliers" will be kept locally. Not new concept, just not used by post offices that I know of today. Will need a bit of fleshing out and expect the end-state to be 2-4 years out but is a good time to think about it. Warmly, Padgett

2 1

No Subject
by owner-cypherpunks＠toad.com 17 Dec '03

17 Dec '03

John Pettitt writes:: # The SET transaction spec is now available on www.visa.com (and presumably on # www.mastercard.com although I didn't check). Norman Hardy writes: > I am unable to find the specs. Anyone have an URL? http://www.mastercard.com still works for me. I haven't looked at the Visa site in a few days. -Lewis

1 0

No Subject
by owner-cypherpunks＠toad.com 17 Dec '03

17 Dec '03

At 1:17 PM 2/29/96, Housley, Russ wrote: >Jim, in what way does the end user distinguish between the MOSS-like >integration and the S/MIME-and-MSP-like integration? It seems to me that a >good user agent implementation provides the same services to the user. Russ, since you weren't present at the workshop I'll repeat the very first words I said in the presentation I gave there. Functionally, from a user's perspective, there is for all practical purposes no difference between any of these technologies. Today I would add that we could pick one out of hat and just move on. However, there are differences in the technologies. Some are easier to implement, some are more flexible, some perform better, and the list goes on. We need to explore those differences to develop a criteria for evaluating the technologies so we can provide the best possible solution to the user community. I proposed one possible criteria in my presentation, by no means the only one and by no means complete. Jim ---------------------------------------------------------------------------- James M. Galvin galvin(a)eit.com VeriFone/EIT, PO Box 220, Glenwood, MD 21738 +1 410.795.6882

1 0

No Subject
by owner-cypherpunks＠toad.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 07:20 PM 2/29/96 -5300, Adam Shostack wrote: >key://ftp.clark.net/pub/u/cme/cme-current.asc >key://ftp.clark.net/pub/u/cme/cme-longterm.asc Just as a head up on not duplicating work with regards to incorporating URL's into key certificates and DBs you might want to consider URI's, URC's or URN's as the piece to bind since URL's are considered to be almost as unstable as email.. Check out for more on these naming schemes. Linkname: WRL: Web: URXs URL: http://webreference.com/urx.html -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: cp850 iQCVAwUBMTcfaP0Ael7bLK1/AQG56QQAxr+Tii4UMytdQUXIrKzIp2ckY4UfbGqW BpkduSxha0lL8Mo2kmzOL4Z3s4NiJMExvzUKOo6Y16MuCXhKgJyxH5VN+Nk1Y/ov qNpm4zaFOiAFQTbjMhSWJgFGmm6uaHuOez5jZDpSCpZTSBbXUwR349lxXjEtuvy8 hm+w0ADr/VQ= =SYWa -----END PGP SIGNATURE----- _______________________ Regards, There is no point at which you can say, 'Well, I'm successful now. I might as well take a nap.' -Carrie Fisher Joseph Reagle http://farnsworth.mit.edu/~reagle/home.html reagle(a)mit.edu 0C 69 D4 E8 F2 70 24 33 B4 5E 5E EC 35 E6 FB 88

1 0

No Subject
by owner-cypherpunks＠toad.com 17 Dec '03

17 Dec '03

Jonathon Fletcher writes: > Can anyone tell me anything about a product called "Entrust", by Nortel > (Northern Telecom). The notes talk about the software using DES ("which > employs a 56-bit key") so I guess it's single DES, not triple DES. It also > mentions a proprietary algorithm called CAST. > > Is this worthy of further investigation, or is it suspect ? What is > CAST, and would it be classed as snake oil ? I asked one of the NorTel sales reps. about this at the RSA conference. As I recall, CAST is an espionage-enabled version of DES -- i.e. 16 of the key bits are sent in the clear, or have a fixed value, or something along those lines. The guy I spoke to didn't know the technical details. Of course, maybe we should consider 56-bit DES espionage-enabled at this point too ! > Please cc to me in mail (done) -Lewis

1 0

No Subject
by owner-cypherpunks＠toad.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- PADGETT(a)hobbes.orl.mmc.com wrote: > Next rage might well be "vanity" PGP keys. While at the moment it is not known > how to create a specific match key to a sequence, if you generate enough > keys, there will be some interesting sequences found. Possibly some PGP > signatures will even be in violation of the CDA (now that should start a > rush 8*). Funny you should mention that, I noticed a strange message in my key the other day ... Type bits/keyID Date User ID pub 1024/C001D00D 1996/01/22 Gary Howland <gary(a)kampai.euronet.nl> -----BEGIN PGP PUBLIC KEY BLOCK----- mQDKAjED/fgD6AEEANi8U98UJ/Wm3rxiZuPrkvLmOifV8y68MgdRnQQtQDsoGa0L OWjoH8yLTVEi8dKeU52Bdr0p+M2TaW8Z+0phW43P9mBaM2sw42vq1FyBxv0EjtEn 8VbN6i7SC1+Xp4GsX9I8ctlN4y59gEcOFSHFCJjw9heRlM8Cq9M+30vAAdANAekB livXDe0T+PGPesUeMedaMliveDehT+PGPesUeMedaMliveDehT+PGPesUeMedaMl iveDehT+PGPes6eMA7QlR2FyeSBIb3dsYW5kIDxnYXJ5QGthbXBhaS5ldXJvbmV0 Lm5sPokBFQIFEDED/i7oDjFwD/HBoQEB3K4H/icZoG0lE5pitriLdqqwNZB0kZiT yEnvhg1NqOZwCusHqzMV71S+vDfYYSrl7VjmCVaEOgPAT3kpc7ShXsWpFa4y9pXF AjBgR/9crcH98cbrIlGMArKKNiGITGq8tpKvAowyIaG6gn1W7XZRFd0hISrI1C3y j13JUFWyYLjNuA/tPiIfZ2h/HUu4LgFr2WhFn4/l3IVcGVLeCLK6Gv4dxd8HEt2d mGn7WAygarf7PQevHLIoxElwJkIea6necbgYx5p2GOUNW3/N478n3n6TT1jpu1pU RUGYRd5cGYc7z6gXb15FZw0z3uh4ybTEP4pOflBjBPJm27RcEYtuZxSuKQg= =Liso -----END PGP PUBLIC KEY BLOCK----- - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMTcqiyoZzwIn1bdtAQHwaQF/ZBY9JZ6e6dgXjAORuRLQSbRY2JuZHGbN 1a69D0NwvRBdrB4iIjWCdwBQuhXXCd+K =8nI2 -----END PGP SIGNATURE-----

1 0

No Subject
by owner-cypherpunks＠toad.com 17 Dec '03

17 Dec '03

I have to thank everyone who helped me with using cypherpunk remailers! Thank you very much.. I've got very much response on this so I have to thank you all in this message! Johan Sandberg

1 0

No Subject
by owner-cypherpunks＠toad.com 17 Dec '03

17 Dec '03

Mail*Link(r) SMTP FWD> ADMIRAL WILLIAM O. STUDEMAN Gee I guess we can trust these guys.... ---- CONCORD, Calif., Feb. 28 /PRNewswire/ -- Premenos Technology Corp. (Nasdaq: PRMO), a leading provider of electronic data interchange (EDI) software solutions for electronic commerce applications, today announced the election of Admiral William O. Studeman, U.S. Navy-retired, to its Board of Directors effective immediately. Studeman will also act as consultant on special projects including security and encryption issues. Admiral Studeman, age 56, is the former Deputy Director of Central Intelligence and served for five months in 1995 as the acting Director of Central Intelligence. He retired from the Navy in October 1995. Prior to his assignment at the Central Intelligence Agency (CIA), Studeman was the Director of the National Security Agency (NSA), and before that was the Director of Naval Intelligence. In these positions, Studeman was involved in attempting to develop public policies and technologies that addressed the complex and often conflicting issues of enhanced economic competitiveness, law enforcement's warranted requirement for information transparency in pursuit of criminal investigations, national security interest in combating potential information warfare threats, and the country's overall increased need for enhanced protection of its information-related systems and applications. In commenting on his election to the Board of Premenos, Studeman stated that "Premenos is not only a leader in facilitating the promising future of electronic commerce, it is the first company in the marketplace with a product line for enhanced protection, security and integrity for the Internet and other electronic communications-related business transactions." Studeman added, "In working with Lew Jenkins and others in the company, I have an opportunity to better frame the government-industry dialogue and define the infrastructure, standards, regulatory, technical and other directional factors which must be addressed for electronic commerce -- a rapidly evolving industry segment so fundamental to the future of the American lifestyle and national security." Lew Jenkins, chairman and founder of Premenos said, "The infrastructure for moving critical business data over the Internet is crucial to the success of electronic commerce. We welcome Admiral Studeman to our team and look forward to his help in developing a trusted model for the electronic commerce market and establishing a solid infrastructure similar to the stringent military requirements that have been in place for decades." About Premenos Corp. Premenos is setting the agenda for electronic commerce and EDI through open networks such as the Internet. Premenos EDI software is an enabling strategy for transforming how corporations conduct business in extended enterprises using electronic communications. Templar -- a suite of software and services that enable businesses to send and receive EDI documents securely and reliably over the Internet -- was awarded the EMA '95 Electronic Commerce Product Excellence Award recognizing the most innovative new product debuted at EMA's annual conference. Premenos products support the IBM AS/400, RISC System/6000, HP 9000, SunSparc, Windows 3.x, NT and Windows 95. Premenos has a worldwide presence with sales offices in California, London and Paris. Contact Premenos World Wide Web (WWW) home page at http://www.premenos.com to access over 3000 pages of information on electronic commerce, EDI, standards, as well as Premenos corporate information materials. NOTE: Premenos is a registered trademark of Premenos Corp. All other product and company names are trademarks of their respective corporations. CO: Premenos Technology Corp. ST: California IN: CPR SU: PER

1 0

No Subject
by owner-cypherpunks＠toad.com 17 Dec '03

17 Dec '03

The database size is really only half the problem I think. The bigger problem is managing the database. I can't quite see it being possible to have one organization serve as a distribution point for all keys. With millions of billions of certs, you're going to have having thousands or millions of database updates on a daily basis. It does seem though that if you can truly eliminate revocations then things get a lot easier. You never have to go back a check with the issuer about anything. This will probably work for some applications, but there's certainly others for which it won't. LL At 2:21 PM 2/29/96, Carl Ellison wrote: >At 12:01 2/29/96, Laurence Lundblade wrote: >>I think a problem occurs when you have 20 billion of >>these certs (two for every person in the year 2010 or such). A simple hash >>into a table isn't going to cut it because you a single database (with >>replication?) isn't going to be possible. > >BTW, at the rate that memory gets cheaper and smaller, it might be quite >reasonable to have that single database fit alongside your daily appointments >in your shirt-pocket daily organizer and e-mail terminal, in 2010. > > >+--------------------------------------------------------------------------+ >|Carl M. Ellison cme(a)cybercash.com http://www.clark.net/pub/cme | >|CyberCash, Inc., Suite 430 http://www.cybercash.com/ | >|2100 Reston Parkway PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 | >|Reston, VA 22091 Tel: (703) 620-4200 | >+--------------------------------------------------------------------------+

1 0