Re: 307 digit number factored
| AFAIK, the only advantage of ECC is that the keys are | shorter. The disadvantage is that it isn't as well | studied. | James A. Donald: | On past performance, elliptic curves are safer than | integers. From time to time, integer based asymmetric | encryption is abruptly and surprisingly weakened by | advances in discrete log algorithms. This is just not | happening with elliptic curves. Leichter, Jerry wrote: Past performance does not predict future results. I don't think this is a particularly strong argument. A reasonable counter-argument is that we've been doing number theory over the integers for hundreds of years, while intensive work on computations over elliptic curves goes back, what, 20 years at most? And in those twenty years we have made little progress on the division problem with elliptic curves, and considerable progress on the discrete log problem on integers. Surely, with a thousand year start, progress on integers should be slowing down, not speeding up. Further, this is what one would expect from the irregular character of elliptic curves. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
A 307 digit number is 1024 bits, near enough. 1024 bits was scheduled to fail in 2013. It has failed early, due to modest advances in factorization. Thus past comparisons of the strength of encryption key sizes are no longer entirely accurate. Further, they never were that accurate to start with - one needs actual run times for breaks run on the same machine. None of the past comparisons have started from such concrete data. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
[EMAIL PROTECTED] wrote: AFAIK, the only advantage of ECC is that the keys are shorter. The disadvantage is that it isn't as well studied. Nate Lawson wrote: Again, this is well covered. The reason is the fundamental difference in the performance of the best-known attacks (GNFS vs. Pollard's rho). http://www.vaf.sk/download/keysize.pdf At the timpe that http://www.vaf.sk/download/keysize.pdf was published, 1024 bit asymmetric encryption over integers was comparable in strength to 80 bit symmetric encryption, and elliptic curve encryption over a 160 bit fields. At that time integers based asymmetric encryption took about four times as long to compute as the comparable strength elliptic curve asymmetric encryption. Since then, integer encryption has weakened further relative to elliptic curve encryption, due to advances in factorization and the discrete log problem, increasing the advantage of elliptic curves. With widespread failure to use encryption due to the computational costs a factor of more than four is not to be sneezed at. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
-- [EMAIL PROTECTED] wrote: AFAIK, the only advantage of ECC is that the keys are shorter. The disadvantage is that it isn't as well studied. On past performance, elliptic curves are safer than integers. From time to time, integer based asymmetric encryption is abruptly and surprisingly weakened by advances in discrete log algorithms. This is just not happening with elliptic curves. The cost of computing power is going down faster than the cost of communication. The size of sufficiently safe asymmetric encryption based on integers is growing considerably faster than the size of sufficiently safe asymmetric encryption based on elliptic curves. Thus the advantage of elliptic curve encryption continually increases, will become overwhelming in the near future - and a large part of that continually increasing advantage comes from unpredictable improvements in factoring and discrete log over the integers. My intuition is that because elliptic curves are considerably less orderly than the integers, there is less scope for discovering fast discrete log methods. We are continually discovering improvements to finding discrete logs over the integers. It has been a long time since any such has been discovered for elliptic curves, long enough to give a plausible hope that no further such will ever be discovered. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG ibAQXQ+Yoy5neOvRwKJwdxVLDGSPwTxKobkv566h 4khPsLmyqlil/F6sx2n1q9mtb65W8RMcWyqxregOo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
Aloha! Nate Lawson skrev: Some EC primitives in the latest OpenSSL. Because various standard forms of EC were never covered by patents. This has been rehashed many times, for example: http://www.xml-dev.com/pipermail/fde/2007-July/000450.html IANAL but IMHO this is only partially true. Try doing an efficient implementation in HW of ECC and not stepping on Certicom patent toes. SW implementations are probably ok though. -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. Kryptoblog - IT-säkerhet på svenska http://www.strombergson.com/kryptoblog - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
On Mon, May 21, 2007 at 04:32:10PM -0400, Victor Duchovni wrote: On Mon, May 21, 2007 at 02:44:28PM -0400, Perry E. Metzger wrote: My take: clearly, 1024 bits is no longer sufficient for RSA use for high value applications, though this has been on the horizon for some time. Presumably, it would be a good idea to use longer keys for all applications, including low value ones, provided that the slowdown isn't prohibitive. As always, I think the right rule is encrypt until it hurts, then back off until it stops hurting... When do the Certicom patents expire? I really don't see ever longer RSA keys as the answer, and the patents are I think holding back adoption... They already expired. Some EC primitives in the latest OpenSSL. But why assume short ECC keys are stronger than long RSA? AFAIK, the only advantage of ECC is that the keys are shorter. The disadvantage is that it isn't as well studied. Although every time I read up on ECC, I understand it, and then within a few days I don't remember anything about it. I think they teflon coated those ideas somehow, because they don't stick. With EECDH one can use ECDH handshakes signed with RSA keys, but that does not really address any looming demise of 1024 bit RSA. Why can't they do something like El-Gamal? I'm not comfortable with RSA somehow. It seems fundamentally more complicated to me than DLP, and it's hard to get right - look at how many things there are in the PKCS for it. -- URL:http://www.subspacefield.org/~travis/ Eff the ineffable! For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpBNtfcR3SYr.pgp Description: PGP signature
Re: 307 digit number factored
[EMAIL PROTECTED] wrote: On Mon, May 21, 2007 at 04:32:10PM -0400, Victor Duchovni wrote: On Mon, May 21, 2007 at 02:44:28PM -0400, Perry E. Metzger wrote: My take: clearly, 1024 bits is no longer sufficient for RSA use for high value applications, though this has been on the horizon for some time. Presumably, it would be a good idea to use longer keys for all applications, including low value ones, provided that the slowdown isn't prohibitive. As always, I think the right rule is encrypt until it hurts, then back off until it stops hurting... When do the Certicom patents expire? I really don't see ever longer RSA keys as the answer, and the patents are I think holding back adoption... They already expired. Not true (counterexample: ECMQV). Some EC primitives in the latest OpenSSL. Because various standard forms of EC were never covered by patents. This has been rehashed many times, for example: http://www.xml-dev.com/pipermail/fde/2007-July/000450.html But why assume short ECC keys are stronger than long RSA? AFAIK, the only advantage of ECC is that the keys are shorter. The disadvantage is that it isn't as well studied. Again, this is well covered. The reason is the fundamental difference in the performance of the best-known attacks (GNFS vs. Pollard's rho). http://www.vaf.sk/download/keysize.pdf Also, EC public operations are typically faster than private, although not on the order of the difference between RSA public and private ops. Although every time I read up on ECC, I understand it, and then within a few days I don't remember anything about it. I think they teflon coated those ideas somehow, because they don't stick. With EECDH one can use ECDH handshakes signed with RSA keys, but that does not really address any looming demise of 1024 bit RSA. Why can't they do something like El-Gamal? I'm not comfortable with RSA somehow. It seems fundamentally more complicated to me than DLP, and it's hard to get right - look at how many things there are in the PKCS for it. The RSA or EC primitives are *not* usable cryptographic schemes by themselves, thus it isn't fair to compare them this way (RSA+PKCS#1 != EC point multiplication). ECDSA, for example, is intentionally constrained to be signing-only and the hash signed is a fixed size. It's more fair to compare RSA+PKCS#1 with EC+DSA/DH. In that sense, I think the complexity of implementation is similar. I'm not saying that one of these schemes is better than the other. They each have their own tradeoffs. I just object to your methodology of claiming RSA is fundamentally more problematic than EC. -- Nate - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
On Thu, May 24, 2007 at 01:01:03PM -0400, Perry E. Metzger wrote: 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. I don't buy it. I build HTTP load balancers for a living, and for basically all of our customers who use our HTTPS accelleration at all, the cost of 1024-bit RSA is already, by a hefty margin, with hardware assist, the limiting factor for performance. Look at the specs on some of the common accelelrator families sometime: 2048 bit is going to be quite a bit worse. Busy web sites that rely on HTTPS are going to pay a fairly heavy price for using longer keys, and not just in cycles: the few hardware solutions still on the market that can stash keys in secure storage, of course, can stash exactly half as many 2048-bit keys as 1024-bit ones. Users who care about HTTPS performance aren't as rare, I think, as you think. What's more frustrating is the slow rate at which accellerator vendors have moved ECC products towards market. That's not going to help with adoption any. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
The need for off-line communication [was: Re: 307 digit number factored]
Anne Lynn Wheeler [EMAIL PROTECTED] writes: ... [lengthy discussion about why on-line communication is better than off-line for strangers becoming introduced to one another] ... That may well be, but no claim was made that off-line communication is as efficient as on-line for introducing and certifying strangers to one another. It was only claimed that players who have to remain geographically hidden would lose their protection if deprived of off-line communication. This is because in the on-line, low-latency case, an attacker can locate the end-points through traffic analysis. Only off-line does the option exist of untraceable traffic mixing such as remailer chains. This subject is on-topic here because cryptography is an indispensable ingredient of these untraceable traffic mixes. -- 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
* Victor Duchovni: 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, Which runs into the same problem as HTTP because the set of recipient domain names is not known at the time the TLS handshake occurs. 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. And if you use fingerprints, there is no need for PKI. And in my experience, PKI doesn't buy you that much if you need to configure per-client privileges and things like that. Using the DN instead of a fingerprint doesn't seem to be worth the trouble. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
StealthMonger wrote: 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. 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 the credential/licensing/certificate paradigm was certification of strangers who have never before communicated before ... and there was no timely, available mechanism for providing information about the other party (aka the analogy of letters of credit/introduction from sailing ship days and before). parties with previous relationship can have available information about each other based on prior relationship ... or strangers in first time communication may have access to timely sources of information about the other party. the issue wasn't that the offline stranger paradigm didn't exist ... it just was a rapidly disappearing scenario ... aka digital certificates were somewhat modeled after the sailing ship days letters of credit/introduction for the early 80s offline email scenario for first time communication between complete strangers ... dial-up local electronic post-office, exchange email, hang-up ... and then potentially faced with first-time email from total stranger. while digital certificate wasn't as high a quality information paradigm as real-time, online ... in this particular scenario, it was better than the alternative ... nothing. the issue isn't eliminating digital certificates for the situations where they may be appropriate ... it is eliminating digital certificates for uses where they are obsolete, never intended for, redundant and/or superfluous. For all the situations where digital certificates and PKI aren't applicable (or redundant and superfluous) they tend to represent and extraneous and unnecessary business cost providing little or no added value. in the wake of some of the original stuff (w/SSL that is frequently no referred to as electronic commerce) there was some investigations that looked at adding digital certificate kinds of processing to existing real time payment transactions http://www.garlic.com/~lynn/aadsm27.htm#20 307 digit number factored some of the comments was that adding such digital certificate processing would bring payment transactions into the modern era. Our observation was that reverting to an offline PKI, digital certificate processing paradigm would set back real-time payment transactions several decades. That if you were doing real-time payment transactions that online, timely processing had significantly higher quality information processing ... real-time status of public key onfile in the account record as well as aggregated information ... recent payment transaction patterns, current balance and/or credit limit, etc. It was in the wake of that series of exchanges that you saw OCSP work start in IETF. We observed that not only was the stale, static digital certificate addition to real-time payment transactions redundant and superfluous ... that the typical proposals of the period represented a factor of 100 times in payload size bloat (enormous payload cost addition providing no added benefit) as well as the redundant and superfluous digital certificate processing increased real-time payment transaction processing by nearly a factor of 100 times. Misc. past posts mentioning enormous redundant and superfluous stale static digital certificate added overhead http://www.garlic.com/~lynn/subpubkey.html#bloat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
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]
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]
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: 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
Re: 307 digit number factored
Anne Lynn Wheeler wrote: 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. That can't happen until we make sure you can trust DNS, which in turn can't happen until we get a concrete proposal that has clearly defined goals and isn't braindead. As has been amply pointed out, it's not clear that DNSSEC will cut it anytime soon. (These days, the complaints even come with illustrations: http://www.matasano.com/log/772/a-case-against-dnssec-count-2-too-complicated-to-deploy/). -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
Ivan Krstić wrote: That can't happen until we make sure you can trust DNS, which in turn can't happen until we get a concrete proposal that has clearly defined goals and isn't braindead. As has been amply pointed out, it's not clear that DNSSEC will cut it anytime soon. A big part of the issue is the domain name certification authority has to trust the domain name infrastructure as to the true owner of the domain name ... when they are processing a domain name certificate application for certification (i.e. only the actual domain name owner on file with the domain name infrastructure should be able to apply for domain name certifications). The catch-22 is that the original idea behind domain name certificates were because of integrity issues with the domain name infrastructure. However, the domain name certification industry is dependent on the integrity of the domain name infrastructure in their domain name certification process. As a result they need to improve the integrity of the domain name infrastructure because their dependency on the domain name infrastructure in their process of certification. 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. This is intended to help improve the integrity of the domain name infrastructure. However, it could also offer benefits to the domain name certification authority industry. The domain name certification authority industry could also then start requiring that domain name certification applications also be digitally signed. The the domain name certification authority industry can do a real-time retrieval of the on-file public key to verify the domain name certification application digital signatures. This provides for turning a time-consuming, error-prone, and expensive identification process into a much simpler, reliable, and less expensive authentication process (enormous benefits for the domain name certification authority industry). The issue is that if the domain name certification authority industry are somewhat two fold: 1) the original justification for domain name certification involved integrity issues with the domain name infrastructure. improving the integrity of the domain name infrastructure would reduce the original justification for having domain name certification 2) if the domain name certification authority industry could start relying on real-time retrieval of public keys ... then possibly the rest of the world could also ... eliminating the need for domain name infrastructure. some collected catch-22 posts http://www.garlic.com/~lynn/subpubkey.html#catch22 long ago and far away, we had been called in to consult with this small client/server startup that wanted to do payment transactions and had this technology called SSL. In addition to doing stuff about working out the payment transaction operation we also had to do a lot of stuff with end-to-end business process investigation of these new business operations called certification authorities. Since then, this has frequently come to be referred to as electronic commerce. some old posts http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 and collection of posts mentioning payment processing and payment gateway http://www.garlic.com/~lynn/subnetworkhtml#gateway Now, the original SSL infrastructure was to verify that the URL that the user entered (into the browser) corresponded to the website that the browser was talking to (i.e. the website that the user thought they were talking to was the website they were actually talking to). However, most electronic commerce sites fairly quickly found that SSL was costing them something like 90percent of their thruput. The result was that most websites transitioned to no longer using SSL for the initial user connection but reserved just for the payment process (to hide the account number information). Now the user clicks on a button (provided by the webserver) which generates a URL (provided by the webserver). Now instead of checking the URL provided by the user against the webserver ... most use of SSL now checks the URL provided by the webserver against the webserver (invalidating the original SSL security assumptions). lots of past posts about ssl digital certificate infrastructure http://www.garlic.com/~lynn/subpubkey.html#sslcert so it could be claimed that the way that the currently deployed SSL for the electronic commerce infrastructure doesn't really cut it either ... it is somewhat a case of the emperor's new clothes ... and the integrity of the domain name infrastructure has to be improved in any case, since it is the
Re: 307 digit number factored
somewhere over the yrs the term certification authority was truncated to certificate authority ... along with some impression that certificates are being sold (as opposed to certification processes). When I pay $14.95 for a certificate, with the investigation of my bona fides limited to clicking through a link in an e-mail, and answering the phone*, entering a short code, and responding to a request to state your name**, it sure seems to me like I'm buying a certificate. The only reason I do it is that for that price it's cheaper than explaining to people why the threat that web certs defend against is stupid. getting totally rid of the need for domain name certificates ... DNS serving up both ip-addresses and public keys in single operation. DKIM does that, you can get the MX and verification key for a domain. But I wouldn't say that was a security improvement except insofar as it makes the process easy enough that people are more likely to use it than they are the more cumbersome systems like S/MIME. R's, John * - any old phone, I've had them call random VoIP numbers in other continents that I was experimenting with ** - so of course I say your name. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
For the math weenies on the list, see the full announcement here: http://listserv.nodak.edu/cgi-bin/wa.exe?A2=ind0705L=nmbrthryT=0P=1019. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
Victor Duchovni [EMAIL PROTECTED] writes: As 1024 RSA keys are not a major risk *today*, 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. 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. 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. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
* 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. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
Victor Duchovni wrote: The other issue is that sites will need multiple certs during any transition from RSA to ECC, because the entire Internet won't upgrade overnight. I am not expecting public CAs to cooperate by charging the same price for two certs (RSA and ECC) for the same subject name(s), this also may significantly impede migration. in theory, certification authorities charge for the certification operations that they perform ... and the certificate is just a representation of that certification process. somewhere over the yrs the term certification authority was truncated to certificate authority ... along with some impression that certificates are being sold (as opposed to certification processes). doing quicky web search of licensing and certification agencies ... it looks like there is charge for replacing certificates/licenses ... but nothing compared to the charge for the original certification process. 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. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
FWIW, according to Arjen Lenstra, there should be a better paper than the physorg.com article on the eprint.iacr.org site next week, hopefully. At 4:32 PM -0400 5/21/07, Victor Duchovni wrote: When do the Certicom patents expire? Which ones? They have many. Using EC depends on how brave you are and which country you are in. I really don't see ever longer RSA keys as the answer, and the patents are I think holding back adoption... Because I agree with the latter, I disagree with the former, at least for a few more years and until a few people are braver than I am. The other issue is that sites will need multiple certs during any transition from RSA to ECC, because the entire Internet won't upgrade overnight. I am not expecting public CAs to cooperate by charging the same price for two certs (RSA and ECC) for the same subject name(s), this also may significantly impede migration. 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. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
On Mon, May 21, 2007 at 08:07:24PM -0700, Paul Hoffman wrote: The other issue is that sites will need multiple certs during any transition from RSA to ECC, because the entire Internet won't upgrade overnight. I am not expecting public CAs to cooperate by charging the same price for two certs (RSA and ECC) for the same subject name(s), this also may significantly impede migration. 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. As 1024 RSA keys are not a major risk *today*, but that may be in sight, it is not unreasonable to explore the (multi-year) road to ECC adoption. There are many obstacles, it may take a long time, but I am removing the one obstacle I can remove... Initially ECC in Postfix will be used by private arrangements between sites that manually exchange keys and have no need of a public CA. Postfix, 2.5 also includes a new fingerprint security level, where the SMTP client verifies the server certificate by its md5, sha1, or SHA256/384/512 fingerprint. (No support for web-of-trust, one step at a time). -- /\ 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]
307 digit number factored
Quoting the original article: A mighty number falls Mathematicians and number buffs have their records. And today, an international team has broken a long-standing one in an impressive feat of calculation. On March 6, computer clusters from three institutions \u2013 the EPFL, the University of Bonn and NTT in Japan -- reached the end of eleven months of strenuous calculation, churning out the prime factors of a well-known, hard-to-factor number that is a whopping 307 digits long. This is the largest 'special' hard-to-factor number factored to date, explains EPFL cryptology professor Arjen Lenstra. (The number is 'special' because it has a special mathematical form -- it is close to a power of two.) The news of this feat will grab the attention of information security experts and may eventually lead to changes in encryption techniques. http://www.physorg.com/news98962171.html My take: clearly, 1024 bits is no longer sufficient for RSA use for high value applications, though this has been on the horizon for some time. Presumably, it would be a good idea to use longer keys for all applications, including low value ones, provided that the slowdown isn't prohibitive. As always, I think the right rule is encrypt until it hurts, then back off until it stops hurting... -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
On Mon, May 21, 2007 at 02:44:28PM -0400, Perry E. Metzger wrote: http://www.physorg.com/news98962171.html My take: clearly, 1024 bits is no longer sufficient for RSA use for high value applications, though this has been on the horizon for some time. Presumably, it would be a good idea to use longer keys for all applications, including low value ones, provided that the slowdown isn't prohibitive. As always, I think the right rule is encrypt until it hurts, then back off until it stops hurting... When do the Certicom patents expire? I really don't see ever longer RSA keys as the answer, and the patents are I think holding back adoption... FWIW, Postfix 2.5 in Q1 08 will have EC support when compiled with (likely officially released by then) OpenSSL 0.9.9, the recommended curve is prime256v1 with secp384r1 for encrypt until it hurts users :-). The other issue is that sites will need multiple certs during any transition from RSA to ECC, because the entire Internet won't upgrade overnight. I am not expecting public CAs to cooperate by charging the same price for two certs (RSA and ECC) for the same subject name(s), this also may significantly impede migration. With EECDH one can use ECDH handshakes signed with RSA keys, but that does not really address any looming demise of 1024 bit RSA. -- /\ 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]
