On Fri, 11 Jul 1997, Steve Schear wrote:

...

...

Remember "the internet interprets censorship as damage and routes around it"? I'd be happy with an internet that interprets DAMAGE as damage and routes around it.

It does.. It's just that when you lose a *large* access point, the impact is significant. (I think that's what happened here...)

Seems to me that having only a few, heavily trafficed, NAPs is a topological weakness in the Net which needs to be delt with soon.

Quite true, but the other main problem, that of major routers dropping lots of packets during high traffic times (basically, anytime from noon eastern until about 8 eastern is horrible, and it tends to pick up a little after that I think, but it stays bad until after about midnight eastern from what I've been able to tell), remains completely unresolved. Some initiatives are in the planning stages to deal with these things, but the sheer number of routes on the net at this point is a problem. Of course, MCI's horrible ATM <-> IP interface is a major point of congestion at this point, at least from my connection here at school. Ryan Anderson - <Pug Majere> "Who knows, even the horse might sing" Wayne State University - CULMA "May you live in interesting times.." randerso@ece.eng.wayne.edu Ohio = VYI of the USA PGP Fingerprint - 7E 8E C6 54 96 AC D9 57 E4 F8 AE 9C 10 7E 78 C9 -----------------------------------------------------------------------

Remember "the internet interprets censorship as damage and routes around it"?

No, the Internet interprets cocksucker John Gilmore as censorship, shits on him, and routes around him. :-) ObCrypto: I was offered a 76GB changer for $350. I thought of the following demo application: a user e-mails a piece of a Unix passwd file (password+salt) to a server, which looks up a password that works. Problem is, 76GB doesn't seem sufficient for the lookup table. :-( (Assume infinite time available on a fast box.) --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

Paul Bradley <paul@fatmans.demon.co.uk> writes:

...

ObCrypto: I was offered a 76GB changer for $350. I thought of the followin demo application: a user e-mails a piece of a Unix passwd file (password+sa to a server, which looks up a password that works. Problem is, 76GB doesn' seem sufficient for the lookup table. :-( (Assume infinite time available on a fast box.)

I have to confess ignorance over the form of the password in the unix passwd file, how much salt is used, does it vary from ?nix to ?nix or is it pretty standard? Maybe a small(ish) lookup table/ dictionary attack could be mounted using this.

Suppose that 'foo' is a valid password for the account 'bar'. Unix computes crypt(3)[similar to DES] using 8 bytes of zeros as the plaintext and the password (56 bits) and the 'salt' (the 12-bit time-stamp of when the password is set) as the key. Then it stores the salt and the (64-bit) result of crypt, often in a place where regular users can read it. When some program wants to verify that 'baz' is indeed a password for 'foo', it extracts the salt and the encrypted string from the password database, computes crypt(3) of salt (from the database) + the password being tried, and sees if it matches the encryption result in the database. This was designed by Robert Morris Sr [who really deserves more fame than being the father of Robert Morris Jr of the worm fame] and Ken Thompson. The purpose of the pseudo-random 'salt' is to make sure that if two accounts have the same password, they'll still have different encryption strings in the database (almost always). Thus, given 12+64 bits of input, we want to get the 56 bits of output; and the vast majority of 12+64 inputs can't happen. A well-known attack (implemented by widely available programs such as "crack") is to try various words from a dictionary with the 'salts' used by the traget account(s) (usually using not the (slow) crypt(3) from the library, but a highly optimized version of it. [The guy who wrote the "Camel" Perl book got caught doing this at a place where he worked as a consultant, and was prosecuted and convicted.] To prevent dictionary attacks, many sites no longer make the encrypted strings "easily" available to users; programs must use an API to check if a supplied password matches. Unix admins call this "password shadowing". --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps