- NANOG - lists.nanog.org

Re:RE: 1024-bit RSA keys in danger of compromise (fwd)
by rkuhljr＠uol.com.br 26 Mar '02

26 Mar '02

Does NSA need compromising US-based CA's private keys ? Probably not, because they either (a) already have the private keys, obtained thru a combination of political, financial and intelligence resources. or (b) already have proceedings with the CA's in order to issue valid look-a-like certificates for any domain they want. If you look from the NSA's point of view, the investment might still sound reasonable for cracking the private keys. Rubens Kuhl Jr. >> > >Since you are mentioning Verisign here, and CA authorities in general, has >anyone considered that factoring the CA authority's key is far simpler than >breaking the underlying key [no matter how large?]. Based on the >implementation, the CA's key cannot be changed often or easily. Key >revocations are not automatic or even respected, and the CA's key, once >compromised, can sign any other key you'd like for a beautiful >man-in-the-middle attack. > >The man-in-the-middle is the only attack these keys are designed to thwart, >because if you can't access the physical bits, you don't have anything to >decipher anyway. The beautiful thing about compromising the CA's key is that >its not easily traceable. > >Regards, > >Deepak Jain >AiNET > >-----Original Message----- >From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of >Len Sassaman >Sent: Monday, March 25, 2002 6:32 PM >To: nanog(a)merit.edu >Subject: Re: 1024-bit RSA keys in danger of compromise (fwd) > > > >I discussed this in detail with Lucky before he posted it. I'll give a >summary of how this affects the readers of NANOG here -- feel free to >forward if you like. > >Prior to Bernstein's discovery the row-reduction step in factorization >could be made massively parallelizable, we believed that 1024 bit keys >would remain unfactorable essentially forever. Now, 1024 bit RSA keys look >to be factorable either presently, or in the very near future once Moore's >law is taken into account. However, at a price tag of $2 billion for a >specialized machine, we have a few years before anyone outside of the >intelligence community attempts this. > >What is most concerning to me is a few discoveries that were made while >looking into the problem of widespread use of 1024 bit keys: > >First: Verisign appears to have no minimum requirements for the key sizes >it will sign. I have discussed at length Verisign's active contributions >to the hindrance of security on the Internet in the past (see the >archives of my presentation at DEFCON 9), but I somehow missed this gem. A >few months ago, in fact, Verisign issued a 384 bit certificate. (You could >factor this on your desk top machine in days.) 512 bit keys are also >fairly commonly signed by Verisign. (Ugh.) > >Question for people who know: Does Verisign allow you to submit CSRs for >2048 to 4096 bit certificates? > > >Second: As far as I can tell, OpenSSH (and I assume the commercial >versions of SSH as well) offer no mechanism for enforcing the size of >users' keys when public key authentication is turned on. This means that >users could be placing (factorable) 512 bit keys in their >~/.ssh/authorized_keys files, which is in effect worse than using weak >passwords (as an attacker would leave no false login attempts for you to >detect in your logs). > >I've mailed Theo de Raadt asking if OpenSSH has an undocumented mechanism >for specifying minimum permitted key size that I don't know about. If >there is one, I'll certainly post a follow-up. > > >Lucky also mentions S/MIME, which has so many flaws I'm not going to >address it; PGP, which places the risks squarely on the key-holder and >doesn't prevent the use of 2048 bit keys (which should be safe even taking >Bernstein's findings into account), so I'm not to concerned with that; and >IPsec, which sadly isn't in widespread use. > > >So, my main concerns are TLS, (which is damaged due to poor engineering on >the part of Netscape and Microsoft, and uncouth policy issues on the part >of Versign) and SSH, which may suffer from an easily correctable >engineering flaw. Note that the biggest concerns don't have to do >specifically with 1024 bit keys, but rather, small key sizes in general. > > >--Len. > > >On Mon, 25 Mar 2002, Todd Suiter wrote: > >> >> (forwarded w/o permissions, though this hit bugtraq earlier...t) >> >> >> ---------- Forwarded message ---------- >> Date: Sat, 23 Mar 2002 17:38:02 -0800 >> From: Lucky Green <shamrock(a)cypherpunks.to> >> To: cypherpunks(a)lne.com >> Subject: 1024-bit RSA keys in danger of compromise >> >> As those of you who have discussed RSA keys size requirements with me >> over the years will attest to, I always held that 1024-bit RSA keys >> could not be factored by anyone, including the NSA, unless the opponent >> had devised novel improvements to the theory of factoring large >> composites unknown in the open literature. I considered this to be >> possible, but highly unlikely. In short, I believed that users' desires >> for keys larger than 1024-bits were mostly driven by a vague feeling >> that "larger must be better" in some cases, and by downright paranoia in >> other cases. I was mistaken. >> >> Based upon requests voiced by a number of attendees to this year's >> Financial Cryptography conference <http:/www.fc02.ai>, I assembled and >> moderated a panel titled "RSA Factoring: Do We Need Larger Keys?". The >> panel explored the implications of Bernstein's widely discussed >> "Circuits for Integer Factorization: a Proposal". >> http://cr.yp.to/papers.html#nfscircuit >> >> Although the full implications of the proposal were not necessarily >> immediately apparent in the first few days following Bernstein's >> publication, the incremental improvements to parts of NFS outlined in >> the proposal turn out to carry significant practical security >> implications impacting the overwhelming majority of deployed systems >> utilizing RSA or DH as the public key algorithms. >> >> Coincidentally, the day before the panel, Nicko van Someren announced at >> the FC02 rump session that his team had built software which can factor >> 512-bit RSA keys in 6 weeks using only hardware they already had in the >> office. >> >> A very interesting result, indeed. (While 512-bit keys had been broken >> before, the feasibility of factoring 512-bit keys on just the computers >> sitting around an office was news at least to me). >> >> The panel, consisting of Ian Goldberg and Nicko van Someren, put forth >> the following rough first estimates: >> >> While the interconnections required by Bernstein's proposed architecture >> add a non-trivial level of complexity, as Bruce Schneier correctly >> pointed out in his latest CRYPTOGRAM newsletter, a 1024-bit RSA >> factoring device can likely be built using only commercially available >> technology for a price range of several hundred million dollars to about >> 1 billion dollars. Costs may well drop lower if one has the use of a >> chip fab. It is a matter of public record that the NSA as well as the >> Chinese, Russian, French, and many other intelligence agencies all >> operate their own fabs. >> >> Some may consider a price tag potentially reaching $1B prohibitive. One >> should keep in mind that the NRO regularly launches SIGINT satellites >> costing close to $2B each. Would the NSA have built a device at less >> than half the cost of one of their satellites to be able to decipher the >> interception data obtained via many such satellites? The NSA would have >> to be derelict of duty to not have done so. >> >> Bernstein's machine, once built, will have power requirements in the MW >> to operate, but in return will be able to break a 1024-bit RSA or DH key >> in seconds to minutes. Even under the most optimistic estimates for >> present-day PKI adoption, the inescapable conclusion is that the NSA, >> its major foreign intelligence counterparts, and any foreign commercial >> competitors provided with commercial intelligence by their national >> intelligence services have the ability to break on demand any and all >> 1024-bit public keys. >> >> The security implications of a practical breakability of 1024-bit RSA >> and DH keys are staggering, since of the following systems as currently >> deployed tend to utilize keys larger than 1024-bits: >> >> - HTTPS >> - SSH >> - IPSec >> - S/MIME >> - PGP >> >> An opponent capable of breaking all of the above will have access to >> virtually any corporate or private communications and services that are >> connected to the Internet. >> >> The most sensible recommendation in response to these findings at this >> time is to upgraded your security infrastructure to utilize 2048-bit >> user keys at the next convenient opportunity. Certificate Authorities >> may wish to investigate larger keys as appropriate. Some CA's, such as >> those used to protect digital satellite content in Europe, have already >> moved to 4096-bit root keys. >> >> Undoubtedly, many vendors and their captive security consultants will >> rush to publish countless "reasons" why nobody is able to build such a >> device, would ever want to build such a device, could never obtain a >> sufficient number of chips for such a device, or simply should use that >> vendor's "unbreakable virtual onetime pad" technology instead. >> >> While the latter doesn't warrant comment, one question to ask >> spokespersons pitching the former is "what key size is the majority of >> your customers using with your security product"? Having worked in this >> industry for over a decade, I can state without qualification that >> anybody other than perhaps some of the HSM vendors would be misinformed >> if they claimed that the majority - or even a sizable minority - of >> their customers have deployed key sizes larger than 1024-bits through >> their organization. Which is not surprising, since many vendor offerings >> fail to support larger keys. >> >> In light of the above, I reluctantly revoked all my personal 1024-bit >> PGP keys and the large web-of-trust that these keys have acquired over >> time. The keys should be considered compromised. The revoked keys and my >> new keys are attached below. >> >> --Lucky Green > > >

1 0

RE: PacBell Security/Abuse contact
by Joe Blanchard 25 Mar '02

25 Mar '02

Pacbell's Abuse/Security Depts are totally useless with regard to assisting its own customers, let alone defending them. For the better portion of a few months now, I've emailed/called many times with regard to CodeRed boxes (On their netblocks) and have yet to see them take any action. Anyone I talked with there indicated, after giving them the offending IPs, that someone would contact the customer and get it resolved. To date nothing has been done. I still see the same anonying IPs looking for codered stuff on my Apache systems. I won't even get started about the Caymen routers that have no password set on them, and the list of 30 of them I emailed to thier NOC/Abuse and a sales rep. That was over 3 months ago, and still they seem to be wide open, at least a few (I suspect someone changed them, probably were hacked given this amount of time.) I can understand their wanting to keep their customers anonymousness, but if they won't followup with them to (in this case help themselves) erraticate infected boxes that are on their business customer's DSL, doesn't that place them in the area of liability? Don't know, Just my 2¢s -Joe > ---------- > From: Jeremy T. Bouse[SMTP:Jeremy.Bouse@undergrid.net] > Sent: Sunday, March 24, 2002 11:11 PM > To: nanog(a)merit.edu > Subject: PacBell Security/Abuse contact > > > Anyone have a telephone number that can reach a live person > within Pacific Bell's Security/Abuse department? PacBell's technical > support is completely inept with trying to help their customers when > under any form of network attack other than passing you to a toll-free > number which informs you to send email to an address that goes without > answer. > > Respectfully, > Jeremy T. Bouse > UnderGrid Network Services >

2 1

RE: long distance gigabit ethernet
by LeBlanc, Jason 25 Mar '02

25 Mar '02

The new 15540 is a much better box, not much more $ either. There are some other people making extremely killer products, ONI being one that is very popular. I wouldn't invest in a 15454 anymore with all the new products out there, we still use them, but anything new will be a better box. > -----Original Message----- > From: Barton F Bruce [mailto:barton@cent.net] > Sent: Friday, March 22, 2002 5:17 PM > To: Antony; Greg Pendergrass > Cc: Richard A Steenbergen; 'Nanog@Merit. Edu' > Subject: Re: long distance gigabit ethernet > > > > The Cerent 454 (now cisco 15454) has 2 port Gig-E cards that > cost a little > more than a PA-GE card. The pair of ports shares OC-12 > available to that > slot (I'm assuming this is NOT an OC-192 equipped shelf) and > the bandwidth > can be split in certain multiples of STSes (OC-1), or used > totally for one > port. You only need as many STSes between boxes as you want to use. > > You can play some nice games with 802.1Q VLANs and multiple > sites, too. > > There is a newer 4 port Cerent gig-E card I have not seen, > but that probably > can do a FULL gig-E on at least 2 of the ports (i.e. use a > full OC-48 if the > box has the OC-192 cross connect matrix installed). This > newer card I think > is only for point to point and does not "understand" VLANS, > though probably > can carry them. > > Some DWDM boxes have their own gig-E ports. We have Sycamore > ones that give > us several Boston, NYC, and Reston routers on the same ethernet. > Consider also that many switches support what cisco calls > ether-channel. If > one gig-E isn't enough, add more in parallel. Any router on > this "ethernet" > can freely talk to any other. > > You are not stuck with just one router talking to one at the > other end. > > ----- Original Message ----- > From: "Antony" <antony(a)phenome.org> > To: "Greg Pendergrass" <greg(a)band-x.com> > Cc: "Richard A Steenbergen" <ras(a)e-gerbil.net>; "'Nanog@Merit. Edu'" > <nanog(a)merit.edu> > Sent: Friday, March 22, 2002 12:28 PM > Subject: Re: long distance gigabit ethernet > > > > > > On Fri, Mar 22, 2002 at 11:54:05AM -0500, Greg Pendergrass wrote: > > > > > > I'm going to take a stab and assume that you're actually > more interested > > > in finding a longhaul line with GigE on the ends, and not > so much how > many > > > miles you can get with whatever optics... > > > > > > Absolutely right, I don't care what's in between as long > as I have GigE > at > > > the end. Other options include using wave (too > expensive), or ethernet > over > > > MPLS (worth considering although latency may be too high > for longer that > > > 1000 miles). > > > > there are solutions of this type. SURFNet line, currently > used for test > > and network research is an example. > > It is from Amsterdam to Chicago. It is presented as GigE at > the ends. > > > > So fairly long distance, RTT is 93 msec.Actually it terminate as > > SONET OC48 that goes too TDM Switch which has GigE interfaces. > > So there is SONET encapsulation in the middle. In theory we can get > > upto 2.5Gbps. > > > > Line is provided by Teleglobe. End equipements are > > CISCO, ONS 15454. This don't do any routing. > > > > This page may be interesting to browse. > > http://carol.wins.uva.nl/~delaat/optical/index.html > > > > You can probably find different variants of such non > standard technology > > from other carriers. > > > > -antony > > > >

1 0

Possible New type of DOS attack
by Vinny India 25 Mar '02

25 Mar '02

Anyone out there ever witness an attack were you received several RSHPORT attempts (5 per second) on a cisco router from different spoofed source addresses. It was capable of taking out BGP and OSPF sessions on the router.

2 1

Wanted: Liebert AC Unit
by Gary Attard 25 Mar '02

25 Mar '02

I realize this is not necessarily the most appropriate forum to search for a used five(5) or ten(10) ton Liebert AC Unit but it may be the most effective. I am looking for a used 5 and 10 ton unit for raised floor Data Center - anyone know of any recently closed Data Centers looking to liquidate? Gary Attard-Director of Technical Support Invision.com Inc. http://www.invision.com Phone: (631) 543-1000 x306 Fax: (631) 964-8896 E-Mail: garya(a)invision.net

1 0

Re: PacBell Security/Abuse Contact
by Eric Brandwine 25 Mar '02

25 Mar '02

>>>>> "db" == David Barak <thegameiam(a)yahoo.com> writes: db> Regarding securiy issues, I'd suggest working with db> UUNet/Worldcom (or whatever AS701 is called lately). db> I've seen some of their folks work closely with db> aggrieved victims of DDOS attacks. I was going to say the same thing, but I'm probably not as believeable. ;) And it's UUNET. It'll remain UUNET until they turn off the last router. ericb -- Eric Brandwine | UNIX was never designed to keep people from doing stupid UUNetwork Security | things, because that policy would also keep them from ericb(a)uu.net | doing clever things. +1 703 886 6038 | - Doug Gwyn Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E

2 1

RE: Yipes
by CARL.P.HIRSCH＠sargentlundy.com 25 Mar '02

25 Mar '02

How's Cogent looking these days? They, along with Yipes, were always trying to get meetings with me. -carl "Daniel Golding" To: "'Allan Liska'" <allan(a)allan.org>, <nanog(a)merit.edu> <dgolding@soc cc: keye.com> Subject: RE: Yipes Sent by: owner-nanog@m erit.edu 03/24/02 11:02 PM They aren't the only ones.... http://www.washtech.com/news/telecom/15783-1.html Aleron, new owner of Telia USA aka AGIS, has also filed for Chapter 11. - Daniel Golding > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Allan Liska > Sent: Saturday, March 23, 2002 2:12 PM > To: nanog(a)merit.edu > Subject: Yipes > > > > Hello, > > Almost a year ago Ralph Los asked the following: > > "2. They're not funded yet, and selling WAY below cost. Does this > mean that a year from now they're going to triple their prices? > worse?" > > Yesterday they declared bankruptcy: > http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2002/0 3/23/BU240955.DTL&type=business Ralph -- if you are still around, I hear Miss Cleo is hiring :). allan -- allan allan(a)allan.org http://www.allan.org

1 0

RE: PacBell Security/Abuse contact
by LeBlanc, Jason 25 Mar '02

25 Mar '02

I agree. > -----Original Message----- > From: Jon Mansey [mailto:jon_mansey@verestar.com] > Sent: Monday, March 25, 2002 12:17 PM > To: Cheung, Rick > Cc: nanog(a)merit.edu > Subject: Re: PacBell Security/Abuse contact > > > > UUnet, excellent responsive abuse team IMHO. > > jm > > On Monday, March 25, 2002, at 12:12 PM, Cheung, Rick wrote: > > > Does anyone have an opinion on a decent ISP out > there that's > > proven to work with the customer during a DDOS storm? > > > > > > Rick Cheung > > > > -----Original Message----- > > From: Jeremy T. Bouse [mailto:Jeremy.Bouse@undergrid.net] > > Sent: Monday, March 25, 2002 2:46 PM > > To: nanog(a)merit.edu > > Subject: Re: PacBell Security/Abuse contact > > > > > > > > More specifically I belive this is a Distributed > Reflection DoS > > like what hit GRC.COM back on Jan 11th... Basically a flood of SYN > > packets to well known ports from IPs which appear to be > spoofed. I've > > actually been riding it out now for over 2 weeks... > > > > The tech support is completely inept and trying to contact > > security/abuse is pointless. Final realization of this was > when I was > > investigating another PacBell customers box which had been > compromised > > via another PacBell customer machine. After the forensics > to get back > > logs and track the intrusion I tried contacting PacBell to > no avail and > > then resulting it tryin to get in contact with their > customer directly. > > Which I managed to do and resolve the issue... I've never dealt with > > such an inept company before. > > > > Jeremy > > > > On Mon, Mar 25, 2002 at 11:18:23AM -0800, Daniel M. Spielman wrote: > > > > > > At 11:11 PM 3/24/2002 -0800, you wrote: > > > > > > > Anyone have a telephone number that can reach a > live person > > > >within Pacific Bell's Security/Abuse department? > PacBell's technical > > > >support is completely inept with trying to help their > customers when > > > >under any form of network attack other than passing you > to a toll-free > > > >number which informs you to send email to an address > that goes without > > > >answer. > > > > > > > > Respectfully, > > > > Jeremy T. Bouse > > > > UnderGrid Network Services > > > I've had a similar experience with their tech > team. I was being > > > dos'd from a college in Chicago so I contacted them to > have it filtered > > out > > > and they had no idea what I meant. They suggested I email > the Admin at > > the > > > college to get it resolved. I started screaming at them > how am i going > > to > > > email someone when I am being attacked. Then they > transferred me to > > their > > > supervisor who was even more inept then they were. > Frankly i gave up and > > > just waited out the dos attack which lasted 2 1/2 days. > > > > > >

1 0

Re:PacBell Security/Abuse Contact
by David Barak 25 Mar '02

25 Mar '02

Regarding securiy issues, I'd suggest working with UUNet/Worldcom (or whatever AS701 is called lately). I've seen some of their folks work closely with aggrieved victims of DDOS attacks. -David Barak "Quis custodes ipsos custodiet?" - Juvenal Rick Cheung wrote: Does anyone have an opinion on a decent ISP out there that's proven to work with the customer during a DDOS storm? __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards� http://movies.yahoo.com/

1 0

PacBell Security/Abuse contact
by Jeremy T. Bouse 25 Mar '02

25 Mar '02

Anyone have a telephone number that can reach a live person within Pacific Bell's Security/Abuse department? PacBell's technical support is completely inept with trying to help their customers when under any form of network attack other than passing you to a toll-free number which informs you to send email to an address that goes without answer. Respectfully, Jeremy T. Bouse UnderGrid Network Services

2 2