- cypherpunks-legacy - lists.cpunks.org

SAIC Offers SET
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

SAIC Is @Yourservice for Secure Electronic Transactions on the Internet San Diego, 29 Feb 1996 -- Science Applications International Corp. (SAIC), a leading provider of information and network security services, today announced that it will offer a wide range of business solutions based on the new Secure Electronic Transactions (SET) standard for safeguarding bankcard purchases over the Internet. Through its @Yourservice business unit, SAIC will provide consulting, integration and digital certification services to financial institutions, network operators and merchants doing business over open networks. SAIC helped Visa and Microsoft in their pioneering effort to bring security to on-line commerce, and played a major role in crafting the SET standard, working for Visa and in close association with MasterCard and other SET technology partners. SAIC has long been one of the largest and most trusted suppliers of information, network and data security solutions in the world, as well as being a major information systems integrator for government and commercial clients. "We're bringing these skills, and our understanding of SET complexities such as digital signatures, public key cryptography, certificate management and network protocols together to help businesses transition smoothly into the world of electronic commerce," said Nick DiGiacomo, who oversees @Yourservice. "What we offer is seamless integration from the cardholder's computer over the networks to the merchants and banks, and back again. We're here to make this easy." --

1 0

Re: PGP to PC mail integration
by tomservo＠access.digex.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- An entity known as "E. ALLEN SMITH" <EALLENSMITH(a)ocelot.Rutgers.EDU> writes: > You'd put something into the mail message itself that would tell it >"don't encrypt this" and/or "don't sign this". Hmm... you'd need to put in >messages to be signed and/or encrypted your passphrase, or have it gotten some >other way... which doesn't look very safe. exmh on Unix systems goes the other way. It adds a header line that includes the sender and recipient, plus the action to be performed ("encrypt," "sign" or "encryptsign"). No header, no encryption/signature. I'm reasonably sure it strips off that line before it passes the message off to sendmail -- but I usually don't send messages to myself that way. :- ) For incoming mail, it looks for standard PGP structure and figures out what it needs from the user. If, for instance, you don't have a public key on your keyring, it allows you to send a mail message to a server to grab it - - - otherwise it performs the operation and shows you the results. If what you're doing requires a password (signing or decrypting), it pops up a window to ask you for it. When it's done, it prompts you to press Return and disappears. It was written in tcl/Tk, but some of it may be applicable for what you want to do. (Sorry, I'm not an expert on either.) Scott -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBMTZk4evEnOI8TfM9AQGiKwL6A+XCKH68tfqJNE6cDRR7KClbXuSchBF3 UW6lY5ZzQIkZSTEKLm6EK2uEg6h9wafO38Dzm61PAdLZ0te67Kqtb4V4seTW4k4M +YBLuUAiutVgZayj2OdrWjvlc43M495w =GrDt -----END PGP SIGNATURE-----

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

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

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

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

17 Dec '03

I think we are in violent agreement here... > 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. Perhaps you misunderstood what I mean by "central keyserver model". What I mean by that is the status quo, where we have a set of central keyservers and each keyserver knows about each key. When I say that this will disappear, I mean that we will move towards a more distributed system, similar to the DNS for looking up hostnames. Yes, we will need a distributed, hierarchial [sic] system in the future, and if we want to continue using PGP we will need to provide a simpler way to use that. > 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. This is true. > 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). I disagree. I know the addresses of the people with whom I communicate regularly. I know my parent's USnail address, my grandparents', my SO's, etc. I dont need to tell the Post Office "Send this to my parents" and trust them to do it. I give them a destination address and trust them to send it to the proper destination. The same thing is true in the electronic world. I put a destination on the email, give it to the mailer, and trust it to send it to the appropriate destination. A similar anology can be made when I dont know an address: I ask someone for it. Same thing with an email address/PGP key, I need to ask for it before I can use it. The same thing is true of hostnames. I can find a hostname<->IP address for just about any host on the planet. Do I have them all on my local disk? No, of course not. I look them up when I need them. However, I do cache local copies of the names I frequently use. > 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. Yes, this is true. And it is used -- its called regional phone books. If I want to get a number for someone, I go to the regional phone book and look them up. I have to know something about them first, so I know where to look. If I asked you to find the machine "incommunicado" and tell me it's IP address, what would you do? You'd have to look in every domain for machines named "incommunicado". However, if you knew that I meant "in the 'ihtfp.org' domain", you'd know exactly where to look. The same is true of phone numbers. The same is true for keys. > 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. True. The problem is that with PGP messages, the only information about keys is a "random" keyID. From a keyID there is no way to determine that key unless you already have it. This means that if you do not already have the key, you have no way to find that key. See the problem? This is like the "find 'incommunicado'" problem above. What I propose is to modify, slightly, the PGP signature certificate to add a "hint" field. This hint field would tell you where to look for the key. This is the way to add the "ihtfp.org" info to the PGP signature. I hope this clears up any misconceptions... -derek

1 0

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

17 Dec '03

Where can I find it? Please send ftp or URL via private E-Mail. (define(RSA m e n)(list->string(u(r(s(string->list m))e n))))(define(u a)(if(> a 0)(cons(integer->char(modulo a 256))(u(quotient a 256)))'()))(define(s a)(if (null? a)0(+(char->integer(car a))(* 256(s(cdr a))))))(define(r a x n)(cond((= 0 x)1)((even? x)(modulo(expt(r a(/ x 2)n)2)n))(#t(modulo(* a(r a(1- x)n))n))))

1 0

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

17 Dec '03

Here is your friendly reminder of the Austin Cypherpunks meeting tomorrow, Saturday the 2nd. We'll meet at the Central Market Cafe at 38th and Lamar at 6PM. Topics include the video (I'll have a camera!), ITAR relaxation, RC4 now being called PC1, how to duck the CDA using crypto, hardware random number generators, and stuff like that. The meeting should go around 2 hours depending on the crowd, and there is a Bookstop next door if you want to browse some reading material later. Look for the people with technical books and/or crypto-related shirts. They will be us. (I'm sending this to both austin-cpunks and cypherpunks.) -- Ben Combee, CAD Software Developer, small language enthusiast, HTML dude Motorola, Paging Products Group, Strategic Semiconductor Operation--Austin E-mail: combee(a)sso-austin.sps.mot.com Phone: (512) 891-7141

1 0

Re: PGP to PC mail integration
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: lmccarth(a)cs.umass.edu >Mike Ingle writes: >> Instead of messing with user interfaces, you set the POP and SMTP >> addresses of your mail program to "localhost". You run locally a Visual >> Basic program that sits on ports 110 (POP) and 25 (SMTP) listening for >> connections. The VB program is configured with the addresses of your >> real SMTP and POP servers, and acts as a proxy. > >> When your mail program retrieves POP mail, it goes through the VB >> program, and the VB program decrypts any PGP mail it sees. When it >> sends mail, the VB program encrypts any mail it has a PGP key for the >> recipient of. >Would you be stuck if you wanted to send something unsigned and/or >unencrypted ? You'd put something into the mail message itself that would tell it "don't encrypt this" and/or "don't sign this". Hmm... you'd need to put in messages to be signed and/or encrypted your passphrase, or have it gotten some other way... which doesn't look very safe. Of course, if you're just encrypting it to the person's public key off of your keyring, and for stuff that's coming in encrypted to someone else's private key or signed with someone else's private key on your keyring, that wouldn't be so much of a problem. For the stuff coming in with the verification message (could be spoofed), looking for such strings already in an incoming message would be good. An attacker could still potentially slip something in between the mail program and the proxy program, though - the same problem as with the passphrase in the message. -Allen

2 1