- cypherpunks-legacy - lists.cpunks.org

Tor 0.0.9pre1 is out
by Roger Dingledine 06 Jul '18

06 Jul '18

We've fixed quite a few bugs. We've also added compression for directories, and client-side directory caching on disk so you'll have a directory when Tor restarts. tarball: http://freehaven.net/tor/dist/tor-0.0.9pre1.tar.gz signature: http://freehaven.net/tor/dist/tor-0.0.9pre1.tar.gz.asc (use -dPr tor-0_0_9pre1 if you want to check out from cvs) Changes from 0.0.8: o Bugfixes: - Stop using separate defaults for no-config-file and empty-config-file. Now you have to explicitly turn off SocksPort, if you don't want it open. - Fix a bug in OutboundBindAddress so it (hopefully) works. - Improve man page to mention more of the 0.0.8 features. - Fix a rare seg fault for people running hidden services on intermittent connections. - Change our file IO stuff (especially wrt OpenSSL) so win32 is happier. - Fix more dns related bugs: send back resolve_failed and end cells more reliably when the resolve fails, rather than closing the circuit and then trying to send the cell. Also attach dummy resolve connections to a circuit *before* calling dns_resolve(), to fix a bug where cached answers would never be sent in RESOLVED cells. - When we run out of disk space, or other log writing error, don't crash. Just stop logging to that log and continue. - We were starting to daemonize before we opened our logs, so if there were any problems opening logs, we would complain to stderr, which wouldn't work, and then mysteriously exit. - Fix a rare bug where sometimes a verified OR would connect to us before he'd uploaded his descriptor, which would cause us to assign conn->nickname as though he's unverified. Now we look through the fingerprint list to see if he's there. - Fix a rare assert trigger, where routerinfos for entries in our cpath would expire while we're building the path. o Features: - Clients can ask dirservers for /dir.z to get a compressed version of the directory. Only works for servers running 0.0.9, of course. - Make clients cache directories and use them to seed their router lists at startup. This means clients have a datadir again. - Configuration infrastructure support for warning on obsolete options. - Respond to content-encoding headers by trying to uncompress as appropriate. - Reply with a deflated directory when a client asks for "dir.z". We could use allow-encodings instead, but allow-encodings isn't specified in HTTP 1.0. - Raise the max dns workers from 50 to 100. - Discourage people from setting their dirfetchpostperiod more often than once per minute - Protect dirservers from overzealous descriptor uploading -- wait 10 seconds after directory gets dirty, before regenerating. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

MCI set to offer secure two-way messaging with strong encryption
by Ian Grigg 06 Jul '18

06 Jul '18

http://www.gcn.com/vol1_no1/daily-updates/27748-1.html MCI set to offer secure two-way messaging with strong encryption 10/27/04 By William Jackson, GCN Staff MCI Inc. will offer secure two-way messaging through its SkyTel Communications subsidiary next month, encrypting wireless text with the Advanced Encryption Algorithm. "It was initially designed to meet the security needs of our government customers," SkyTel marketing director Michael Barnes said. The company plans to get the device for its Secure 2Way service certified for Federal Information Processing Standard 140-2, which applies to cryptological devices used by the government. The company also is promoting the service as compliant with the Health Insurance Portability and Accountability Act and expects the health care and financial service industries to be early users. Text messaging and paging has emerged as a reliable-sometimes the only-means of communication during emergencies that disrupt other media, such as wired and cellular telephone systems and the Internet. The Secure 2Way service uses the handheld ST900 2Way messaging device from Sun Telecom Inc. of Norcross, Ga. Messages are encrypted between the device and an encryption server at SkyTel's secure network operations center. Two levels of service are offered. Device-level security provides device-to-device encryption when both users have the ST900. When messages are received from nonsecure devices, traffic is encrypted only between the operations center server and the ST900. With end-to-end security, all traffic is blocked except that from other secure ST900 devices so there is no unencrypted link on any message. The service uses 128-bit encryption keys with AES and the ANSI X9.63 key management standard for symmetrical keys. The National Security Agency has approved AES with 128-bit keys for use up to secret classification. The key on each device is automatically changed every 30 days or after 5,000 messages. The initial key generation and exchange takes about eight minutes. Subsequent key changes take two or three minutes. Each device also is password protected with an eight-character alphanumeric password. "It was tough to build the AES encryption into the device," Barnes said. "It is not done through add-on hardware." After buying the ST900, there's no extra charge for the device- level service. End-to-end service incurs an additional fee. ) 1996-2004 Post-Newsweek Media, Inc. All Rights Reserved. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

[Dewayne-Net] Judge Approves Warrantless Email Monitoring
by Dewayne Hendricks 06 Jul '18

06 Jul '18

[Note: This item comes from reader Randall. DLH] >From: Randall <rvh40(a)insightbb.com> >Date: February 10, 2006 8:54:22 PM PST >To: Dave <dave(a)farber.net>, Dewayne Hendricks ><dewayne(a)warpspeed.com>, cyberia <CYBERIA-L(a)LISTSERV.AOL.COM> >Subject: Judge Approves Warrantless Email Monitoring > ><http://htdaw.blogsource.com/post.mhtml?post_id=232185> > >Judge Approves Warrantless Email Monitoring >Friday, February 10, 2006 at 11:51 PM EST > What: The Justice Department asks a judge to approve Patriot Act e- >mail >monitoring without any evidence of criminal behavior. > >When: Decided Feb. 2, 2006 by U.S. District Judge Thomas Hogan in >Washington, D.C. > >Outcome: E-mail surveillance approved. > >What happened: As part of a grand jury investigation that's still >secret, the Justice Department asked a federal magistrate judge to >approve monitoring of an unnamed person's e-mail correspondents. > >The request had a twist: Instead of asking to eavesdrop on the >contents >of the e-mail messages, which would require some evidence of >wrongdoing, >prosecutors instead requested the identities of the correspondents. >Also >included in the request was header information like date and time and >Internet address--but not subject lines. > >The federal magistrate judge balked and asked the Justice >Department to >submit an additional brief to demonstrate that such a request would be >legal. > >Instead, prosecutors asked Judge Hogan to step in. He reviewed the >portion of federal law dealing with "pen register" and "trap and >trace" >devices--terms originating in the world of telephone wiretapping--and >concluded it "unambiguously" authorizes the e-mail surveillance >request. > >Though the language may be clumsy, Hogan said, the Patriot Act's >amendments authorize that type of easily obtainable surveillance of >e-mail. All that's required, he said, is that prosecutors claim the >surveillance could conceivably be "relevant" to an investigation. > >Excerpt from the court's opinion: >"In 2001, Congress enacted the Uniting and Strengthening America by >Providing Appropriate Tools Required to Intercept and Obstruct >Terrorism >Act of 2001 (the "USA Patriot Act"), Section 216 of which explicitly >amended the authorities relating to pen registers and trap and trace >devices...by expanding the definitions of these devices to include >"processes" to obtain information about "electronic communication." > >"Commenting on the very language that was finally enacted in >Section 216 >of the USA Patriot Act, several members of Congress highlighted the >fact >that the amendments would bring the state of the law in line with >current technology by making pen registers and trap and trace devices >applicable to the Internet and--more to the point--e-mail. > >"For example, a section-by-section analysis of the bill that >Representative John Conyers included in the record before the final >House vote, which contains the same language that was finally >enacted by >Congress, states that Section 216 "extends the pen/trap provisions so >they apply not just to telephone communications but also to Internet >traffic." > >"In addition, Senator Jon Kyl, who is currently Chairman of the United >States Senate Judiciary Subcommittee on Terrorism, Technology & >Homeland >Security, noted that the same language in the Senate version of the >bill >"would codify current case law that holds that pen/trap orders >apply to >modern communication technologies such as e-mail and the Internet, in >addition to traditional phone lines." > >"The Congressional Research Service also published a legal analysis of >the USA Patriot Act that states that the Act "permits pen register and >trap and trace orders for electronic communications (e.g., e-mail)." > >"The plain language of the statute makes clear that pen registers and >trap and trace devices may be processes used to obtain information >about >e-mail communications. The statute's history confirms this >interpretation and there is no support for a contrary result." > ><http://news.zdnet.com/2100-9595_22-6037598.html> Weblog at: <http://weblog.warpspeed.com> ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

Re: U.S. officials deny technical takedown of WikiLeaks
by Ken Gilmour 06 Jul '18

06 Jul '18

Now Sarah Palin is suggesting Wikileaks are terrorists and should be taken offline with technical capabilities http://www.golem.de/1012/79848.html or for anyone who can't speak German: http://translate.google.ie/translate?u=http%3A%2F%2Fwww.golem.de%2F1012%2F7… (The translation is about as coherent as Sarah Palin herself). ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: U.S. officials deny technical takedown of WikiLeaks
by Ken Gilmour 06 Jul '18

06 Jul '18

Now Sarah Palin is suggesting Wikileaks are terrorists and should be taken offline with technical capabilities http://www.golem.de/1012/79848.html or for anyone who can't speak German: http://translate.google.ie/translate?u=http%3A%2F%2Fwww.golem.de%2F1012%2F7… (The translation is about as coherent as Sarah Palin herself). ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

None
by None 06 Jul '18

06 Jul '18

1 0

None
by None 06 Jul '18

06 Jul '18

--- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

Lucrative update
by Patrick 06 Jul '18

06 Jul '18

Lucrative release 4 is out. I know many people are used to seeing releases numbered like "0.000001", "0.000002", "2.0.3.0.14.657" etc. but release numbering systems are essentially arbitrary in nature so don't get excited as Lucrative goes toward version 50+. This release is a fairly minor one, but included some changes such as the client name that I wanted to get out as soon as possible. There is also a new development weblog at http://lucrative.thirdhost.com/weblog/. I went through an install with someone over IRC last night and made a blog entry summarizing the install notes. I recommend reading the notes before attempting an install. I am glad to help with an install, drop me a note at patrick(a)lfcgate.com if you have trouble. Some documentation on the various entities in the Lucrative system is now available on the website, http://lucrative.thirdhost.com/documentation.php but more is needed and coming. If Lucrative is interesting to you, please consider helping in any way you can: Feedback Installation reports Suggestions Comments Criticism Feature requests Source code patches Donations Are all very much welcomed. And criticism is more useful to me than praise. My sincere thanks to everyone who has participated so far by installing, testing, providing feedback, spreading the word, and donating. And finally I just received word from SourceForge that the project registration for Lucrative has been approved. Regards, Patrick -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com> mQGiBD5ECKcRBADUvjXHwLtxIyS4AyjBs/dFtN6rdeP18Fhzh1hD5fJwkFevqY9Z I1ASROTh6eXYF7pU5sEvbcPshHyTB41ZtTqZvQvpwWN0fUzOuutuI0mtC5UPp9Rz j47SdWLdEXNHjwnHDCYSyqtqZu8GujGRQybR0eP3NIh/NwbSDUKdgz7IjwCg//Jo UtjP3zUFobm/0UYA+CJ5krED/091x9Js0gwNwvjbzM8DqO+r8qNz0kXI13FkrPRk QNd37lxt6m2m8HZD1WYM2wKwtMzHSwJcWzaDZ/tNc+ppYjzpw0EQCh9FqjGs8Vau guF6PA1M8lJTCcLKaL4e7ynic+PAw5Xa/tdOYgFCG+eLMU5RLvzRCYoOLIjgMJLJ yG98BACAMlDmFVYgC/UKvzZmHfZ5CtCKd8sPfCXrYLu5NeFRE0LR6D6zjzmhi1xX okfreR5o3T/y78VBM98js+m2/+7Z0AElqydeW/RnV1zqwDGjDr9z2MgARf3yLAbs n3BU8Fz61RwvHy6cRkT+2dR2f69QQUSpkupvLwZIGX/iwm4uKLQdUGF0cmljayA8 cGF0cmlja0BsZmNnYXRlLmNvbT6JAE4EEBECAA4FAj5ECKcECwMCAQIZAQAKCRBb mvb9yuOVfaA2AKDAu5tDj9F2KI8cJMrKKkQRAcUyxACg6/bei7lUJH+E5igJqGRx SjKrRA65BA0EPkQIpxAQAPkYoH5aBmF6Q5CV3AVsh4bsYezNRR8O2OCjecbJ3HoL rOQ/40aUtjBKU9d8AhZIgLUV5SmZqZ8HdNP/46HFliBOmGW42A3uEF2rthccUdhQ yiJXQym+lehWKzh4XAvb+ExN1eOqRsz7zhfoKp0UYeOEqU/Rg4Soebbvj6dDRgjG zB13VyQ4SuLE8OiOE2eXTpITYfbb6yUOF/32mPfIfHmwch04dfv2wXPEgxEmK0Ng w+Po1gr9oSgmC66prrNlD6IAUwGgfNaroxIe+g8qzh90hE/K8xfzpEDp19J3tkIt AjbBJstoXp18mAkKjX4t7eRdefXUkk+bGI78KqdLfDL2Qle3CH8IF3KiutapQvMF 6PlTETlPtvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSGSfgMg71l6RfUodNQ +PVZX9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarT W56NoKVyOtQa8L9GAFgr5fSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY72 88kjwEPwpVsYjY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy 1obEAxnIByl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XrPdYX AAICD/wKwtF7Y4NKBe8PQ6jDbjWziiTv9Ac/EnRTJDQEoqgLa2LyE+6Ahw/VPGvp mfxkD2MKxC9E7kYVmasn6sHnSpvAv3e7O1Bqbo/qLzzCcJQ5VCurZ+elRM1GZ4Oc fM19FPKutb0/JFEv0nrqS4BGkF7WFBbu5dKYl/GIO7Co1mAerFIb719dOwMPVEIz OT08u8uB9jyR8gEElf+CVuNfOUkrUGg4HS4SbmTTrCSz3/8n5PkquSuAyjCB/dwM ZsZwA0/TTR8sDYlmlf9xPj5PGpGnV9OUwfig6eE0eWtRFeasmz0uiX+yp45ABtNh 6EXP/PFaBgXi9omXXjeeFYfpDvmfA6izvTIQfXTV6V9ZWrBfXarM+GQ+6guXWVbd 9fXvmCr982LkzuKQrK1OpRXBMUapXL+tOy/LYzz91InqKKhgPNGa12fvotZ4LzlM iqoM+Hpz5L9B5We1Ph0lD6RBVXDCqd+P8extnY/7AaDy7tC0UghaAaUuEZXJQPIc oQ3QGbpjM0nGe/VZN5EZhljau0NNENFaU56cOpvOhcO04gLGNNc2NS+rIpTMsaHh o1CG90c5zZZJuUbyx0mIHriNQXDgEwunSZPQorKK9KSppyyjeuOyi5F/mBBPXeyT weLhLqLvAr9se/+Z3aQvMADJi8zUZtGggLTw+N9R5XSwtSh2R4kARgQYEQIABgUC PkQIpwAKCRBbmvb9yuOVfWayAKC+mBhHdn1XZ5uH0RocAyJ32hx2kgCePyhB+IqM TjWLDLarQxcPYhbkFi4= =nx1M -----END PGP PUBLIC KEY BLOCK----- --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0

Anonymity, ... - A Proposal for Terminology v 0.18
by Andreas Pfitzmann 06 Jul '18

06 Jul '18

Hi all, Marit Hansen and myself are happy to release herewith Anonymity, Unobservability, Pseudonymity, and Identity Management - A Proposal for Terminology v0.18 Since the beginning of this undertaking in 2000, it is joint work with many criticizing and contributing. Thanx a lot to them all. May I encourage you to make use of this document and help in its further development as well? To help you in this, I did put online at http://dud.inf.tu-dresden.de/Literatur_V1.shtml all older versions of this document (starting with v0.5) not only in .pdf, but in .doc as well. The latter you can use easily using, e.g. MS Word, to highlight any delta between versions, e.g. the differences between the last version you have read and the current version. Happy to hear from you Andreas -- Andreas Pfitzmann Dresden University of Technology Phone (mobile) +49 170 443 87 94 Department of Computer Science (office) +49 351 463 38277 Institute for System Architecture (secretary) +49 351 463 38247 01062 Dresden, Germany Fax +49 351 463 38255 http://dud.inf.tu-dresden.de e-mail pfitza(a)inf.tu-dresden.de

1 0

Tor 0.0.9pre1 is out
by Roger Dingledine 06 Jul '18

06 Jul '18

We've fixed quite a few bugs. We've also added compression for directories, and client-side directory caching on disk so you'll have a directory when Tor restarts. tarball: http://freehaven.net/tor/dist/tor-0.0.9pre1.tar.gz signature: http://freehaven.net/tor/dist/tor-0.0.9pre1.tar.gz.asc (use -dPr tor-0_0_9pre1 if you want to check out from cvs) Changes from 0.0.8: o Bugfixes: - Stop using separate defaults for no-config-file and empty-config-file. Now you have to explicitly turn off SocksPort, if you don't want it open. - Fix a bug in OutboundBindAddress so it (hopefully) works. - Improve man page to mention more of the 0.0.8 features. - Fix a rare seg fault for people running hidden services on intermittent connections. - Change our file IO stuff (especially wrt OpenSSL) so win32 is happier. - Fix more dns related bugs: send back resolve_failed and end cells more reliably when the resolve fails, rather than closing the circuit and then trying to send the cell. Also attach dummy resolve connections to a circuit *before* calling dns_resolve(), to fix a bug where cached answers would never be sent in RESOLVED cells. - When we run out of disk space, or other log writing error, don't crash. Just stop logging to that log and continue. - We were starting to daemonize before we opened our logs, so if there were any problems opening logs, we would complain to stderr, which wouldn't work, and then mysteriously exit. - Fix a rare bug where sometimes a verified OR would connect to us before he'd uploaded his descriptor, which would cause us to assign conn->nickname as though he's unverified. Now we look through the fingerprint list to see if he's there. - Fix a rare assert trigger, where routerinfos for entries in our cpath would expire while we're building the path. o Features: - Clients can ask dirservers for /dir.z to get a compressed version of the directory. Only works for servers running 0.0.9, of course. - Make clients cache directories and use them to seed their router lists at startup. This means clients have a datadir again. - Configuration infrastructure support for warning on obsolete options. - Respond to content-encoding headers by trying to uncompress as appropriate. - Reply with a deflated directory when a client asks for "dir.z". We could use allow-encodings instead, but allow-encodings isn't specified in HTTP 1.0. - Raise the max dns workers from 50 to 100. - Discourage people from setting their dirfetchpostperiod more often than once per minute - Protect dirservers from overzealous descriptor uploading -- wait 10 seconds after directory gets dirty, before regenerating. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0