Re: 307 digit number factored
On Wed, May 23, 2007 at 06:34:26PM +0200, Florian Weimer wrote: * Victor Duchovni: That's good of you not to expect it, given that zero of the major CAs seem to support ECC certs today, and even if they did, those certs would not work in IE on XP. We are not talking about this year or next of course. My estimate is that Postfix releases designed this year, ship next year, are picked up by some O/S vendors the year after and shipped perhaps a year after that, then customers take a few years to upgrade, ... So for some users Postfix 2.5 will be their MTA upgrade in 2011 or later. So we need to anticipate future demand by a few years to be current at the time that users begin to use the software. But no one is issuing certificates which are suitable for use with SMTP (in the sense that the CA provides a security benefit). As far as I know, there isn't even a way to store mail routing information in X.509 certificates. There is no need to store routing information: http://www.postfix.org/TLS_README.html#client_tls_limits http://www.postfix.org/TLS_README.html#client_tls_levels http://www.postfix.org/TLS_README.html#client_tls_verify http://www.postfix.org/TLS_README.html#client_tls_secure The short summary is that full security is only available when the receiving MX hosts have certs that match the recipient domain, or the sender is willing to manually (in his MTA configuration) bind the recipient domain to the subject names (or in 2.5 fingerprints) of the appropriate MX hosts. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
SSL certificates for SMTP
At 6:34 PM +0200 5/23/07, Florian Weimer wrote: * Victor Duchovni: That's good of you not to expect it, given that zero of the major CAs seem to support ECC certs today, and even if they did, those certs would not work in IE on XP. We are not talking about this year or next of course. My estimate is that Postfix releases designed this year, ship next year, are picked up by some O/S vendors the year after and shipped perhaps a year after that, then customers take a few years to upgrade, ... So for some users Postfix 2.5 will be their MTA upgrade in 2011 or later. So we need to anticipate future demand by a few years to be current at the time that users begin to use the software. But no one is issuing certificates which are suitable for use with SMTP (in the sense that the CA provides a security benefit). No one? I thought that VeriSign and others did, at least a few years ago. As far as I know, there isn't even a way to store mail routing information in X.509 certificates. Why would you need to? SMTP-over-TLS only identifies the system to whom you are speaking. No routing inforation is needed or wanted. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: dnssec?
Anne Lynn Wheeler wrote: for other topic drift ... a recent post with some DNS related trivia ... more than a decade before DNS (about half-way down the post mentioning former MIT student) http://www.garlic.com/~lynn/2007k.html#33 Even worse than UNIX and for other topic drift, old email about online, real-time public key distribution (also predating DNS) http://www.garlic.com/~lynn/2006w.html#email850515 in this post http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network and rfc editor announcement from today my rfc index http://www.garlic.com/~lynn/rfcietff.htm http://www.garlic.com/~lynn/rfcindx16.htm#4871 4871 PS DomainKeys Identified Mail (DKIM) Signatures, Allman E., Callas J., Delany M., Fenton J., Libbey M., Thomas M., 2007/05/22 (71pp) (.txt=166054) (Obsoletes 4870) (See Also 4870) (Refs 1847, 2045, 2047, 2440, 2821, 2822, 3447, 3490, 3766, 3833, 3851, 4033, 4234, 4686) (was draft-ietf-dkim-base-10.txt) http://www.garlic.com/~lynn/rfcindx16.htm#4870 4870 -H Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys), Delany M., 2007/05/22 (41pp) (.txt=87378) (Obsoleted by 4871) (See Also 4871) (Refs 1421, 3833, 3851, 4648) (was draft-delany-domainkeys-base-06.txt) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
-- Anne Lynn Wheeler wrote: So one of the proposals (somewhat backed by the domain name certification authority industry) is that domain name owners place a public key on file when they register a domain name with the domain name infrastructure. They all future communication with the domain name infrastructure can be digitally signed ... and the domain name infrastructure verify the digital signature with the onfile public key. If the decision was to be made by five engineers sitting around a coffee table, they would agree on a solution in a few minutes, and implement it in a week, but a committee of seventeen people could not agree to adjourn a meeting held in a burning building. The problem is organizational. To get one decision centrally made and imposed on everyone requires a central body capable of making decisions and imposing them on everyone, and before it can get that authority, that central body usually has to raze Atlanta and burn the crops, or inflict genocidal famine on the Ukraine. The great strength and great weakness of the internet is that it is an anarchy. Anything that requires one decision made for all, such as the domain name system, got frozen when the internet became too large for decision making by consensus, and is now extremely difficult to change. So to make changes, they have to be made incrementally: You need a CA with the proposed policy and a deal with several registrars, and that CA needs to get on the Mozilla and IE list. Nice selling point. If you register with, say OpenSRS, you would automatically get an SSL cert. Unfortunately, the certification process for a CA to get on the browser list seems to be somewhat circular - to be a CA, you have to prove you are like existing CAs, which is most easily done if you *are* an existing CA, and have no intention of changing the way you work. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
James A. Donald wrote: The problem is organizational. To get one decision centrally made and imposed on everyone requires a central body capable of making decisions and imposing them on everyone, and before it can get that authority, that central body usually has to raze Atlanta and burn the crops, or inflict genocidal famine on the Ukraine. The great strength and great weakness of the internet is that it is an anarchy. Anything that requires one decision made for all, such as the domain name system, got frozen when the internet became too large for decision making by consensus, and is now extremely difficult to change. So to make changes, they have to be made incrementally: You need a CA with the proposed policy and a deal with several registrars, and that CA needs to get on the Mozilla and IE list. Nice selling point. If you register with, say OpenSRS, you would automatically get an SSL cert. Unfortunately, the certification process for a CA to get on the browser list seems to be somewhat circular - to be a CA, you have to prove you are like existing CAs, which is most easily done if you *are* an existing CA, and have no intention of changing the way you work. re: http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored ... that could be the short term view ... as well as dealing with established operation ... having been around since before the current CA stuff started ... and somewhat involved in helping get the current infrastructure established (from the standpoint of its inception for what is now called electronic commerce ... and having to do detailed business process technical walk thru and audit of the early certification authority players) ... the issue is more how to replace something once it was established (i.e. the current infrastructure somewhat got fast uptake ... because it didn't have alternative solutions to deal with). re: http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec? http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec? somewhat topic drift with DNS related trivia ... more than a decade before DNS http://www.garlic.com/~lynn/2007k.html#33 and some old email (predating dns) suggesting online, realtime public key server http://www.garlic.com/~lynn/2006w.html#email810515 in this post http://www.garlic.com/~lynn/2006w.htmL#12 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
crypto maxims
I have posted my ideas on defensive use of crypto here: https://www.subspacefield.org/security/cgi-bin/moin.py/CryptoMaxims This is not about cipher design, it's more about protocol design and implementation. Everyone here is welcome to edit it as they see fit; questions and answers, discussion - the goal is education, so all of those are desirable. -- Good idea: helping a stranger move Bad idea: helping a stranger move bodies URL:http://www.subspacefield.org/~travis/ -- For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpxaOXrYkI6v.pgp Description: PGP signature
Re: 307 digit number factored
Anne Lynn Wheeler [EMAIL PROTECTED] writes: of course ... the whole licenses/credentials/certificates are an offline world paradigm licensing, credentialing, and certifications can be validated with online, real-time operations ... obsoleting any requirement for supporting offline methodologies. it would be really great to make it an excuse to move away from offline paradigm to real online operation ... getting totally rid of the need for domain name certificates ... DNS serving up both ip-addresses and public keys in single operation. This would destroy the protection of one who depends on off-line, message-based communication for self-defense. Such a person may create and maintain a persistent pseudonym through untraceable chains of random latency, anonymizing remailers which thwart traffic analysis through mixing. On-line, connection-based communication has low latency and can be traced by traffic analysis. -- StealthMonger [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- stealthmail: Scripts to hide whether you're doing email, or when, or with whom. http://stealthsuite.afflictions.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
[EMAIL PROTECTED] (Peter Gutmann) writes: I would go further and say that for most applications of PKCs/PKI today, 1024- bit RSA keys are not a risk at all, or more specifically that on a scale of risk they're so far down the list that they're close to negligible. As numerous security HCI studies have shown, user comprehension of PKI is close to zero percent, which means that the security effectiveness of the same is also close to zero. Although I agree that key cracking is not a threat we should concern ourselves with by a long shot, that does not mean that changing to larger keys is not cost effective. This is because larger keys are essentially free -- it costs no more (for most applications) to generate a 2048 bit key than a 1024 bit key, so there is no incentive not to. However, I violently agree that no one should be under the illusion that longer keys will protect them from the most realistic security threats. (For those applications where longer keys actually will cost significantly and the value of the keys is low, the calculation changes and there is little or no reason to upgrade.) As the multi-billion dollar phishing industry has ably demonstrated, the bad guys are more than aware of this too. So going from x- bit RSA to y-bit RSA on a component with close to zero-percent effectiveness is... well, I'll let you do the maths. https with X.509 certs is not the only application of RSA keys, of course. There are a significant number of applications where the keys actually do work reasonably effectively, and the real threat is not phishing but code bugs. Still, in spite of the fact that no one is, say, formally validating openssh, it costs nothing to request a 2048 bit key instead of a 1024 bit key, and I'm not sure it is a bad idea to do that on an opportunistic basis. Even for https, it costs no more to type in 2048 than 1024 into your cert generation app the next time a cert expires. The only potential cost is if you're so close to the performance line that slower RSA ops will cause you pain -- otherwise, it is pretty much costless. For average people's web servers most of the time, connections are sufficiently infrequent and RSA operations are fast enough that it makes no observable difference. Until the hundred other constituent parts required to secure something like web browsing are fixed, changing the key size is just pointless posturing, since it's not fixing anything that anyone is attacking. Once all the other bits are fixed and working as intended, then we can go back to debating whether length is more important than width in key sizes. I'm not sure I entirely buy the argument. Certainly there are other far more (overwhelmingly more) important issues, and certainly a steel door helps little in a tissue paper wall, but that is no reason to let the door slowly rust away while you rebuild the wall, especially if protecting it from rust is literally effortless. At the same time, I'll agree that reading this argument is itself probably more expensive than the benefit longer key length is likely to provide someone in the near future. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL certificates for SMTP
Paul Hoffman wrote: At 6:34 PM +0200 5/23/07, Florian Weimer wrote: But no one is issuing certificates which are suitable for use with SMTP (in the sense that the CA provides a security benefit). No one? I thought that VeriSign and others did, at least a few years ago. FWIW, last year we established a dedicated Intermediate Certification Authority for issuing digital certificates to admins of XMPP servers: https://www.xmpp.net/ Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: 307 digit number factored
re: http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec? http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec? http://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored part of the quick IETF uptake of SSL and VPN in the 94/95 time-frame was that there really wasn't any serious competition. there was ipsec ... but it was end-to-end implementation at low level ip-stack ... which were kernel implementations ... and then was faced with the whole issue of distribution, installation and support of new kernels on machines all around the world (from a variety of different vendors and different operating systems). SSL was almost a no-brainer ... since it just involved loading/installing a new application (orders of magnitude easier than ipsec). lots of collected posts mentioning SSL and/or SSL certificates http://www.garlic.com/~lynn/subpubkey.html#sslcert in the same time-frame VPN was introduced at the gateway committee meeting at '94 San Jose IETF meeting. We had worked with the guy on and off since the late 70s and he originally developed the technology for his own use ... between home and office; actually both his wife and he worked for different technology companies ... he got a leased line from the house to his office ... and her company got a circuit from his office to their office. The issue was how to encrypt the wife's communication w/o having it exposed to the husband and/or the husband's company. sort of the state-of-the art had been link encryptors ... for a little topic drift ... the internal corporate network had been larger than the arpanet/internet from just about the beginning until possibly summer of '85. the internal network required encryption on everything leaving the premise ... and in the mid-80s there were comments that the internal network had over half of all link encryptors in the world. misc. past posts mentioning the internal network. http://www.garlic.com/~lynn/subnetwork.html#internalnet the requirement that led to VPN was how to carry separately encrypted streams over the same link. ipsec would have solved the problem ... but again was end-to-end solution that required upgrading all the low-level ip-stacks ... which required distribution, installation (and support) of new kernel. the VPN solution was to handle the stream encryption/decryption in boundary routers (which could be tunneled over other infrastructure). my observation was this resulted in some amount of consternation in the ipsec faction ... which they somewhat resolved by starting to refer to VPN as lightweight ipsec (and of course, everybody else could then refer to regular ipsec as heavyweight ipsec). the other problems was with various router vendors in the IETF. it was sort of divided along the lines of the vendors that had enuf horse power in their current boxes to implement and deploy VPN support ... and the other vendors whos' products didn't have enuf processing power available to do the crypto operations in support of VPN. This difference dragged out some of the VPN standardization activity within IETF. misc. past posts mentioning lightweight ipsec http://www.garlic.com/~lynn/aadsm11.htm#24 Proxy PKI. Was: IBM alternative to PKI? http://www.garlic.com/~lynn/aadsm15.htm#2 Is cryptography where security took the wrong branch? http://www.garlic.com/~lynn/aadsm25.htm#19 Hamiltonian path as protection against DOS http://www.garlic.com/~lynn/2003e.html#34 Use of SSL as a VPN http://www.garlic.com/~lynn/2003l.html#23 Why more than 1 hole in FW for IPSec http://www.garlic.com/~lynn/2007d.html#37 MAC and SSL http://www.garlic.com/~lynn/2007g.html#63 The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007h.html#67 SSL vs. SSL over tcp/ip for other drift ... some of the people doing VPN implementations were using RSA bsafe library ported to whatever processor they were using. Some number of these put in effort to enhance the performance of bsafe library. some of this was going on when we were in transition from working on the infrastructure that is currently frequently referred to as electronic commerce and work in the x9a10 financial standard committee. in that same time frame there were other efforts looking at enhancing how payment transactions could be implemented and deployed for the internet (as opposed to x9a10 standards work which had a requirement to have a standard that preserved the integrity of financial infrastructure for ALL retail payments). One of these published some of their specification and from the specification I drew up a business operation profile and a public key operation profile. I then got the public key operation profile executed on a number of different platforms using the speeded up bsafe library (running four times faster) ... and reported the numbers back to the organization responsible for that
