December 2003 - cypherpunks-legacy

Re: DES-Busting Screen Savers?
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 5:02 PM 7/23/96, Lucky Green wrote: >At 15:53 7/23/96, Timothy C. May wrote: > >>Or several times that number of machines or time for machines with less >>crunch. Say, 100K Pentium-type machines for a month or two. How might this >>be gotten? >> >>A while back I proposed one approach: a brute force "screen saver" for >>Windows machines. Other platforms, maybe, but the most cost-effective thing >>to do is to go after the Windows market only. > >A friend of mine actually wrote an RC4-40 cracking screen saver during the >initial RC4 crack. We finished the brute force so quickly that he never >released the software. > Too bad. Properly modularized software, i.e., with a place to drop in the specific system/algorithm being attacked, could be adapted quickly to DES-busting, or whatever. If your friend still has this, and it's not just spaghetti code, maybe he can adapt it to a truly large-scale attack. BTW, sitting in my hot tub last night I quickly reconstructed the math for the "random" keyspace inefficiency: -- Imagine that N users are "randomly" picking chunks of keyspace to search. That is, they are not coordinating with others to avoid duplication. -- By the time the total amount of computons expended has equalled the amount that would have been expended in a "no duplications" allocated search, the Poisson probability distribution says that 1/e = 36.8% of the keyspace will not have been searched; the rest of the probabilty lies in keyspace searched once, twice, three times, etc. -- Thus, the calculation will have to go 2-4 times longer to give a high (>95%) chance that the answer is found. For example, at 3 times the "efficient" search time, there is only a 1/e^3 = 5% chance that nobody has found the answer The probabalistic assignment is less efficient, obviously, but has the advantage of not requiring a registry of keyspace allocations. Further, "denial of service" attacks (lying about having searched a chunk, or incorrectly searching or reporting) are not a problem. --Tim May Boycott "Big Brother Inside" software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Licensed Ontologist | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

3 2

Re: Bare fibers
by jim bell 17 Dec '03

17 Dec '03

At 05:19 PM 7/23/96 -0400, Rabid Wombat wrote: >> It occurs to me that a bare fiber could actually be (randomly) hung across >> treetops, roofs, power lines, and various other structures, over a >> many-block distance in suburban areas. Such a fiber wouldn't be protected >> very well, but it would probably last a few months. It would also be >> exceedingly hard to find its terminations, and tracing it would be a real >> pain. (It probably wouldn't be visible against a bright sky more than a >> meter or two away.) > >It also would have little structural integrity - if you attached it to >trees, which sway in the wind, you'd have a broken fiber in a short time. >(The fiber doesn't even need to break, per se; microscopic cracking, >usually at the cladding, will ruin your fiber) (bird strikes would also be >a big problem, mostly for the bird) But how long? I don't doubt that the effects you describe will occur, but I'm only talking about a _semi_-permanent installation. My guesstimate (months) was based on the idea that the fiber would be short (say, less than a kilometer)enough so that even accelerated loss (microcracking) wouldn't appreciably degrade the transmission. Also, I'm assuming that the fiber would be hung with enough slack so that swaying/growing trees wouldn't stretch the fiber appreciably. >ob crypto/privacy: Anybody have a good idea for detecting a tap on >exterior fiber? I'd expect an attacker to have to interupt connectivity, >terminate both ends of a break, and insert an active device. Thoughts? They can tap a fiber by bending it over a small radius, which causes leakage around the OD without appreciably interrupting the signal. Changes are pretty good that this would b e the technology used. Jim Bell jimbell(a)pacifier.com

1 0

Re: DAM_lin
by jim bell 17 Dec '03

17 Dec '03

At 02:10 PM 7/23/96 GMT, John Young wrote: > 7-23-96, WaPo: > > "The Cryptography Wars." Op-Ed By Kenneth W. Dam and > Herbert S. Lin > Indeed, only a fully open > and inclusive public discussion can lead to the national > consensus upon which any successful cryptography policy > will depend. > http://jya.com/damlin.txt (6 kb) I've pointed out (primarily to Sternlight) that the whole concept of referring to it as a "cryptography _policy_" biases the discussion. "Policies," in this usage, are the functions of governments. Countries don't necessarily have any need to have a "policy" on cryptography. In fact, one could argue that in a country where freedom of speech is in effect, no sort of restrictive "policy" has any place. Jim Bell jimbell(a)pacifier.com

1 0

re:SHI_fty
by Vinnie Moscaritolo 17 Dec '03

17 Dec '03

>jya(a)pipeline.com (John Young) writes: > >> "Microsoft Sees A Major Shift For Computers." John Markoff >> >> MS is preparing to release new software that would bring >> the most fundamental change to personal computers since >> the machines were invented in the 1970's. > Uh I think apple had that for a while, it's called cyberdog http://cyberdog.apple.com screw this ole fud. Vinnie Moscaritolo Developer Tech Support http://www.vmeng.com/vinnie/ Fingerprint: 4FA3298150E404F2782501876EA2146A

1 0

Ross Anderson's Eternity service
by Hal 17 Dec '03

17 Dec '03

Sherry Mayo posted here a while back a reference to Ross Anderson's Eternity service paper, <URL: http://www.cl.cam.ac.uk:80/users/rja14/#Lib >. He is also giving an invited talk on the subject this fall at a crypto conference in Prague. The goal of the Eternity service is to make published information permanently and ineradicably available, despite efforts on the part of powerful attackers to destroy it. The attack model explicitly includes governments. This has obvious relevance to current controversies involving copyright, trade secrets, etc. It's difficult to evaluate the proposal because many of the issues seem more legal than technical. Can a service like this, which would seemingly exist largely to circumvent legal restrictions on publishing, possibly be legal? Anderson's basic concept is of a network of storage servers in widely scattered jurisdictions. He uses cryptography so that although the servers store data, no single computer knows exactly what is stored in the encrypted files it holds. Keys to the data are spread across the network using secret sharing techniques, with mutual cooperation among the servers being necessary to decrypt files. (I believe the files themselves are redundantly stored on individual servers, but they are encrypted with keys which are split.) Anonymous communications are used among the network of computers to reply to requests, so that attackers can't tell which computer produced a requested document. The overall goal is apparently to arrange things so that each individual server has a level of deniability if they are accused of having provided information which is illegal in some jurisdictions. It can deny having produced any particular document in question, and if everything is designed properly it is not possible to prove otherwise (other than by subverting a bunch of the other servers). I won't try to go into much detail here (actually I found some of the crypto details kind of hard to follow in the paper, but I will write up my understanding if there is interest) but some of the other ideas are that the service would charge money enough to cover its costs and add new equipment as storage requirements increase (to prevent flooding attacks), and that requests would be submitted by broadcast to the network of servers, and information returned via a remailer network. The documents would be identified by some global names, and one of the documents would be an index file which identifies the others, with descriptions. A few questions for discussion: - Would it be possible in practice to run a network like this? - Would there be much interest in it among users? - Would it be a net benefit to society for such a service to exist? Hal

4 3

Announcing SecureDrive 1.4b
by edgar＠garg.campbell.ca.us 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This is to announce the availability of Version 1.4b of SecureDrive. SecureDrive Version 1.4b replaces version 1.4a, 1.4, 1.3d, and previous versions. Release 1.4b is a maintenance release of 1.4/a. No new function is added. Only modules SDCOMMON.C, SETENV.ASM and CRYPTDSK.C have non-cosmetic changes, which affect executables LOGIN.EXE and CRYPTDSK.EXE. For that reason, all other executables still self-identify as release 1.4. They are in fact the exact same EXE & COM files as release 1.4. 1.4b fixes problems setting PGPPASS from Windows 95, either inside Win95 from a DOS window, or from the DOS 7.0 environment outside Windows. Unfortunately, LOGIN still cannot activate SecureDrive decryption from inside a Win95 DOS window. This same fix also, for the first time, enables LOGIN to set PGPPASS (as well as activate SecureDrive) from inside a Windows 3.x DOS window. CRYPTDSK also contains added warning msgs for 1) attempting to encrypt drive C: and 2) interrupting en/decryption with Ctrl-Break. There are also some minor changes in SECDRV.DOC. In the USA, SecureDrive 1.4b is now available at Colorado Catacombs BBS - 303-772-1062 (up to 28,800 bps, 8n1) - log in with your own name or alias. Download SECDR14B.ZIP from the [F]ile menu. ftp://ftp.csn.net/mpj/USA/?????/disk/secdr14b.zip where the ????? is given in ftp://ftp.csn.net/mpj/README These are all controlled-access sites available to USA citizens and residents only. Thanks to the cooperation of Steve Crompton of the U.K., who worked with me closely, I am able to also announce availability on an offshore site, ftp://utopia.hacktic.nl/pub/replay/pub/disk/secdr14b.zip In case anyone in the U.S. Justice Dept. is reading this, Steve and I were very careful to do this release without violating US export restrictions. The only things I "exported" to Steve were "diffs" for source changes from 1.4a to 1.4b, which themselves don't contain any code capable of encryption or decryption. Steve combined those with source for 1.4a, already available overseas. Steve compiled the new source code, and sent the new EXE files to me. I compared the new executables to ones I compiled myself and verified they match, bit for bit. I then sent back to Steve detached signature files for the executables. Steve then put together secdr14b.zip and sent that to me for final inspection. I then compared all files against my "master" files here and verified that they matched. I then shipped the secdr14b.zip that Steve sent me to the USA sites. So the USA release matches bit for bit the offshore release. Here are the contents of secdr14b.zip Length Method Size Ratio Date Time CRC-32 Attr Name ------ ------ ----- ----- ---- ---- -------- ---- ---- 54081 DeflatX 19452 65% 07-20-96 19:45 8f807f09 --w- SECDRV.DOC 43718 DeflatX 20532 54% 07-20-96 20:12 21b5a5cb --w- LOGIN.EXE 42564 DeflatX 20333 53% 07-20-96 20:12 bdda692b --w- CRYPTDSK.EXE 32595 DeflatX 8786 74% 08-06-95 00:00 1c7d2225 --w- SECTSR.ASM 20623 DeflatX 4896 77% 07-20-96 19:34 f4c9ffda --w- CRYPTDSK.C 19664 DeflatX 4184 79% 11-19-93 21:42 22c2502c --w- CRYPT2.ASM 18598 DeflatX 4560 76% 07-20-96 19:41 7b2def07 --w- LOGIN.C 18321 DeflatX 6917 63% 06-14-93 22:27 0767480b --w- COPYING 15466 DeflatX 9750 37% 07-20-96 20:12 a90b90ff --w- FPART.EXE 14998 DeflatX 4111 73% 06-12-96 18:06 858fc2cb --w- SDCOMMON.C 13011 DeflatX 3073 77% 07-20-96 19:48 4fbda9fb --w- SETENV.ASM 12606 DeflatX 7634 40% 07-20-96 20:12 5b3023ad --w- COPYSECT.EXE 11557 DeflatX 3274 72% 05-09-93 19:38 e71f3eea --w- MD5.C 5278 DeflatX 3467 35% 11-14-95 20:52 af2f141c --w- KEY.ASC 4353 DeflatX 1721 61% 08-06-95 00:00 b4e99e6a --w- FPART.C 3656 DeflatX 1101 70% 08-06-95 00:00 6ed75bcc --w- SECDRV.H 3407 DeflatX 1105 68% 05-11-93 12:49 f1f58517 --w- MD5.H 2022 DeflatX 789 61% 08-06-95 00:00 dd3e9e64 --w- COPYSECT.C 2000 DeflatX 1324 34% 07-20-96 20:12 ba1568d1 --w- SECTSR.COM 1554 DeflatX 569 64% 08-06-95 00:00 3589f489 --w- MAKEFILE 1355 DeflatX 629 54% 01-21-94 08:44 db63ade4 --w- RLDBIOS.ASM 1254 DeflatX 543 57% 05-09-93 19:39 182978aa --w- USUALS.H 278 DeflatX 213 24% 12-06-95 20:33 6c13428c --w- FILE_ID.DIZ 152 Stored 152 0% 08-06-95 00:00 17b02bc2 --w- COPYSECT.SIG 152 Stored 152 0% 06-01-96 01:10 c195c865 --w- CRYPTDSK.SIG 152 Stored 152 0% 08-06-95 00:00 0b345a16 --w- FPART.SIG 152 Stored 152 0% 06-01-96 01:09 4cebe45a --w- LOGIN.SIG 152 Stored 152 0% 08-06-95 00:00 3817512c --w- SECTSR.SIG ------ ------ --- ------- 343719 129723 63% 28 Also note that the ZIP file contains PGP detached signatures (*.SIG) for the executable files. Finally here is my public key, also available on many public keyservers and on my home page (below); note who has signed it. Also please note my present Email addresses. Edgar W. Swank <edgar(a)Garg.Campbell.CA.US> Edgar W. Swank <Edgar_W._Swank(a)ilanet.org> Home Page: http://members.tripod.com/~EdgarS/index.html (Note: only Garg and ilanet addresses are currently valid. Garg is preferred.) Type bits/keyID Date User ID pub 1024/DA87C0C7 1992/10/17 Edgar Swank <edgar(a)Garg.Campbell.CA.US> sig E8E044BD Peter Herngaard <pethern(a)datashopper.dk> sig DA87C0C7 Edgar Swank <edgar(a)Garg.Campbell.CA.US> sig 4AAF00E5 Dave Del Torto <ddt(a)lsd.com> sig 32DD98D9 Vesselin V. Bontchev <bontchev(a)complex.is> sig 0F59323D Albert Yee <sa3189049(a)ntuvax.ntu.ac.sg> Edgar W. Swank <Edgar_W._Swank(a)ilanet.org> sig DA87C0C7 Edgar Swank <edgar(a)Garg.Campbell.CA.US> Edgar W. Swank <edgar(a)spectrx.sbay.org> sig 91E71221 Cruz <cruz(a)ccxbbs.uunet.ve> sig DA87C0C7 Edgar Swank <edgar(a)Garg.Campbell.CA.US> sig C0595F91 Ian H. Chan <ianchan(a)iti.gov.sg> sig 61130A1B Arnold L. Cornez, J.D. <arniec(a)dnai.com> sig 18239E91 Robert C.Casas <73763.20(a)compuserve.com> sig 4AAF00E5 Dave Del Torto <ddt(a)lsd.com> sig 08B707C5 Anton Sherwood <dasher(a)netcom.com> sig 32DD98D9 Vesselin V. Bontchev <bontchev(a)complex.is> sig 34D74DC1 Peter Simons <simons(a)petium.rhein.de> Edgar W. Swank <edgar(a)spectrx.saigon.com> sig 877AA661 Peter Simons *OLD KEY* <simons(a)peti.GUN.de> sig 4AAF00E5 Dave Del Torto <ddt(a)lsd.com> sig 3245BF5D Jeremy S. Anderson <jeremy(a)cctwin.ee.ntu.edu.tw> sig 08B707C5 Anton Sherwood <dasher(a)netcom.com> sig 32DD98D9 Vesselin V. Bontchev <bontchev(a)complex.is> sig FF67F70B Philip R. Zimmermann <prz(a)sage.cgd.ucar.edu> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAirfypkAAAEEAKe2jziPeFw6hY19clR2GtQ4gtGCSSVOTgPKEJzHfuC74Scf 9PEuu1kebLhHk43A9wo1vr52o4jpH/P/tnFmRtBQOMzLUzAt5rMucswtSVviMQS2 hBuc9yGJKWHVcyfA79EARKEYTdhx+2qKI+hFJcPE+rmD8wVoF94nNf3ah8DHAAUR tClFZGdhciBTd2FuayAgIDxlZGdhckBHYXJnLkNhbXBiZWxsLkNBLlVTPokAlQIF EDDoDMtzeIyX6OBEvQEBwiED/3qOECeAY1szZQVpOaSKQNSyPqnB8xwOJAryCNUE Pix2kjA0MG+dpJeLABUc17NX7FD8ZP5pfeYtXyIaV27Ls7/dSmpHYKCb/dV2o8QX CftwBteuetXy8OcE63hE6s1P1/tvo3iYPXvG4+MADfh1C4680Skx/RAzBHRNBEHA aDBaiQCVAwUQMNMNwd4nNf3ah8DHAQEs2wP8D7n1GMjYUvSA8aAWzdl37TEVnefX Qo5Y5Ns5dBNympYMcUseNC11hKiP/Po4w+Uso3saUfHasO+dtzOlkJVvUQkBlDlv HQDn4rbim1O1h0apM0uscsqBf5M4sx7fOq3NdH1FxKMbJkzoQX3SS8NEw0kfxq8M olFM1B5cklSgnjyJAJUDBRAwzGO6ocE4X0qvAOUBAUwKA/4pJAFciiDobMXRvVBr K00mSjGPNfrpxLBrEtKFFvnXmyWX//3qKBo7knJK1jWhsi2CHrnD1eYuhalk5QMH KAbRB45IALZ96VU6HFE9eG8kLdNCMqL1Z9zuWJIHSoTA8BJMGp9oJUQRVCR4EX4l Or2bC1zGBNYNiMshtCnbSX4Va4kAlQMFEDBmZEE2VpfGMt2Y2QEBEsID/0vobHvt D65LmaHQZzPd1fuZzxsKFXG5/dCwx60Qk624Yc7P1m1q+LY8KFuLtvSe1Ltn1dOp Q+eKOqdqh7z6BpywheHSwUPkA80QS9JIPFwj4FBBw5imvPihTG56TRfpDQn1kN2S laurx3SADtbohOZXuzT+uagk9OWl0/NQS/ubiQCVAwUQL5YBoVPK4mAPWTI9AQHF AQQAtjRStFaaWND/0ju+ciwcCvvHyQg8/EEXYekopHkDhHcnD7oSqQhvk/4P4CEa DMKC2U/BQVdmhoXjTH9LpdlxqLuxIkDD05NBAKJDiWaDcZDOXstHDsQB4X0R0SYn +l4fe0/Dhp+b7tLr0RTYr0A7X8bpi/w/X68V3EjBph556Me0LEVkZ2FyIFcuIFN3 YW5rICAgPEVkZ2FyX1cuX1N3YW5rQGlsYW5ldC5vcmc+iQCVAwUQMcEkft4nNf3a h8DHAQEQjQQAgQSNNO81LkGalLyQHZSdsUIitrDONnK4jg0y2xd3AyjmObbJvDCr UGGlC8CTh0OC9xqTGHVWrDDFPWsyUpzCPP6L5OqiJXllNNwExp8hkW7Xc8Qe5I9P 0foL2Xvc85B0s0ml6bBvdJi8VNVvdZRWgmoGLn+N2RAgboSFcpklcHe0J0VkZ2Fy IFcuIFN3YW5rIDxlZGdhckBzcGVjdHJ4LnNiYXkub3JnPokAlQMFEDCA7Ag0lND0 kecSIQEBogYD/AjSmPjE1aC41IWsRfxYUCRyXuTAdgt1KDbhhkTTM2S4KPCSraHu HNnI11oPRihyhW6CHomyrhHZ37gVxcKjPGJUIc5SkWX+BXmzuCx4PMtq3drON4qy Jb+qH0PVXU3YGDrphRkgjW90lotRItSe0453jc4/d7KvnnH9kW5Xw1gviQCVAgUQ LZj0qd4nNf3ah8DHAQFrQwP+OeVHrxlNzhC+SxfttzIUC3g+VALuM6gv8b+cyxl0 tlkwi6H9G8qmPh9nr2ppQZR5jHUhubfsek/QGi88UwOfuRPdh+ZDl/rU4kMcXvdY GT9clOLjzXmcLM7y9v8F4mFLsNtvFN2qWLsqne6hUI7EFn2ea/8ujdm7eoNlq7t8 CyuJAJUDBRAvTcc16RnkL8BZX5EBAc3hA/sH117w/Wk0k4dJf0QiaBpg1s1aoipl 1Qg8bmOEuKuv7jfsxHIU1b5Lge2nA1tYgWuLOe8riNwJ5fFOgiBOx8ZfZWMpsZzz dEsp3XZ+6zjIe0Yx+vHcwDNrLANHrhO50tL9vnU3Vn3iszpwGEWH/F4Jccv/JuD9 pHIplRGrTOHkDokAlQMFEC7KUw2GKKqoYRMKGwEBG7kEANXdWUGwnnEtW7mLd02n YozA759qDHaVx3QtM5YYB8bDV7iZh7F+/XYnoPj9hzF4Ha0nLcISPXDHBHhtq7Cs cYJn8DetJ71CMAe8Zd/+W/vOqCmUqORaMU/L1tqnvpOWUNnswOkzROzOmNpw+Kq4 L+oqBFuqJPDXQYYEFKOsvB9LiQCVAgUQLiSVP18k3sEYI56RAQG5TgQAnw9Wtc+G dGScZ48hvMWZABnUiAXThw+Tq79HdPu+IySNi7aRfkSeppn9QD6v2OS8ELatgkTS uGt4CpME6hLHB46fTiTdoXMdw+z092mOuqVF2qVKtswnFar5Fy4j0XK/4lEx2d2/ 1IpaTQ+sbicGH9CqCoWOKAy1j2Ly9Jf7ZgeJAJUCBRAt1dNBocE4X0qvAOUBAQdh A/kB2vTXCIjZGtOw/bC6gOTHnMPBVTQeXHIZ3BZ4xYRdMfdKsxN3gTezOI8QixQo HzhvNGB02fB5EdB8+Ulw9kn08AR2b+mTwkgeNtlytvNZ52E7UpWEVtznxlGeiwRM bOFIaGKJFsGXFSRw3F89ZqoUnoeRvRgL0kJIQOZCLF62ZYkAlAIFEC2o/S8YM6Fl CLcHxQEBHcsD9i0o2d7Q2rsG/iRRwapxGKQbHPxgQXCB6MLVNDEa3c/png8r2PA9 cOeRcwx2xY/XxNuZo7lHXNp/j5xwYhooq+yTBJIL8DZqW99QT8+c05vw7M1UCEpy 7NT1exkMzoVR/Y3jKbIa4X1tX1ZrdmoozxW0T3DwCcCZ7dR26eZXlx2JAJUCBRAt mw+uNlaXxjLdmNkBAULKA/4wqdMn2GCApAq+5kJT+iJmLvVeNZj0JVjWspGDcd+1 cjCK9XWVTATVtRAfWbDukoJ2wNzNuz7gbqVHHcrV7nvcQt3KUsxWRyahREklc75P tXBm0PKpr5TNTM2J/Kql28GXQQyL+PHawTDQVE8ybCPj+WUgK5qd1o/2QPxnb4EA mYkAlQIFEC2bGrAPRy9bNNdNwQEBhLAD/3vWoDu4msz4YA8BcnfuovI0ApDL5ekS u447ByXgIcqNRe4oDtGdvrqXvJhpyuj5t7vVDGtzgQE0jU8H6u+Ocpj1nBlOXL36 DASSaJuLErByNCzqTaGVya5WGxmK2m+pKS6UVIXitF2tGxrKu+Pdp3rkv3oPHTWV gFT5eGRvfJIKtClFZGdhciBXLiBTd2FuayA8ZWRnYXJAc3BlY3RyeC5zYWlnb24u Y29tPokAVQIFECu5dYOzvL/Jh3qmYQEBYDICAI5KdaTiPr2Y1OtRCTi6xMG6hnRN alvK9C5d/bxrKnUYqsfSpKayX+Ts9psmq6a6doOrX3AAtgcZuTCYUfQkd22JAJUC BRArlzITocE4X0qvAOUBAahdA/4rRoSVp3G+Ki0wvkcAvpnwt7vSEYpHXSkyoC8L dAqs9bft5NDTOykgw5H1qFG1Doqk6oR0yxY0k91eVoBVclLWDb94sNO3JjHJKO/Q dODik5DpmXEnQhBfLlujuYkCtJjoBv1+QdImnnv9aNidGuLAneNvZ+UNNqfE3IRS hzNw3IkAlQIFECwAALo04ip/MkW/XQEBmNQD/0jUVqT0LMoVvw7Zz2FXyWrdBn6b RlyGxeqQWhigDXRipZ824/fHbA2vkbAczEayw8ZpwRVmhWNsxxWhjYFIi92KYJbA P/XIbr+rEuTIhPKKKKhuuGLUWhfXhCFluHjs3CA6ZQwnT4jnu1NlCkcnWLbL4ktq ub2zLwrHCPUe31L1iQCUAgUQK9Y50xgzoWUItwfFAQHPrAPzBbf6lQyzwbUwdxay zLDoh3HygnunLooi+yzziEVQchOgSt3sLe2I108DLxTgp+26lJYTAZB+Gg8HGyB+ Nz6263D0XlVUXQi9/7CSRyd8bhYFeuFPwFzHPWZlyLDAIsuaEfBsmp2DBLgffvhU CqiiWYmP9oa+rOA+5IHS+xN8tIkAlQIFECtj5iw2VpfGMt2Y2QEBDEYD/2iMMml6 5eFaNWrNP7abYh8QW3+Mnjyl5CNpAjGkxejmIm4nZKqUHN5DuGzpJDnstRwbz6da XK15XcoM1m8guhu6UzIwHs9+hbKE6inTCz4C0mE55PSmvF/ejjexnGzsiFpuFnjN /sRrSHc57flOIUWBCZD8Hizz3aYBxmvwJ863iQCVAgUQKxEXHOJ13g7/Z/cLAQGy YgP/apcv9V2MbHFgU0hl0D4MLqGjBReUfDroxQCsgsTb/0nr1W9yltBMqYPgD7Th LAf2rxIPNbGyD7VUA27LTwQTS6n2mbtkHOvGQVw7J2GwTA6319Gf0Qne0M1h7VJW jFX0Vzjuh/nk6btxM2uTLSF2nUsDXe5/9N5XeesFhrbXNrM= =N7az - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMfT1Bt4nNf3ah8DHAQEFdwP/QYiBhqlP0K5YMqY6LIb4EQWy/ddZd4ji R5dwYRBxfErnb7h+3K4mtH/gFf/rznSDt5TONLIfaw2nGXx0nSpa9ANFbRhYaZTX GSaesh1wDQ0Z3/OZaKYpaKXbiZuprbBm0OEzTqb4IoTP4VpyYRrRly01lAtOClT/ IUX3I+irPoY= =24Ih -----END PGP SIGNATURE----- Edgar W. Swank <edgar(a)Garg.Campbell.CA.US> Edgar W. Swank <Edgar_W._Swank(a)ilanet.org> Home Page: http://members.tripod.com/~EdgarS/index.html

1 0

Re: Distributed DES crack
by Cerridwyn Llewyellyn 17 Dec '03

17 Dec '03

>I've a few machines around that could be dedicated almost full time to the >task. What are the bandwidth requirements? Specifically, could the >keycracker be run over a 28.8 (with a 486 running linux)? If so, how many >486's could I get over a single 28.8 (i.e. 28.8 -> multiple 486's daisy >chained with ppp over direct serial connection)? I imagine it would only need to report in every now and then with reports on the work it's accomplished, thus requiring very minimal bandwidth (unless you're the server, which would probably also do fine over 28.8). For that reason, you can have as many 486's as you can possibly own networked and cracking at the same time... For the record, I'm in, and have access to several mostly idle pentiums and a few sparc 10's ... =) //cerridwyn//

1 0

Re: Intel, Microsoft doing Internet Phone Software
by Duncan Frissell 17 Dec '03

17 Dec '03

At 10:47 AM 7/23/96 -0400, W Lee Nussbaum wrote: > >...see IDT's Net2Phone product, at http://www.net2phone.com/; it does >what you describe. Two notes: (1) I haven't used it yet; (2: disclosure) >I'm now employed by IDT, though in a different area. > > - Lee Subject of an Economist article: http://www.economist.com/issue/20-07-96/wb2.html DCF

1 0

Re: Digital Watermarks for copy protection in recent Billbo
by jim bell 17 Dec '03

17 Dec '03

At 08:08 PM 7/23/96 -0400, Alan Horowitz wrote: >> However, what is somewhat less >> well-known is the fact that in order to keep higher frequencies from being >> "aliased" (reflected to lower frequencies by heterodyne processes) it is >> necessary to remove (by filtering) any frequency content above that maximum, >> before sampling is done. > > Well, fudge sticks. That sounds like this thing called an "image" in >heterodyne analog RF receivers. I know how those work. Sampling produces essentially the same effect. >What is the physical basis for "aliasing" as you describe, in the >sampling theater of operations? Sampling a signal of frequency f1 at a rate of f2 produces two mixes, f1+f2 and f1-f2. The sum is sufficiently high that it isn't a concern, the difference could be. If you have an input containing frequencies up to 25 Khz, and you sample it at a rate of 40 kilosamples per second, the input frequency of 25 kilohertz gets mirrored down to 15 kilohertz, which is far lower than its original frequency. This is a problem! Some of the early voice-scramblers used this effect, heterodyning the audio band with a higher-frequency signal and reversing it, changing higher frequencies to lower and vice versa. Not particularly "secure" by today's standards, but it probably kept a few people from understanding what's going on. I've heard, however, that with practice you could learn to understand such frequency-inverted speech, as odd as it sounds. Jim Bell jimbell(a)pacifier.com

1 0

Re: Brute Force DES
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 12:41 AM 7/23/96 -0800, jim bell wrote: >Not that I think that such a dedicated chip necessarily exists; chances are >good that there isn't all that much demand for a 12-megabyte/second >encryptor. If you are running a 600 megabit/sec ATM/SONET link and want to encrypt it, you are in the market for a 75 megabyte/sec encryptor. As for dedicated crackers, according to my notes from the SAFE forum at Stanford, Eric Thompson said his company made FPGAs for cracking DES. A seven day crack for $1 million. ------------------------------------------------------------------------- Bill Frantz | Cave ab homine unius lebri | Periwinkle -- Consulting (408)356-8506 | [Beware the man of one | 16345 Englewood Ave. frantz(a)netcom.com | book] - Anonymous Latin | Los Gatos, CA 95032, USA

1 0