- cypherpunks-legacy - lists.cpunks.org

Announcing SecureDrive 2.4
by edgar＠highnrg.sbay.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This is to announce the availability of Version 1.4 of SecureDrive. SecureDrive Version 1.4 replaces version 1.3d and previous versions. Changes for 1.4 have added significant new function. New features include ability to use a keyfile either instead of or in addition to a passphrase, the /ADD function and the option to specify a drive letter, which is remembered, when specifying manual partition parameters to LOGIN. /ADD allows you to LOGIN multiple hard disk partitions (with the same key) at the same time. The subroutine which "finds" a physical hard disk partition based on the DOS drive letter has been improved, so hopefully situations where manual partition parameters must be used will be rare. Releases 1.3, 1.3a, 1.3d and 1.4 of Secure Drive are based on releases 1.0 and 1.1, mostly written by Mike Ingle <mikeingle(a)delphi.com> and version 1.2, with significant new code by myself. The code which we wrote is not copyrighted, but the program contains GNU Copylefted code, and therefore may be freely distributed under the terms of the GNU General Public Licence. See file COPYING for legalese. SecureDrive provides strong encryption via the IDEA cypher (The same symmetrical cypher used by PGP) for your files on diskettes or up to four hard disk partitions. You encrypt your diskettes and/or HD partitions with CRYPTDSK. Then you can access the data by using LOGIN and SECTSR. This provides "on-the-fly" decryption (and re-encryption) as disk sectors are accessed by your applications. Entering LOGIN /C or powering off your PC clears the crypto keys from memory and your encrypted disks are "instantly" secure. Mike Ingle and I have different opinions on the distribution of SecureDrive. Under the GNU General License (copyleft) I do not need Mike's permission to distribute version 1.4 and I have not asked for same. My policy on distribution is in the version 1.4 doc: Exporting this program. Cryptography is export controlled, and sending this program outside the country may be illegal. Don't do it. The "author" of versions 1.2 and 1.3, Edgar Swank, says that the export ban should not prevent you from placing this program on public BBS's and anonymous FTP sites in the US and Canada. If individuals outside the US/Canada use the internet or international long distance to obtain copies of the program, THEY may be breaking US law. Any such foreign individuals should be aware that US law enforcement may legally (under US law) apprehend individuals who break US laws even if such individuals are not on or even have never been on US soil. Such apprehension may remove such individuals directly to US jurisdiction without benefit of extradition proceedings in such individuals' home country(ies). SecureDrive Version 1.4 is already available for download on the following public BBS's as SECDR14.ZIP: Flying Dutchman (408)294-3065 Colorado Catacombs BBS, 303-772-1773 (up to 28,800 bps, log in with your own name, answer the questions, and download SECDR14.ZIP). ftp://ftp.csn.net/mpj/I_will_not_export/crypto_???????/disk/secdr14.zip see ftp://ftp.csn.net/mpj/README for the ??????? ftp://miyako.dorm.duke.edu/mpj/crypto/disk/secdr14.zip See ftp://miyako.dorm.duke.edu/pub/GETTING_ACCESS for access instructions. Here is the contents of SECDR14.ZIP Length Method Size Ratio Date Time CRC-32 Attr Name ------ ------ ----- ----- ---- ---- -------- ---- ---- 18321 DeflatX 6914 63% 06-14-93 22:27 0767480b --w- COPYING 2022 DeflatX 789 61% 08-06-95 00:00 dd3e9e64 --w- COPYSECT.C 12542 DeflatX 7670 39% 08-06-95 00:00 c089888f --w- COPYSECT.EXE 152 Stored 152 0% 08-06-95 00:00 17b02bc2 --w- COPYSECT.SIG 19664 DeflatX 4183 79% 11-19-93 21:42 22c2502c --w- CRYPT2.ASM 19622 DeflatX 4594 77% 08-06-95 00:00 14940d0b --w- CRYPTDSK.C 41834 DeflatX 19854 53% 08-06-95 00:00 2e5664b8 --w- CRYPTDSK.EXE 152 Stored 152 0% 08-06-95 00:00 484719f3 --w- CRYPTDSK.SIG 4353 DeflatX 1724 61% 08-06-95 00:00 b4e99e6a --w- FPART.C 15450 DeflatX 9790 37% 08-06-95 00:00 44c4a0e7 --w- FPART.EXE 152 Stored 152 0% 08-06-95 00:00 0b345a16 --w- FPART.SIG 2998 DeflatX 2113 30% 04-22-95 13:23 1a54cbe5 --w- KEY.ASC 18447 DeflatX 4526 76% 08-06-95 00:00 d9f91a8e --w- LOGIN.C 43476 DeflatX 20274 54% 08-06-95 00:00 39b32d3d --w- LOGIN.EXE 152 Stored 152 0% 08-06-95 00:00 cb182e12 --w- LOGIN.SIG 1554 DeflatX 568 64% 08-06-95 00:00 3589f489 --w- MAKEFILE 11557 DeflatX 3277 72% 05-09-93 19:38 e71f3eea --w- MD5.C 3407 DeflatX 1097 68% 05-11-93 12:49 f1f58517 --w- MD5.H 1355 DeflatX 629 54% 01-21-94 08:44 db63ade4 --w- RLDBIOS.ASM 14757 DeflatX 4050 73% 08-06-95 00:00 2142bf7c --w- SDCOMMON.C 52175 DeflatX 18701 65% 08-06-95 00:00 da0e2c45 --w- SECDRV.DOC 3656 DeflatX 1094 71% 08-06-95 00:00 6ed75bcc --w- SECDRV.H 32595 DeflatX 8860 73% 08-06-95 00:00 1c7d2225 --w- SECTSR.ASM 2000 DeflatX 1326 34% 08-06-95 00:00 ba1568d1 --w- SECTSR.COM 152 Stored 152 0% 08-06-95 00:00 3817512c --w- SECTSR.SIG 11519 DeflatX 2801 76% 08-06-95 00:00 060d33e8 --w- SETENV.ASM 1254 DeflatX 541 57% 05-09-93 19:39 182978aa --w- USUALS.H 276 DeflatX 248 11% 08-06-95 00:00 20880832 --w- FILE_ID.DIZ ------ ------ --- ------- 335594 126383 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; note who has signed it. (HighNRG is only address currently valid) Type bits/keyID Date User ID pub 1024/DA87C0C7 1992/10/17 Edgar W. Swank <edgar(a)HighNRG.sbay.org> Edgar Swank <edgar(a)Garg.Campbell.CA.US> Edgar W. Swank <edgar(a)spectrx.sbay.org> Edgar W. Swank <edgar(a)spectrx.saigon.com> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAirfypkAAAEEAKe2jziPeFw6hY19clR2GtQ4gtGCSSVOTgPKEJzHfuC74Scf 9PEuu1kebLhHk43A9wo1vr52o4jpH/P/tnFmRtBQOMzLUzAt5rMucswtSVviMQS2 hBuc9yGJKWHVcyfA79EARKEYTdhx+2qKI+hFJcPE+rmD8wVoF94nNf3ah8DHAAUR tClFZGdhciBXLiBTd2FuayAgIDxlZGdhckBIaWdoTlJHLnNiYXkub3JnPokAlQMF EC+W0kveJzX92ofAxwEB1rsEAIsfe/gJas0E9Ky+oA6I13Z4sjuECt+B9ouHFQ5m hvS5pVXCl4FM5ymMS9BaASK4nh1NK89bTtP0syGQId6G9K4YYphhuhNmIuoi6YCF G9DZo1ZseDMMcBwKMN1IMK06YhBFZXaaZGnAD9q+8IEwphqUCKQhZ+kz9np1DXI+ WleBtClFZGdhciBTd2FuayAgIDxlZGdhckBHYXJnLkNhbXBiZWxsLkNBLlVTPokA lQMFEC+SO/jeJzX92ofAxwEBCcwD/05FhVGTxYOsRjXjuEEWtndNhgX1fCpEKrtH 2kj7vnNLjZHYKqgFJhKKuu4T0RxYHweoM5zwMD0TaUlMZeeUHJTrCnS6MACf9UMS x5wdcNqptGL/LsErJudGXfEfiCtSyMtWchAuKHgE0Gxgac1yjx6LwB6RR32Mo39u V1rO3ncLtCdFZGdhciBXLiBTd2FuayA8ZWRnYXJAc3BlY3RyeC5zYmF5Lm9yZz6J AJUDBRAvTcc16RnkL8BZX5EBAc3hA/sH117w/Wk0k4dJf0QiaBpg1s1aoipl1Qg8 bmOEuKuv7jfsxHIU1b5Lge2nA1tYgWuLOe8riNwJ5fFOgiBOx8ZfZWMpsZzzdEsp 3XZ+6zjIe0Yx+vHcwDNrLANHrhO50tL9vnU3Vn3iszpwGEWH/F4Jccv/JuD9pHIp lRGrTOHkDokAlQMFEC7KUw2GKKqoYRMKGwEBG7kEANXdWUGwnnEtW7mLd02nYozA 759qDHaVx3QtM5YYB8bDV7iZh7F+/XYnoPj9hzF4Ha0nLcISPXDHBHhtq7CscYJn 8DetJ71CMAe8Zd/+W/vOqCmUqORaMU/L1tqnvpOWUNnswOkzROzOmNpw+Kq4L+oq BFuqJPDXQYYEFKOsvB9LiQCVAgUQLiSVP18k3sEYI56RAQG5TgQAnw9Wtc+GdGSc Z48hvMWZABnUiAXThw+Tq79HdPu+IySNi7aRfkSeppn9QD6v2OS8ELatgkTSuGt4 CpME6hLHB46fTiTdoXMdw+z092mOuqVF2qVKtswnFar5Fy4j0XK/4lEx2d2/1Ipa TQ+sbicGH9CqCoWOKAy1j2Ly9Jf7ZgeJAJUCBRAt1dNBocE4X0qvAOUBAQdhA/kB 2vTXCIjZGtOw/bC6gOTHnMPBVTQeXHIZ3BZ4xYRdMfdKsxN3gTezOI8QixQoHzhv NGB02fB5EdB8+Ulw9kn08AR2b+mTwkgeNtlytvNZ52E7UpWEVtznxlGeiwRMbOFI aGKJFsGXFSRw3F89ZqoUnoeRvRgL0kJIQOZCLF62ZYkAlAIFEC2o/S8YM6FlCLcH xQEBHcsD9i0o2d7Q2rsG/iRRwapxGKQbHPxgQXCB6MLVNDEa3c/png8r2PA9cOeR cwx2xY/XxNuZo7lHXNp/j5xwYhooq+yTBJIL8DZqW99QT8+c05vw7M1UCEpy7NT1 exkMzoVR/Y3jKbIa4X1tX1ZrdmoozxW0T3DwCcCZ7dR26eZXlx2JAJUCBRAtmw+u NlaXxjLdmNkBAULKA/4wqdMn2GCApAq+5kJT+iJmLvVeNZj0JVjWspGDcd+1cjCK 9XWVTATVtRAfWbDukoJ2wNzNuz7gbqVHHcrV7nvcQt3KUsxWRyahREklc75PtXBm 0PKpr5TNTM2J/Kql28GXQQyL+PHawTDQVE8ybCPj+WUgK5qd1o/2QPxnb4EAmYkA lQIFEC2bGrAPRy9bNNdNwQEBhLAD/3vWoDu4msz4YA8BcnfuovI0ApDL5ekSu447 ByXgIcqNRe4oDtGdvrqXvJhpyuj5t7vVDGtzgQE0jU8H6u+Ocpj1nBlOXL36DASS aJuLErByNCzqTaGVya5WGxmK2m+pKS6UVIXitF2tGxrKu+Pdp3rkv3oPHTWVgFT5 eGRvfJIKtClFZGdhciBXLiBTd2FuayA8ZWRnYXJAc3BlY3RyeC5zYWlnb24uY29t PokAlQIFECsRFxzidd4O/2f3CwEBsmID/2qXL/VdjGxxYFNIZdA+DC6howUXlHw6 6MUArILE2/9J69VvcpbQTKmD4A+04SwH9q8SDzWxsg+1VANuy08EE0up9pm7ZBzr xkFcOydhsEwOt9fRn9EJ3tDNYe1SVoxV9Fc47of55Om7cTNrky0hdp1LA13uf/Te V3nrBYa21zaz =LWNj - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMD9Snt4nNf3ah8DHAQFVOAP5AQPD3TESTabv35I7yBtmMFYS5VDoQB5M 7Lxz3YbDDLr15vCzKcCe58KbCit+XqL11YjQcWXFjlYY83ouIxwIWRb0AEOQq2NC MRxIC61DGLcb2ry0UCKhD5Szj9QCJE/sF3Zx9EiuKDYu0Xbx8zKv4zTpdyO1CMQS sw/NA3PbzX8= =jv0o -----END PGP SIGNATURE----- --- edgar(a)HighNRG.sbay.org Keep Freestyle Alive!

1 0

oops, re last message
by Donald M. Kitchen 17 Dec '03

17 Dec '03

Sorry to add another msg to the clutter, but please send responses to the previous message (DNS keyserver) to me at don(a)cs.byu.edu and NOT at root at _any_ system. Don

1 0

List of reliable remailers
by Raph Levien 17 Dec '03

17 Dec '03

I operate a remailer pinging service which collects detailed information about remailer features and reliability. To use it, just finger remailer-list(a)kiwi.cs.berkeley.edu There is also a Web version of the same information, plus lots of interesting links to remailer-related resources, at: http://www.cs.berkeley.edu/~raph/remailer-list.html This information is used by premail, a remailer chaining and PGP encrypting client for outgoing mail, which is available at: ftp://ftp.csua.berkeley.edu/pub/cypherpunks/premail/premail-0.33.tar.gz For the PGP public keys of the remailers, as well as some help on how to use them, finger remailer.help.all(a)chaos.taylored.com This is the current info: REMAILER LIST This is an automatically generated listing of remailers. The first part of the listing shows the remailers along with configuration options and special features for each of the remailers. The second part shows the 12-day history, and average latency and uptime for each remailer. You can also get this list by fingering remailer-list(a)kiwi.cs.berkeley.edu. $remailer{"vox"} = "<remail(a)vox.xs4all.nl> cpunk pgp. post"; $remailer{"avox"} = "<anon(a)vox.hacktic.nl> cpunk pgp post"; $remailer{"extropia"} = "<remail(a)extropia.wimsey.com> cpunk pgp special"; $remailer{"portal"} = "<hfinney(a)shell.portal.com> cpunk pgp hash"; $remailer{"alumni"} = "<hal(a)alumni.caltech.edu> cpunk pgp hash"; $remailer{"bsu-cs"} = "<nowhere(a)bsu-cs.bsu.edu> cpunk hash ksub"; $remailer{"rebma"} = "<remailer(a)rebma.mn.org> cpunk pgp. hash"; $remailer{"c2"} = "<remail(a)c2.org> eric pgp hash reord"; $remailer{"penet"} = "<anon(a)anon.penet.fi> penet post"; $remailer{"ideath"} = "<remailer(a)ideath.goldenbear.com> cpunk hash ksub reord"; $remailer{"hacktic"} = "<remailer(a)utopia.hacktic.nl> cpunk mix pgp hash latent cut post ek"; $remailer{"flame"} = "<remailer(a)flame.alias.net> cpunk mix pgp. hash latent cut post ek reord"; $remailer{"rahul"} = "<homer(a)rahul.net> cpunk pgp hash filter"; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord"; $remailer{"syrinx"} = "<syrinx(a)c2.org> cpunk pgp reord mix post"; $remailer{"ford"} = "<remailer(a)bi-node.zerberus.de> cpunk pgp"; $remailer{"hroller"} = "<hroller(a)c2.org> cpunk pgp hash mix cut ek"; $remailer{"vishnu"} = "<mixmaster(a)vishnu.alias.net> cpunk mix pgp hash latent cut ek ksub reord"; $remailer{"crown"} = "<mixmaster(a)kether.alias.net> cpunk pgp hash latent cut mix ek reord"; $remailer{"robo"} = "<robo(a)c2.org> cpunk hash mix"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{"spook"} = "<remailer(a)spook.alias.net> cpunk mix pgp hash latent cut ek reord"; $remailer{"rmadillo"} = "<remailer(a)armadillo.com> mix cpunk pgp hash latent cut"; $remailer{"ursula"} = "<ursula(a)cyberspace.org> cpunk"; $remailer{"ncognito"} = "<ncognito(a)gate.net> cpunk"; catalyst(a)netcom.com is _not_ a remailer. lmccarth(a)ducie.cs.umass.edu is _not_ a remailer. usura(a)replay.com is _not_ a remailer. Use "premail -getkeys pgpkeys(a)kiwi.cs.berkeley.edu" to get PGP keys for the remailers. Fingering this address works too. 21 Apr 1995: The new version of premail (0.33) is out, with direct posting, perl5 and better MH support, and numerous bug fixes. Last ping: Mon 28 Aug 95 6:00:57 PDT remailer email address history latency uptime ----------------------------------------------------------------------- portal hfinney(a)shell.portal.com *##*#*****+* 9:28 99.99% alumni hal(a)alumni.caltech.edu **********+* 11:12 99.99% hacktic remailer(a)utopia.hacktic.nl **+********* 11:54 99.99% spook remailer(a)spook.alias.net -+------+-- 2:28:52 99.99% hroller hroller(a)c2.org *##*-+*--*** 31:39 99.98% c2 remail(a)c2.org ++++-++--+++ 1:31:06 99.98% mix mixmaster(a)remail.obscura.com --..---.---- 6:57:01 99.98% crown mixmaster(a)kether.alias.net ------.--- 2:55:00 99.99% syrinx syrinx(a)c2.org ----------- 2:13:52 99.98% flame remailer(a)flame.alias.net ++++++++++++ 51:11 99.96% ideath remailer(a)ideath.goldenbear.com --.-.------ 4:57:42 99.95% bsu-cs nowhere(a)bsu-cs.bsu.edu -##+*+****++ 52:12 99.84% vishnu mixmaster(a)vishnu.alias.net ----------- 3:15:22 99.82% rmadillo remailer(a)armadillo.com +++++++++++* 1:34:11 99.67% vox remail(a)vox.xs4all.nl ---.-----. 17:32:05 99.99% ncognito ncognito(a)gate.net #+** 3:44 99.46% replay remailer(a)replay.com **+****_**** 44:17 99.34% penet anon(a)anon.penet.fi - -++-----++ 3:58:07 98.44% ursula ursula(a)cyberspace.org # * 3:37 97.42% rahul homer(a)rahul.net *#*++******* 5:12 99.99% extropia remail(a)extropia.wimsey.com ._.-__..-.. 20:21:39 89.74% ford remailer(a)bi-node.zerberus.de ****# **** 7:36 87.14% robo robo(a)c2.org -*** 55:42 55.73% rebma remailer(a)rebma.mn.org 9:53:43 1.99% For more info: http://www.cs.berkeley.edu/~raph/remailer-list.html History key * # response in less than 5 minutes. * * response in less than 1 hour. * + response in less than 4 hours. * - response in less than 24 hours. * . response in more than 1 day. * _ response came back too late (more than 2 days). cpunk A major class of remailers. Supports Request-Remailing-To: field. eric A variant of the cpunk style. Uses Anon-Send-To: instead. penet The third class of remailers (at least for right now). Uses X-Anon-To: in the header. pgp Remailer supports encryption with PGP. A period after the keyword means that the short name, rather than the full email address, should be used as the encryption key ID. hash Supports ## pasting, so anything can be put into the headers of outgoing messages. ksub Remailer always kills subject header, even in non-pgp mode. nsub Remailer always preserves subject header, even in pgp mode. latent Supports Matt Ghio's Latent-Time: option. cut Supports Matt Ghio's Cutmarks: option. post Post to Usenet using Post-To: or Anon-Post-To: header. ek Encrypt responses in reply blocks using Encrypt-Key: header. special Accepts only pgp encrypted messages. mix Can accept messages in Mixmaster format. reord Attempts to foil traffic analysis by reordering messages. Note: I'm relying on the word of the remailer operator here, and haven't verified the reord info myself. mon Remailer has been known to monitor contents of private email. filter Remailer has been known to filter messages based on content. If not listed in conjunction with mon, then only messages destined for public forums are subject to filtering. Raph Levien

1 0

Re: Florida Drivers Permits
by jpb＠shadow.net 17 Dec '03

17 Dec '03

>Better would be to figure out the encoding scheme and post it here. I like this, myself. It'd be nice to be able to have the picture of my choosing instead of a digitized thumbprint...

3 2

Turing test novel: "Galatea 2.2"
by lwp＠mail.msen.com 17 Dec '03

17 Dec '03

Reviewed in The New Yorker (August 21&28 issue) is the novel "Galatea 2.2" by Richard Powers, wherein a neural net is nurtured by an English Literature professor "to counterfeit human responses to the Master's Comprehensive Exam, which calls for the interpretation of set texts". The review makes me want to read this book. :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: Lou Poppler <lwp(a)mail.msen.com> | Doom an evil deed, :: :: http://www.msen.com/~lwp/ | liven a mood. :: ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

2 1

R.I.P. John Brunner
by abostick＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Science fiction writer John Brunner died last Friday, August 25, from a massive stroke, while attending the World Science Fiction Convention in Glasgow, Scotland. Among several other notable works, Brunner was the author of THE SHOCKWAVE RIDER, a groundbreaking vision of the information age that inspired and forsaw much that was pertinent to the Internet in general and the Cypherpunks in particular. Let us pause a moment to note his passing and honor his life and contributions. Alan Bostick | "Oh. You come to Heaven without a fortune?" Seeking opportunity to | "Yes." develop multimedia content. | "Unfortunate." Finger abostick(a)netcom.com | Roger Zelazny, LORD OF LIGHT for more info and PGP public key -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQB1AgUBMEIHReVevBgtmhnpAQG3IgL6A17RmOyCP/J4c/Dp5w1Qntv9/Ill90A/ OpulCQlBS4vBE5+yQ6nElJG0//13NNQ8/v73A/7hqeBEBZ6I0PG1rhdI8Iw5pqcd 74w4IYATmJ/YZe+IA/1GmqjwSohXcCbI =Tf1e -----END PGP SIGNATURE-----

1 0

Re: SSL trouble
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

I did a distributed scheme for something else that had two levels, a master and a group of slaves. Only the slaves talked to the master. For this effort I think a variation of the idea would be better. Have all of the brutes contact the master, who will, in the first transaction assign them to the next slave in a round-robin fashion. Then all of the transactions from that point would take place between the brute and the slave:) (Sounds kind of like Conan or the Princess Bride.) The slaves would each be delegated large chunks of the keyspace, but not keyspace/numslaves. Maybe 1/16th or something like that, and could ask for more when their space was depleted. Periodically, perhaps when requesting more key space, and/or when a timer pops, the slaves could report results. What I mean is that every so often they'd report even if they didn't need more keyspace yet, iff they had any new stats to report. The nice thing here is that the work of the master and of the slaves is almost the same. The slaves don't have to do the initial assignment of slave, and the master doesn't have to report results, but everything else is the same. With careful design you could use the same daemon for both with a command line argument to tell it if it was the master (-m) or the slave (-s). Of course I'm sure you see that this allows you to add as many levels as you want to the hierarchy. A slave doesn't care whether a slave or a brute talks to it. The only thing that changes with the levels is the max size of an allocated chunk. For each daemon it would be nice to have the minimum, maximum and default chunk size configurable. The master might have all three the same, since it would be expected to talk only to slaves. That doesn't mean you couldn't get more than, (for example), 16th of the keyspace to work on. It just means that you'd have to make more than one request. You could make the slave software available as well, and a site with many machines could have only the slave contact the master to get assigned a slave to talk to, and could configure all of their brutes to talk to their own slave. Software like this is easy to write, (and fun), and we should go for it:) Of course I do everything like this in C++, but I suppose perl would be the most portable. It's a shame it's so aethestically displeasing to the eye. perl's never a pleasant read. Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

3 3

SSL keyspace etc.
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

regarding SSL challenge, I am not following this close enough to understand completely, but I thought I would offer a few suggestions for tweaking the code: -- the issue of grabbing keyspace has been raised. what if someone malicious just yanked huge areas of keyspace and didn't search them? it seems that the clients need to return to the server some evidence that they have searched their keyspace in question. the server could verify this evidence. for those that don't return the "evidence", that keyspace could be reallocated to other comers. the simple approach to all this, if you don't have "evidence", is to just have the server keep reallocating the same space over and over to different crackers. hopefully eventually every part of the keyspace would be allocated to a "legitimate" worker. -- the issue of efficiency is very fascinating for this project. essentially the server has no idea what the block size of key blocks it should dole out. obviously the server would want to try to dole out equal *processing chunks* such that the remote machine reports back in a certain amount of time, no matter what architecture. the problem of course is that remote machines all have different efficiency. two possibilities: a sort of "bogomip" calculation is done in the client, and its processor speed is reported to the server. the server uses this in a calculation to determine how much to dole out. it could try to derive a best fit linear relationship between space covered and processor spead, or build up a table of results and interpolate for new requests. note that the efficiency issue also ties into "what if people take keys they don't solve". if the server knows roughly how long a client should take to report back, and it never reports back, it could then reallocate that key space. -- another problem of efficiency is that the server is clearly a bottleneck for servicing requests. the question arises: suppose that the server could determine the precise interval between which machines would go back to it for new keys. what is the optimum interval over the whole project? in other words, give the number of machines participating, and their processor speeds, what size of key space should be parceled out to the next request so that the bottleneck at the server is minimized? this optimum interval must be very hard to derive, because it depends on the contention based on many incoming connections. it would involve some probabilistic approximations of the likelihood of collisions. to model it, you might consider a request as taking [n] seconds of time, and consider that if any two requests are in contention, a retry happens after [m] seconds. you could build up models that would try to minimize the time based on empirical simulations. however I would be exceedingly impressed if someone could derive a formula for this, or give it from some textbook. -- adaptive algorithms for all these situations are possible. the server could use a "hypothesis" in the sense of partitioning out a starting size of keyspace, and then watch how long it took the client machine to respond, and then assume a linear relationship or something to compute the size of the next keyspace to hand out to the machine. the server could continually watch how closely its "hypothesis" (i.e. its estimations of how long a given machine will take) match the actual returns. -- more on the idea of evidence: we are working with a hashing algorithm, right? as evidence the client machines could return checksums of all the hashes of all the keyspace it searched. it could break up its own search space into blocks and return the checksums on the hashes for each block. the server, if it wanted to, could verify these blocks running its own computations. if it ever found a client was "unreliable", it could then diminish the keys sent to the unreliable client, or even send it areas of search space it didn't care about anymore (i.e. areas that have already been confirmed searched by a more "reliable" client). -- in fact all this reminds me of the process of intelligence gathering by an agency, which could be formalized as follows: suppose that the agency wishes to identify "quality information". it has a set of sources, A,B,C,D.... now, it can send questions out to these sources and get information from them. some of them however would be "unreliable". the agency must devise some means by which it can weed out the unreliable sources. note that this may even involve sending them bogus instructions to keep them busy so they do not themselves suspect they have been "discovered" and then change their defective plans. obviously, one of the most important intelligence tools in this matter is that of *correlation*. you have to determine "truth" (or "quality information") via the correlation between answers that the different sources give you. also important to correlation is *redundancy*. you sometimes have to ask more than one source the same question, and test the answer. in this model, if A and B give different answers, you know that one of A or B is "unreliable". what is very interesting in our case of cracking keys is that the server can verify the information on its own. in other words, it has a *control* that it knows is correct that it can judge against the answers "out there". unfortunately, in contrast, real intelligence agencies are not always privy to this kind of certain "control" and in fact have to determine "truth" entirely from a set of sources, any of which might be unreliable. in this case one has to have a hypothesis about what is the "truth" and test it to see if it holds up consistently with all information. the approaches of attackers are obvious. the most obvious is that of collusion and infiltration. but I will save the rest for some NSA spook to elaborate. there are certainly enough colluding and infiltrating on this list <g> -- one of the reasons all this interests me is that it really reminds me of some projects I have worked on in the past. in high school I wrote a network mandelbrot set program (client/host). the issue of contention arose and it appeared to me to look like an upside-down parabola after I plotted some points (curving up, that is). i.e. the optimum was at the pit of the parabola, and when too few or too many requests happened, the speed over the overall simulation was increased above the optimum. some very ingenious readers may actually be able to locate this code, which I put in the public domain over 5 years ago. -- another thing I worked on was trying to find the optimal block size of communications protocols such as Zmodem, which generally instead just pick arbitrary block sizes 2^n. I actually was able to attack this problem analytically through the observations of the properties of infinite series and calculus techniques. it is a similar problem but the idea of contention really complicates this issue. (for what I studied, there was only one client and one server, so to speak). I still have this paper in Latex format and if anyone is interested I would be happy to send it to you. it's a really nice example, IMHO, of how if you use your brain and some mathematics, you can really get a far more elegant approach than brute force, and know with much greater certainty that what you are doing makes sense mathematically. an awful lot of programmer just tend to bang on the keyboard with out thinking of the theoretical implications of their work. this is understandable given that the theoretical implications of even trivial programs (such as the SSL client/server interactions) can be mathematically extremely daunting, requiring even differential equations to model fairly simple pieces of code. -- well, that is my contribution of the moment into the cypherpunk annals. one never knows what a little combination of boredom and inspiration can lead to. --V.Z.Nuri

1 0

Re: Florida Drivers Permits and a Hello
by d-jones＠ix.netcom.com 17 Dec '03

17 Dec '03

>What possible value could the LEAs get by having your thumbprint digitally >encoded on your driver's license? It's not like the average cop-on-the-beat >is qualified to lift a fingerprint and compare it. Even if he was, how >does it benefit that the fingerprint is on the license? > >This seems silly. There are device that will electronicly read fingerprints available now. So with such a device, the LEO would know instantly if you were who you said that you were.

4 3

GOST ??
by Jim Prickett 17 Dec '03

17 Dec '03

Does anyone know what the legal status of the Russian cypher "GOST" is ? Is it public domain, patented, proprietary or what ? It looks like it would be more efficient than DES when implemented on a microprocessor or microcontroller. Also the DDJ article mentioned that like DES, there are good and bad S-boxes for GOST. Does anyone know how to choose a strong S-box for GOST ? Jim Prickett

1 0