RSA touts DIY certificates
http://www.theregus.com/content/55/25329.html 21 June 2002 Updated: 06:57 EST The Register The Register USA RSA touts DIY certificates By ComputerWire Posted: 06/21/2002 at 06:42 EST ComputerWire: IT Industry Intelligence A new option for web authentication from RSA Security Inc will let businesses manage their own SSL (Secure Socket ayer) digital certificates, instead of having to rely on certificate authority service providers who charge an annual fee per certificate. The need to reliably authenticate Web servers to visiting browsers, calls for trusted certificates to complete the certificate validation process in a way that is transparent to the end-user. In the same way that a business will want to verify the identity of an individual wanting to make a commercial web site transaction, visitors to web sites want to see a level of trust. By reliably authenticating Web servers to visiting browsers, SSL server certificates help build that trust. With RSA's Keon Web Server SSL, customers' Web server certificates generated and issued by their RSA Keon Certificate Authority (CA) software are designed to be automatically validated and trusted by popular Web browsers, email packages or other secure applications. The product is targeted for use anywhere there is a need for web authentication, to support a move to digital signatures, or to improve the level of secure access to corporate email or virtual private network (VPN) systems. The Bedford, Massachusetts-based security vendor claims its option is a cheaper alternative to a service-based approach to CA-based server authentication. It is a move no doubt intended to chip away at the managed certificate business of RSA rival, Verisign Inc. The RSA Keon Web Server SSL offering is intended to take care of all aspects surrounding the issuing, management and validation of SSL server certificates, using 128-bit encryption between browsers and servers. It also includes various root signing services to accredit a businesses' certificate authority to RSA's own recognized trust hierarchy. -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Secure mail relays [was:RE: DOJ proposes US data-rentention law. ]
John wrote quoting Lucky: Locate the button in your MUA that's labeled Use secure connection or something to that effect, search the docs for your MTA for the words STARTTLS, relaying, and potentially SASL, don't use your ISP's smtp server, encourage those that you are communicating with to do the same, and the email data retention laws will be of no bother to you. However, your ISP will cut you off for spamming, by which they mean sending emails toward their destination without going via the ISP's wiretap point, I mean mail relay machine. All you anti-spam bastards wanted ways to control what people are allowed to send you, regardless of the cost in broken protocols, savaged freedoms, and user inconvenience. OK, now you have a bunch of controls, stop whining when they are used to control YOU! (Of course, the spam hasn't stopped coming in anyway, so you get the worst of both worlds.) I share John's dislike for the (thoroughly ineffective, except in making the lives of legitimate users more difficult) anti-spam zealots and anybody else upstream from me that deems it necessary or even acceptable to do anything other than to forward raw IP packets addressed to my IP address unmodified. In fact, I cautioned various anti-spam activists back around 1994/95 where their objectives would lead, but it was to no avail. An experience that John is undoubtedly familiar with. Nonetheless, I would not run an open relay today simply due to the fact that I want the postmaster alias to remain useful for submitting reports of actual mail sub-system problems on my system. And, yes, because I would loath to see cypherpunks.to's very pleasing 100Mbps upstream connection cut. Fortunately, what I am suggesting can be accomplished without running an open relay on port 25, which /will/ cause you pain. I am limiting relaying on port 25 smtp to authorized users by using Cyrus-SASL, which integrates cleanly with postfix + TLS as the MTA. Since Outlook only provides the plaintext variant of SASL authentication, my MTA is configured to not offer smtp AUTH as an option until after the TLS connection has been established to prevent eavesdroppers from capturing the relaying authentication password. Since more and more misguided ISP's are flat out blocking outgoing connections to port 25 from inside their network, I have postfix listening at a higher port number in addition to port 25, just as many hosts today are running sshd on several ports to help compensate for similarly misguided corporate firewall policies. One probably could get away without using SASL just by running the smtpd on a non-standard port, since AFAIK spammers only try port 25, at least at the moment, but enabling SASL was so easy with postfix that I saw little reason not to do so. Besides, it was the more esthetically pleasing solution. John (off the Internet for months now, getting email via uucp, since Verio cut off my T1 for running an open relay, i.e. a box that would accept email like what Lucky proposes) UUCP, eh? Well, having just watched my ISP's primary upstream provider essentially melt down and the replacement likely to do so soon, I had myself briefly considered retrieving my old UUCP books from storage just in case the need should suddenly arise. :-) Hmm, I wonder where one gets an UUCP link nowadays. Guess I should take a look at the current maps. (The following offer is specifically for John: let me know if you'd like a relay and I'll gladly give you an UID/PW for my not-quite-open mail relay. I have little doubt that any and all traffic in and out of that particular machine has been logged since it first came online 7 years ago. I don't care, since any significant traffic is encrypted. YMMV. Oh, and yes, cypherpunks.to of course supports IPSec under both IPv4 and IPv6 in addition to higher-level encryption protocols such as smtp's STARTTLS). --Lucky strong crypto sure has become amazingly inexpensive and easy to use Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Recommended key sizes and lifespans
I have been reading a draft of, Key Management Guideline, from NIST describing key management requirements for non-classified, but confidential government information. When complete, it is expected to become a FIPS. While the guidence in it is subject to change, I found the recommendations for key sizes and lifetimes interesting. They define equivalent strength of algorithms in terms of a symetric algorithm with no known attacks better than brute force. DES is 56 bits, Triple DES (with three different keys) (TDES) is 112 bits, AES is 128, 192 or 256 bits. Secure hashes are defined as having a strength equal to half the bit-length of their output. So SHA1 is 80 bits, SHA-256 is 128 bits, etc. for SHA-384 and SHA-512. Algorithms based on the descrete log problem on integer fields (DSA, Diffie Hellman, MQV) are based on the size of the modulus and the size of the private key. The equivalents are: modulus private symetric keyequilavent 1024 16080 2048 224 112 3072 256 128 7680 384 192 15360 512 256 RSA is defined in terms of it's modulus size. The equilavents are the same as for DSA etc. in the above table. Algorithms based on the descrete log problem in elliptic curve files (ECDSA, EC Diffie Hellman etc.) are defined in terms of the base point G of the curve. This number is commonly considered to be the key size of the curve. curve symetric size equilavent 16080 224 112 256 128 384 192 512 256 The document then goes on to recommend key sizes for information which must be protected past certain dates in the future: date symetric size now-201580 2016-2035 112 2036- 128 For E, the weakest part of the system is the 1024 bit Diffie-Hellman key agreement, the use of SHA1, and the use of DSA-1024. We should consider that users of E with long-term data confidentality requirements will need bigger keys. Cheers - Bill - Bill Frantz | The principal effect of| Periwinkle -- Consulting (408)356-8506 | DMCA/CBDTPA is to | 16345 Englewood Ave. [EMAIL PROTECTED] | prevent fair use. | Los Gatos, CA 95032, USA - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Shortcut digital signature verification failure
At 2:18 PM -0400 6/21/02, Ed Gerck wrote: A DoS would not pitch one client against one server. A distributed attack using several clients could overcome any single server advantage. A scalable strategy would be a queue system for distributing load to a pool of servers and a rating system for early rejection of repeated bad queries from a source. The rating system would reset the source rating after a pre-defined time, much like anti-congestion mechanisms on the Net. Fast rejection of bogus signatures would help, but not alone. I had already thought of this approach, but wanted to add to it a CPU limit on the client end. Hash cash with a server provided problem seems a good approach there. Cheers - Bill - Bill Frantz | The principal effect of| Periwinkle -- Consulting (408)356-8506 | DMCA/CBDTPA is to | 16345 Englewood Ave. [EMAIL PROTECTED] | prevent fair use. | Los Gatos, CA 95032, USA - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DOJ proposes US data-rentention law.
At 18:57 21/06/2002 -0700, John Young wrote: Data retention is being done now by programs and services which cache data to ease loading on servers and networks. [...] John, As a systems administrator @ an ISP, I can tell flat out that the software you describe has nothing to do with ISP services. The software provides caching services for telecom companies (ie. billing, WAP, voice mail alerts etc). I see nothing that mentions typical ISP services, like e-mail or web-browsing. It is software designed to impress the executive level with pie charts and promises of reduced hardware costs. No one likes spending $50k on a NAS or Fibre Channel / RAID 10 box. Next time John, I suggest you turn your sites on caching software like Squid. Know what? I'm not even afraid to provide the URL! http://www.squid-cache.org .. you may even discover it has US Intelligence Community(tm) links, dating back many years! Incredible, huh? ISP's like the one I work for use Squid to save on bandwidth costs by caching oft-visited websites. Unfortunately, we (like most if not all ISP's) cannot afford the massive disk arrays (or the space they would take up, even the electricity) that would be necessary to retain data *for one day*. Geez, I don't think the government gonna like that. That's doesn't even bring us to the technical abilities of all the different pieces of software that must be re-written (en masse) to satisfy government desires. For instance, let's try e-mail software.. There are numerous companies and individuals who offer their own versions of e-mail server software. Microsoft's Exchange and Ipswitch's IMail for the Windows crowd who like spending lots of money, or Qmail, Postfix, Exim and even Sendmail for the Unix crowd. There are dozen's more, but you get the point. All that software will need to be rewritten. Then all the e-mail servers will need to be upgraded and tested. THEN more disk space added just to handle all the extraneous information like from who and to, from where (say originating IP and from what server host and IP) etc etc etc ad nauseam. Whoops! Let's not forget tape backups! I'm buying 3M stock come Monday! But what happens if we have a disk failure and the logs are lost? Hmm... Anyway, that is just for e-mail.. Imagine what HTTP, or FTP, or whatever can't-live-without service someone invents in the future? Data retention is unworkable even to the biggest of companies. Even the NSA cannot store that kind of data without a significant (and secret) budget. The only ones deriving any benefit from this are law enforcement and computer hardware commercial software manufacturers. Maybe its an economic stimulus package in disguise? -- Steve. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Shortcut digital signature verification failure
David Wagner describes a trick from Dan Bernstein to speed up RSA signature verification with e = 3: One of the nicest ideas from his work is easy to describe. In plain RSA, s is a valid signature on m if H(m) = s^3 (mod n). Now suppose we ask the signer to also supply an integer k such that 0 = s^3 - kn n; clearly this can't hurt security, as k can be publicly computed from s. Then the recipient can efficiently verify the validity of the claimed signature (t,k) on m as follows: verify that 0 = s^3 - kn n; then So the signer supplies s and k. And our first step is to verify that 0 = s^3 - kn n. But given that we've computed S = s^3 - kn and it is in this range, isn't it the case that S = s^3 mod n? And so we can test test that H(m) = S = s^3 mod n and that verifies the signature directly. secretly pick a random 31-bit prime p, compute t' = s^3 mod p, n' = n mod p, k' = k mod p, h' = H(m) mod p, and verify that t' - k'n' = h' (mod p). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DOJ proposes US data-rentention law.
Steve, Not arguing, but the hardware cost curve for storage has a shorter halving time than the cost curve for CPU (Moore's Law) and the corresponding halving time for bandwidth is shorter still. If that relationship holds up over a period of years, today's tradeoffs between cache, re-computation, and anticipatory transmission would presumably change in the direction the economics dictates. And of course, if I really care that a particular piece of data is non-discoverable I either have to encrypt it, never transmit it, or go on one whopping search mission. Or so I think. Does the world look different from your vantage? --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DOJ proposes US data-rentention law.
At 17:37 22/06/2002 -0400, [EMAIL PROTECTED] wrote: Not arguing, but the hardware cost curve for storage has a shorter halving time than the cost curve for CPU (Moore's Law) and the corresponding halving time for bandwidth is shorter still. You've got a point. Storage is becoming less and less expensive per gigabyte, especially for IDE drives. If you're using a RAID set up, IDE doesn't cut it, SCSI is the way to go (for now). SCSI is a lot cheaper than it used to be, but it's still over $1000 for a single 70gig drive in Canada. For maximum redundancy in one rack-mount server, RAID 10 is the way to go. That means for every 1 drive, there must be an an exact duplicate. Costs can increase exponentially. That said, storage isn't the only expense when creating a large, fast and redundant file server (especially for caching). The fastest way to get data from a computer to the file server is via fibre channel. And fibre channel hardware isn't cheap. Last time I looked, a DIY RAID 10 system with 15 drives (1 hot-standby), case and fibre channel capability was ~ $30-35k. For each workstation that connects to it, there is a ~1k charge for the fibre channel client card. Don't even go near a fibre channel switch, they run $10-15k apiece, and don't handle more than 10-15 connections. Plus cabling. See, it adds up -- and that's just for one unit. To do the kind of data retention proposed in th EU, that is the kind of hardware that would be necessary. Plus a rack of tape backup drives running 24x7. Perhaps this sounds extreme, and it very well could be. My concern isn't so much based on what the law says must be retained, the penalties if the data isn't retained are what worry me. Could a system or network administrator be charged if the data is unavailable? What if their is a plausible reason (ie. hardware failed a year ago, fire)? What if the company cannot afford it? What charges are brought against the company? These questions are the reality for sysadmins in the EU. If Canada implemented a data retention law, I would be extremely concerned about my personal liability as well as corporate -- Canada already can charge a network administrator who the police believe is negligent in blocking (and removing) copyrighted software from computers he/she is responsible. It has happened. My understanding it has to do with an RCMP settlement over the PROMIS software scandal, but that's another topic. -- Steve - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DOJ proposes US data-rentention law.
I appreciate what an honorable ISP admin will do to abide customer rights over intrusive snoopers and perhaps cooperative administrators above the pay grade of a sysadmin. Know that a decent sysadmin is on for about 1/3 of a weekday for 24x7 systems is a small comfort but leaves unanswered what can happen: 1. During that time when a hero is elsewhere. 2. Upstream of the ISP, the router of the ISP and the nodes serving routers, as well as at a variety of cache systems serving there various levels. 3. At major providers serving a slew of smaller ISPs. In this case I reported a while back of a sysadmin telling what my ISP, NTT/Verio, is doing at its major node in Dallas: allowing the FBI to freely scan everything that passes through the Verio system under an agreement reached with NTT when it bought Verio. No matter what a local sysadmin does with data, it remains very possible that data is scanned, stored and fucked with in nasty ways coming and going such that no single sysadmin can catch it. End to end crypt certainly could help but there is still a fair abount of TA that can be done unless packets are truly disintegrated and/or camouflaged at the source before data leaves the originating box. Pumping through anonymizers, inserting within onions, subdermal pigging back on innocuous wireless packets of the financial advisor door, multiple partial sends, stego-ing, data static and traffic salting, bouncing off the moon or windowpane, what else can you do when an eager beaver industry is racing to do whatever it takes to build markets among the data controllers breathing hot about threats to national security and handing out life-saving contracts to hard-up peddlers shocked out of their skivvies with digital downturn. No patriotic act is too sleazy these days that cannot be justified by terror of red ink and looming layoffs. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Ross's TCPA paper
I recently had a chance to read Ross Anderson's paper on the activities of the TCPA at http://www.cl.cam.ac.uk/ftp/users/rja14/.temp/toulouse.pdf I must confess that after reading the paper I am quite relieved to finally have solid confirmation that at least one other person has realized (outside the authors and proponents of the bill) that the Hollings bill, while failing to mention TCPA anywhere in the text of the bill, was written with the specific technology provided by the TCPA in mind for the purpose of mandating the inclusion of this technology in all future general-purpose computing platforms, now that the technology has been tested, is ready to ship, and the BIOS vendors are on side. Perhaps the Hollings Consumer Broadband and Digital Television Promotion Act bill would be more accurately termed the TCPA Enablement Act. BTW, the module that Ross calls a Fritz in his paper after the author of the bill, long had a name: it is called a Trusted Platform Module (TPM). Granted, in the context of the TCPA and the Hollings bill, the term trusted is used somewhat differently than the customers of future motherboards, which are all slated to include a TPM, might expect: trusted here means that the members of the TCPA trust that the TPM will make it near impossible for the owner of that motherboard to access supervisor mode on the CPU without their knowledge, they trust that the TPM will enable them to determine remotely if the customer has a kernel-level debugger loaded, and they trust that the TPM will prevent a user from bypassing OS protections by installing custom PCI cards to read out memory directly via DMA without going through the CPU. The public and the media now need to somehow, preferably soon, arrive at the next stage of realization: the involvement in the TCPA by many companies who's CEO's wrote the widely distributed open letter to the movie studios, telling the studios, or more precisely -- given that it was an open letter -- telling the public, that mandating DRM's in general-purpose computing platforms may not be a good idea, is indicative of one of two possible scenarios: 1) the CEO's of said computer companies are utterly unaware of a major strategic initiative their staff has been diligently executing for about 3 years, in the case of the principals in the TCPA, such as Intel, Compaq, HP, and Microsoft, several years longer. 2) the CEO's wrote this open letter as part of a deliberate good cop, bad cop ploy, feigning opposition to DRM in general computing platforms to pull the wool over the public's eye for hopefully long enough to achieve widespread deployment of the mother of all DRM solution in the market place. I do not know which of the two potential scenarios holds true. However, I believe public debate regarding the massive change in the way users will interact with their future computers due to the efforts of the TCPA and the Hollings bill would be greatly aided by attempts to establish which of the two scenarios is the fact the case. --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Ross's TCPA paper
Ross has shifted his TCPA paper to: http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/toulouse.pdf At 07:03 PM 6/22/2002 -0700, Lucky wrote: I recently had a chance to read Ross Anderson's paper on the activities of the TCPA at http://www.cl.cam.ac.uk/ftp/users/rja14/.temp/toulouse.pdf - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
