- cypherpunks-legacy - lists.cpunks.org

[bitcoin-list] Bitcoin 0.3.17 is released
by theymos 06 Jul '18

06 Jul '18

Fixes not mentioned below: - Due to a problem in GetMyExternalIP, it was taking 5-10 extra minutes to connect to the network. - Efficiency in transaction processing while generating has been improved, which will reduce wasted CPU usage, especially for generators using several GPUs/CPUs. Some heavy GPU miners might have found themselves bound by CPU power. 0.3.16 (SVN revision 189) was never officially released. http://www.bitcoin.org/smf/index.php?topic=1946.0 Version 0.3.17 is now available. Changes: - new getwork, thanks m0mchil - added transaction fee setting in UI options menu - free transaction limits - sendtoaddress returns transaction id instead of "sent" - getaccountaddress <account> The UI transaction fee setting was easy since it was still there from 0.1.5 and all I had to do was re-enable it. The accounts-based commands: move, sendfrom and getbalance <account> will be in the next release. We still have some more changes to make first. Downloads: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.17/ ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ bitcoin-list mailing list bitcoin-list(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-list ----- 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

[bitcoin-list] Bitcoin 0.3.17 is released
by theymos 06 Jul '18

06 Jul '18

Fixes not mentioned below: - Due to a problem in GetMyExternalIP, it was taking 5-10 extra minutes to connect to the network. - Efficiency in transaction processing while generating has been improved, which will reduce wasted CPU usage, especially for generators using several GPUs/CPUs. Some heavy GPU miners might have found themselves bound by CPU power. 0.3.16 (SVN revision 189) was never officially released. http://www.bitcoin.org/smf/index.php?topic=1946.0 Version 0.3.17 is now available. Changes: - new getwork, thanks m0mchil - added transaction fee setting in UI options menu - free transaction limits - sendtoaddress returns transaction id instead of "sent" - getaccountaddress <account> The UI transaction fee setting was easy since it was still there from 0.1.5 and all I had to do was re-enable it. The accounts-based commands: move, sendfrom and getbalance <account> will be in the next release. We still have some more changes to make first. Downloads: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.17/ ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ bitcoin-list mailing list bitcoin-list(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-list ----- 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 John F. McMullen 06 Jul '18

06 Jul '18

<declan(a)well.com>, Peter Neumann <neumann(a)csl.sri.com> Subject: [johnmacsgroup] Cybersecurity: they just don't get it... FYI ---------- Forwarded message ---------- From: wes_morgan(a)US.IBM.COM To: johnmacsgroup(a)yahoogroups.com Subject: [johnmacsgroup] Cybersecurity: they just don't get it... I'm watching CNN's Headline News, and they run a story on security preparations for this week's Democratic Convention in Boston. They go on, at great length, about the extensive network of cameras--approximately 75 of them, scattered around various Federal buildings and convention sites--and make it a point to illustrate how the security force, with their wireless networks and handheld devices, can grab the feed from any of these cameras at the tap of a stylus. So, they show one such device - with it's 802.11b card clearly identifiable - and show another agent viewing a webcam of the Boston Harbor shoreline - with the URL of the hosting site clearly readable. When talking about the cameras, they show several different cameras on different buildings, some of which seem fairly unusual in their architecture. I now know that they're using 802.11b, and I know the name at least one system handling the webcam feeds, and (with a bit of reconaissance) I can probably determine the position of at least one camera. So much for cybersecurity; I can't believe that the Feds even let that stuff on the air, much less that they did so without obfuscating critical information. *sigh* What were they thinking? --------------------------------------------------------------------~-> "When you come to the fork in the road, take it" - L.P. Berra "Always make new mistakes" -- Esther Dyson "Any sufficiently advanced technology is indistinguishable from magic" -- Arthur C. Clarke "You Gotta Believe" - Frank "Tug" McGraw (1944 - 2004 RIP) John F. McMullen johnmac(a)acm.org johnmac(a)computer.org johnmac(a)m-net.arbornet.org johnmac(a)tmail.com johnmac(a)panix.com johnmac(a)echonyc.com jmcmullen(a)monroecollege.edu johnmac(a)alumni.iona.edu ICQ: 4368412 Skype, AIM & Yahoo Messenger: johnmac13 http://www.westnet.com/~observer ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- 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

[IP] Cybersecurity: they just don't get it...
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

Re: [liberationtech] CryptoParty Handbook
by Seth David Schoen 06 Jul '18

06 Jul '18

Andrew Mallis writes: > FYI > > This 392 page, Creative Commons licensed handbook is designed to help > those with no prior experience to protect their basic human right > to Privacy in networked, digital domains. By covering a broad array > of topics and use contexts it is written to help anyone wishing to > understand and then quickly mitigate many kinds of vulnerability using > free, open-source tools. Most importantly however this handbook is > intended as a reference for use during Crypto Parties. > > > PDF available for download and more info: > > https://cryptoparty.org/wiki/CryptoPartyHandbook I'm grateful to people for doing this (and happy that it built upon some prior sprints that I was part of!) but I'm a bit worried about errors. Starting from the end of the book I fairly quickly came upon two things that concerned me: "Quantum cryptography is the term used to describe the type of cryptography that is now necessary to deal with the speed at which we now process information and the related security measures that are necessary. Essentially it deals with how we use quantum communication to securely exchange a key and its associated distribution. As the machines we use become faster the possible combinations of public-key encryptions and digital signatures becomes easier to break and quantum cryptography deals with the types of algorithms that are necessary to keep pace with more advanced networks." I think the first and third sentences of this paragraph are completely mistaken. (The second sentence is right to assert that quantum cryptography deals with key-exchange mechanisms.) First, quantum cryptography for key exchange is unrelated to "the speed at which we now process information". In fact, conventional encryption has scaled well and more than kept pace with increases in communications data rates, particularly since our CPUs have gotten faster much faster than our communications links have. That's one reason that it's now much more feasible to use HTTPS routinely for web services -- current CPUs can handle the ciphers involved efficiently, and some CPUs even have hardware acceleration for AES. It's also not clear that using quantum cryptography is "necessary" for anyone today. QKD still requires strong authentication https://en.wikipedia.org/wiki/Quantum_key_distribution#Man-in-the-middle_at… so although it could reduce the need to make assumptions about the difficulty of solving math problems that are used in other forms of key distribution, it does _not_ make the authentication problem go away. The authentication problem is the logistically difficult thing about using all distributed cryptosystems, so when you use QKD you still encounter these logistical difficulties, in addition to (in most existing implementations) the extra major logistical difficulty of needing a physically directly connected fiber optic cable (!) between the parties who are trying to establish a key. Yikes! The book's suggestion that "[a]s the machines we use become faster the combinations of public-key encryptions and digital signatures becomes easier to break" is also not an argument for using quantum cryptography, just appropriate key lengths. See http://www.keylength.com/ NIST and others have thought about what appropriate cryptographic key lengths are to respond to the phenomenon of computers getting faster. That's why current NIST recommendations call for using 2048-bit RSA instead of 1024-bit RSA -- not a quantum cryptosystem, just a stronger key length. I was also concerned by the "Securely Destroying Data" section. Although it acknowledges some situations under which erased data (or even overwritten data) could be recovered, it seems to treat these situations as exceptional and multiple-overwrite tools generally reliable. It doesn't mention that these tools are potentially quite untrustworthy on current filesystems even under normal conditions, because of data journaling. (I first learned about this problem from John Gilmore.) In fact, even the man page for shred gives a warning about this: CAUTION: Note that shred relies on a very important assumption: that the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption. The following are examples of file systems on which shred is not effective, or is not guaranteed to be effective in all file sysb tem modes: * log-structured or journaled file systems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.) * file systems that write redundant data and carry on even if some writes fail, such as RAID-based file systems * file systems that make snapshots, such as Network Appliance's NFS server * file systems that cache in temporary locations, such as NFS version 3 clients * compressed file systems In the case of ext3 file systems, the above disclaimer applies (and shred is thus of limited effectiveness) only in data=journal mode, which journals file data in addition to just metadata. In both the data=ordered (default) and data=writeback modes, shred works as usual. Ext3 journaling modes can be changed by adding the data=something option to the mount options for a particular file system in the /etc/fstab file, as documented in the mount man page (man mount). The wipe man page says Journaling filesystems (such as Ext3 or ReiserFS) are now being used by default by most Linux distributions. No secure deletion program that does filesystem-level calls can sanitize files on such filesystems, because sensitive data and metadata can be written to the journal, which cannot be readily accessed. Per-file secure deletion is better implemented in the operating system. Some people see this concern as hypothetical, but it's pretty easy to test with loopback mounting. I just made a 100 MB file, initialized it with zeroes, created an ext4 filesystem in it, and loopback mounted the filesystem. Then I created several very large text files with repeating, easy-to-recognize contents, and then deleted the files with shred -u. It was still possible to find a small number of copies of the text file contents in the underlying storage file afterward -- probably because of data journaling in ext4. The book spends several pages describing how to make GUI interfaces for wipe and shred under GNOME, remarks that wipe is "a little more secure" than shred, and doesn't mention that (according to their own official documentation) neither program can be assumed to work properly on a modern system! :-( Things like this make me worry that this book needs some more work. -- Seth Schoen <schoen(a)eff.org> Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 454 Shotwell Street, San Francisco, CA 94110 +1 415 436 9333 x107 -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- 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: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- At 04:47 PM 11/22/00 -0800, Bram Cohen wrote: >On Wed, 22 Nov 2000 Lynn.Wheeler(a)firstdata.com wrote: >>the other scenerio that some certification agencies have >>expressed (i.e. licensing bureaus, bbb, consumer report, etc >>operations) is that in the online world ... that they would >>provide an online service .... rather than certificates >>designed for an offline world. >Yes, it seems fairly well established that revocations just >plain don't work. >Once again, the solution to the problems of offline >operation appears to be online operation. And the annoying thing about this is that once we go to needing an online trusted third party to allow us to have secure communications, we may as well chuck the public key stuff and just use symmetric ciphers and the key exchange protocols worked out ten or fifteen years ago. Which makes me suspect that we're just not using public key mechanisms very intelligently yet. We've realized that screws are better for many jobs than nails, it's just that they're so damned hard to hammer in.... >-Bram Cohen --John Kelsey PGP: 5D91 6F57 2646 83F9 6D7F 9C87 886D 88AF ``Slavery's most important legacy may be a painful insight into human nature and into the terrible consequences of unbridled power.'' --Thomas Sowell, _Race and Culture_ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use <http://www.pgpinternational.com> Comment: foo iQCVAwUBOh7WlyZv+/Ry/LrBAQE+eAP9E8RxIl9TAVbWT8CJKGl0V3IN9wMCWs82 wzh3XaSs/YYdGcG/+rEPN+S6y9t8HsSz9vr3dgPwOMDsVvkmBkOQJT+YK86thUiS a4eL2Ea9T2lAj5+gb6jeUhBpqn130C0WxUab5ARZffSOMkZCa7I9V6CfKIwL9Noq fMzDtrkqNXw= =yGFp -----END PGP SIGNATURE-----

1 0

Re: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- At 04:47 PM 11/22/00 -0800, Bram Cohen wrote: >On Wed, 22 Nov 2000 Lynn.Wheeler(a)firstdata.com wrote: >>the other scenerio that some certification agencies have >>expressed (i.e. licensing bureaus, bbb, consumer report, etc >>operations) is that in the online world ... that they would >>provide an online service .... rather than certificates >>designed for an offline world. >Yes, it seems fairly well established that revocations just >plain don't work. >Once again, the solution to the problems of offline >operation appears to be online operation. And the annoying thing about this is that once we go to needing an online trusted third party to allow us to have secure communications, we may as well chuck the public key stuff and just use symmetric ciphers and the key exchange protocols worked out ten or fifteen years ago. Which makes me suspect that we're just not using public key mechanisms very intelligently yet. We've realized that screws are better for many jobs than nails, it's just that they're so damned hard to hammer in.... >-Bram Cohen --John Kelsey PGP: 5D91 6F57 2646 83F9 6D7F 9C87 886D 88AF ``Slavery's most important legacy may be a painful insight into human nature and into the terrible consequences of unbridled power.'' --Thomas Sowell, _Race and Culture_ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use <http://www.pgpinternational.com> Comment: foo iQCVAwUBOh7WlyZv+/Ry/LrBAQE+eAP9E8RxIl9TAVbWT8CJKGl0V3IN9wMCWs82 wzh3XaSs/YYdGcG/+rEPN+S6y9t8HsSz9vr3dgPwOMDsVvkmBkOQJT+YK86thUiS a4eL2Ea9T2lAj5+gb6jeUhBpqn130C0WxUab5ARZffSOMkZCa7I9V6CfKIwL9Noq fMzDtrkqNXw= =yGFp -----END PGP SIGNATURE-----

1 0

Re: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- At 04:47 PM 11/22/00 -0800, Bram Cohen wrote: >On Wed, 22 Nov 2000 Lynn.Wheeler(a)firstdata.com wrote: >>the other scenerio that some certification agencies have >>expressed (i.e. licensing bureaus, bbb, consumer report, etc >>operations) is that in the online world ... that they would >>provide an online service .... rather than certificates >>designed for an offline world. >Yes, it seems fairly well established that revocations just >plain don't work. >Once again, the solution to the problems of offline >operation appears to be online operation. And the annoying thing about this is that once we go to needing an online trusted third party to allow us to have secure communications, we may as well chuck the public key stuff and just use symmetric ciphers and the key exchange protocols worked out ten or fifteen years ago. Which makes me suspect that we're just not using public key mechanisms very intelligently yet. We've realized that screws are better for many jobs than nails, it's just that they're so damned hard to hammer in.... >-Bram Cohen --John Kelsey PGP: 5D91 6F57 2646 83F9 6D7F 9C87 886D 88AF ``Slavery's most important legacy may be a painful insight into human nature and into the terrible consequences of unbridled power.'' --Thomas Sowell, _Race and Culture_ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use <http://www.pgpinternational.com> Comment: foo iQCVAwUBOh7WlyZv+/Ry/LrBAQE+eAP9E8RxIl9TAVbWT8CJKGl0V3IN9wMCWs82 wzh3XaSs/YYdGcG/+rEPN+S6y9t8HsSz9vr3dgPwOMDsVvkmBkOQJT+YK86thUiS a4eL2Ea9T2lAj5+gb6jeUhBpqn130C0WxUab5ARZffSOMkZCa7I9V6CfKIwL9Noq fMzDtrkqNXw= =yGFp -----END PGP SIGNATURE-----

1 0

Re: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- At 04:47 PM 11/22/00 -0800, Bram Cohen wrote: >On Wed, 22 Nov 2000 Lynn.Wheeler(a)firstdata.com wrote: >>the other scenerio that some certification agencies have >>expressed (i.e. licensing bureaus, bbb, consumer report, etc >>operations) is that in the online world ... that they would >>provide an online service .... rather than certificates >>designed for an offline world. >Yes, it seems fairly well established that revocations just >plain don't work. >Once again, the solution to the problems of offline >operation appears to be online operation. And the annoying thing about this is that once we go to needing an online trusted third party to allow us to have secure communications, we may as well chuck the public key stuff and just use symmetric ciphers and the key exchange protocols worked out ten or fifteen years ago. Which makes me suspect that we're just not using public key mechanisms very intelligently yet. We've realized that screws are better for many jobs than nails, it's just that they're so damned hard to hammer in.... >-Bram Cohen --John Kelsey PGP: 5D91 6F57 2646 83F9 6D7F 9C87 886D 88AF ``Slavery's most important legacy may be a painful insight into human nature and into the terrible consequences of unbridled power.'' --Thomas Sowell, _Race and Culture_ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use <http://www.pgpinternational.com> Comment: foo iQCVAwUBOh7WlyZv+/Ry/LrBAQE+eAP9E8RxIl9TAVbWT8CJKGl0V3IN9wMCWs82 wzh3XaSs/YYdGcG/+rEPN+S6y9t8HsSz9vr3dgPwOMDsVvkmBkOQJT+YK86thUiS a4eL2Ea9T2lAj5+gb6jeUhBpqn130C0WxUab5ARZffSOMkZCa7I9V6CfKIwL9Noq fMzDtrkqNXw= =yGFp -----END PGP SIGNATURE-----

1 0

Re: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- At 04:47 PM 11/22/00 -0800, Bram Cohen wrote: >On Wed, 22 Nov 2000 Lynn.Wheeler(a)firstdata.com wrote: >>the other scenerio that some certification agencies have >>expressed (i.e. licensing bureaus, bbb, consumer report, etc >>operations) is that in the online world ... that they would >>provide an online service .... rather than certificates >>designed for an offline world. >Yes, it seems fairly well established that revocations just >plain don't work. >Once again, the solution to the problems of offline >operation appears to be online operation. And the annoying thing about this is that once we go to needing an online trusted third party to allow us to have secure communications, we may as well chuck the public key stuff and just use symmetric ciphers and the key exchange protocols worked out ten or fifteen years ago. Which makes me suspect that we're just not using public key mechanisms very intelligently yet. We've realized that screws are better for many jobs than nails, it's just that they're so damned hard to hammer in.... >-Bram Cohen --John Kelsey PGP: 5D91 6F57 2646 83F9 6D7F 9C87 886D 88AF ``Slavery's most important legacy may be a painful insight into human nature and into the terrible consequences of unbridled power.'' --Thomas Sowell, _Race and Culture_ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use <http://www.pgpinternational.com> Comment: foo iQCVAwUBOh7WlyZv+/Ry/LrBAQE+eAP9E8RxIl9TAVbWT8CJKGl0V3IN9wMCWs82 wzh3XaSs/YYdGcG/+rEPN+S6y9t8HsSz9vr3dgPwOMDsVvkmBkOQJT+YK86thUiS a4eL2Ea9T2lAj5+gb6jeUhBpqn130C0WxUab5ARZffSOMkZCa7I9V6CfKIwL9Noq fMzDtrkqNXw= =yGFp -----END PGP SIGNATURE-----

1 0