July 2018 - cypherpunks-legacy

[liberationtech] DIY Drones
by Jeffrey Burdges 06 Jul '18

06 Jul '18

It's perhaps worth forwarding this to liberationtech : > Mavelous is an open-source web/HTML-based ground control station for amateur UAVs/DIY drones. It is the first open-source ground control station that lets you control your drone from your tablet or even your phone. source https://github.com/wiseman/mavelous#readme via http://www.metafilter.com/122685/Marvelous-Mavelous See also http://diydrones.com Best, Jeff -- 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

Sunday 3 August 2003 Three Jewels Free Software Workshop: Install Fest and Five Lines in Three Files
by Jay Sexpot Sulzberger 06 Jul '18

06 Jul '18

Sunday 3 August 2003 there will be an Install Fest and Talk at Three Jewels Refuge and Free Internet Cafe 211 East 5th Street east of Third Avenue Island of the Manahattoes Subway: Eighth Street stop on the N, R, sometimes W, lines; Astor Place on the 6 line; Third Avenue on the crosstown L line; Lower East Side-Second Avenue-Houston Street on the F, V lines Note that some of these lines may not be running right this weekend. The Fest will start at 3:00 pm and run until 9:00 pm. At 7:00 pm there will a short talk followed by discussion. The title of the talk is Five Lines in Three Files. This meeting is free and open to the public. There are certain rules which will be strictly observed: 1. No meat eating inside the Refuge. 2. No personal abuse. Every member of every free software org, tribe, drinking club, and family, is invited, without prejudice, without fear, and without favor. Newcomers are particularly invited. Come down and join us, even if you bring no hardware. Likely we will have enough electric power strips and cables, but bring extras if you wish. CDs, DVDs, tapes, wax cylinders, quipus, memorable stanzas, black cubes, etc. of your favorite operating systems and software are welcome. See below about management of stuff you bring with you. Please read the appended standard blurb about Install Fests before you come down, if you hope to get stuff installed. Jonas Arnaldo and Kevin Mark and Jay Sulzberger will be available to answer any questions we may. In the next month we will likely have special meetings dealing with: 1. Lisp and RoboCup, http://www.lispnyc.org 2. Introduction to network security, special emphasis on time series analysis and key management 3. How to buy parts and assemble a computer well suited to run a Free *n*x We thank the Three Jewels, LXNY, and GNUbies for their generous help in making this Fest possible, and we thank the Three Jewels for hosting this Workshop, and Sunday Workshops to come, Sundays of Free Software in New York City. Jay Sulzberger <secretary(a)lxny.org> Corresponding Secretary LXNY LXNY is New York's Free Computing Organization. http://www.lxny.org <blockquote what="standard Install Fest blurb"> Here is general information about Install Fests: Hardware: Bring the boxes on which you wish to run a Free OS. Software: Bring whatever distribution CDs, boot and rescue disks, boot managers, tiny distributions, manuals, and anything else you want. Important: Everything done to/with any computer at any Install Fest, and in particular, at this Install Fest, is done at the specific request of the owner of the computer. As with all human endeavor, there is some risk of catastrophe. Back up all your data, before coming to the Fest! In addition, make a list of all hardware and media you bring to the Fest, and check that you have all your hardware and media when you leave the Fest. Useful reading: http://www.netcom.com/~casandra/mirror-of-luny-site/installfest/guidelines.… http://linuxmafia.com/bale/linuxprep.html http://www.luv.asn.au/if/preparation.php3 The LDP hardware HOW-TO: http://www.linuxdoc.org/HOWTO/Hardware-HOWTO/index.html Linux pre-install checklist: http://www.linuxdoc.org/HOWTO/mini/Pre-Installation-Checklist/index.html Linux post-install mini-checklist: http://algolog.tripod.com/postlnx.htm http://www.linuxdoc.org/HOWTO/mini/Post-Installation-Checklist/index.html http://www.lxny.org http://www.gnubies.org http://www.nylug.org http://www.sixgirls.org http://www.fsf.org http://www.debian.org http://www.multicians.org http://www.gnu.org/projects/dotgnu http://tinfoilhat.cultists.net http://www.nsa.gov/selinux http://www.linux.org http://www.debian.org/ports/hurd http://www.squeak.org http://www.freebsd.org http://www.netbsd.org http://www.openbsd.org http://www2.ics.hawaii.edu/~esb/prof/proj/hello http://www.daemonnews.org http://slashdot.org http://dmoz.org/Computers/Software/Operating_Systems http://www2.tunes.org/Review/OSes.html </blockquote> ----- End forwarded message -----

1 0

Re: [p2p-hackers] Verifying Claims of Full-Disk Encryption in Hard Drive Firmware
by Tom Ritter 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After reviewing the FIPs approval document for the drive[1], I've tried to put together a complete threat model outlining the major classes of attack on the hard drive in the interest of being rigorous. I'd like your input to see if I missed any you can think of. I've explicitly excluded DriveTrust (the proprietary stuff) from the threat model, and am only focusing on the ATA Standard. [1] http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1388.pdf ==================== In approximate physical/logical order, this is every attack I can conceive of: 1. The BIOS may have been replaced to record passwords 2. The keyboard or keyboard connection may be tapped/keylogged 3. The physical computer may have been tampered with physically installing hardware in any of its components 4. The Operating System may have been tampered with 5. The application used to interact with the hard drive (hdparm) may have been subverted 6. The SATA connection to the HDD may have been tapped 7. On the Drive 1. The hardware of the drive may been tampered with 2. Firmware 1. The firmware may be buggy allowing code execution on the Hard Disk Drive 2. The firmware may have been replaced. Supposedly, the firmware replace requires the firmware be signed with a private RSA key AND that the drive have the Load Firmware capability active. The public key is stored on the system storage area of the media 1. The firmware may be able to be loaded despite the load firmware capability inactive 2. The firmware load process may have a bug invalidating the signature 3. The malicious firmware may be appropriately signed 4. The public key in the system storage area may have been replaced, allowing untrustworthy firmware be loaded 3. The RAM of the device may be able to be read, allowing unknown compromising vectors. 1. The encryption key may be stored in RAM 2. The Seed Key and Seed used in the Random Number Generator may be read, allowing any new key that is generated to be guessed. 3. Internal states to the encryption process, or other operation of the firmware may be exposed 4. System Storage Area - An area of the drive that is supposed to only be able to be read by the firmware, and not the computer. 1. Secure ID aka Drive Owner (SHA Digest) 1. If the system area is able to be read, an unsalted simple SHA may be crackable 2. If the system area is able to be written, this may be replaced with a hash of a known password. 3. If the Drive Owner PIN has not been changed upon initialization, the PIN is printed on the drive 2. User & Master Passwords (SHA Digest) 1. If the System Area is able to be read, an unsalted simple SHA digest may be crackable 2. If the system area is able to be written, this may be replaced with a hash of a known password. 3. User/Master Encryption Keys (Plaintext?) 1. The the System Area is able to be read, plaintext storage of the keys allows full data recovery 2. If the Random Number Generator is not cryptographically secure, the encryption key may follow a guessable pattern 4. Firmware Public RSA Key 1. The the System Area is able to be written to, the firmware key may be replaced and new firmware loaded 5. User Storage Area - where your data is stored. 1. The data may not be encrypted with AES as promised 2. The cipher mode may not be suitable for filesystem encryption 3. The drive may be initialized in a non-random pattern, allowing usage analysis 4. The ciphertext may be stored in a way allowing block swapping, ciphertext injection, or otherwise damaging the integrity of the ciphertext 6. The Drive may be vulnerable to side channel attacks 1. Crypto operations may not be constant-time leaking data about the key structure or value 2. Drive may not draw power equally during crypto operations leaking data about the key structure or value 3. The drive may not be acoustically silent, leaking information about where on the platters the data is being written by listening to drive head movements. 4. The drive may not be protected against induced faults such as power manipulation, temperature extremes, electrical shocks, or physical shocks. 8. AT Password Security Protocol 1. Passwords may be attempted at a rapid sequence if a mechanism to reset the module is created. ==================== This groups those attacks together, and notes whether I consider them within the realm of testing for the drive. I'm not sure what will be doable easily or cheaply, but if I can verify the firmware, I'll try. Not Considered for evaluation User Coercion or Cooperation / "Evil Maid" Attacks 1. Hardware tampering or tapping of the Keyboard, Keyboard connection, Computer, SATA connection or HDD Pwnage 1. Subversion of the Operating System, BIOS, or hdparm Misconfiguration 1. Not changing the Master or Drive Owner password 2. Not enabling hard disk security Side Channel Attacks Considered for Evaluation 1. Buggy firmware 1. with regards to firmware signature verification 2. with regards to firmware replacement despite load firmware capability disabled 3. with regards to randomly selecting an encryption key 4. with regards to proper encryption 5. with regards to backdoors 6. with regards to memory trespass or other ?standard? vulnerabilities 2. Key Management 1. plaintext storage of encryption keys in system area 2. poor password hashing practices of passwords 3. Encryption 1. lack of encryption of user data 2. Improper cipher mode 3. Patterned initial fill of disk 4. Lack of ciphertext integrity 4. System Area 1. ability to read system area 2. ability to write system area ==================== Again, all comments welcome, but particularly interesting in talking to - Anyone familiar with these Seagate drives or DriveTrust. - Anyone familiar with BIOS support for the AT Security Spec, who can help me locate a new netbook to work with. - Anyone familiar with Data Recovery Services who could provide information on disk unlocking, AT password bypass, or moving platters between disks. - Anyone who has done this before. - -tom -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAk65zqYACgkQJZJIJEzU09sNfwCfX3APmmrtFBke2CI3Ia1Rot+4 cDQAn00ezd8VPehRXAYCIM80bh464I6A =AwIs -----END PGP SIGNATURE----- _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- 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

Sunday 3 August 2003 Three Jewels Free Software Workshop: Install Fest and Five Lines in Three Files
by Jay Sexpot Sulzberger 06 Jul '18

06 Jul '18

Sunday 3 August 2003 there will be an Install Fest and Talk at Three Jewels Refuge and Free Internet Cafe 211 East 5th Street east of Third Avenue Island of the Manahattoes Subway: Eighth Street stop on the N, R, sometimes W, lines; Astor Place on the 6 line; Third Avenue on the crosstown L line; Lower East Side-Second Avenue-Houston Street on the F, V lines Note that some of these lines may not be running right this weekend. The Fest will start at 3:00 pm and run until 9:00 pm. At 7:00 pm there will a short talk followed by discussion. The title of the talk is Five Lines in Three Files. This meeting is free and open to the public. There are certain rules which will be strictly observed: 1. No meat eating inside the Refuge. 2. No personal abuse. Every member of every free software org, tribe, drinking club, and family, is invited, without prejudice, without fear, and without favor. Newcomers are particularly invited. Come down and join us, even if you bring no hardware. Likely we will have enough electric power strips and cables, but bring extras if you wish. CDs, DVDs, tapes, wax cylinders, quipus, memorable stanzas, black cubes, etc. of your favorite operating systems and software are welcome. See below about management of stuff you bring with you. Please read the appended standard blurb about Install Fests before you come down, if you hope to get stuff installed. Jonas Arnaldo and Kevin Mark and Jay Sulzberger will be available to answer any questions we may. In the next month we will likely have special meetings dealing with: 1. Lisp and RoboCup, http://www.lispnyc.org 2. Introduction to network security, special emphasis on time series analysis and key management 3. How to buy parts and assemble a computer well suited to run a Free *n*x We thank the Three Jewels, LXNY, and GNUbies for their generous help in making this Fest possible, and we thank the Three Jewels for hosting this Workshop, and Sunday Workshops to come, Sundays of Free Software in New York City. Jay Sulzberger <secretary(a)lxny.org> Corresponding Secretary LXNY LXNY is New York's Free Computing Organization. http://www.lxny.org <blockquote what="standard Install Fest blurb"> Here is general information about Install Fests: Hardware: Bring the boxes on which you wish to run a Free OS. Software: Bring whatever distribution CDs, boot and rescue disks, boot managers, tiny distributions, manuals, and anything else you want. Important: Everything done to/with any computer at any Install Fest, and in particular, at this Install Fest, is done at the specific request of the owner of the computer. As with all human endeavor, there is some risk of catastrophe. Back up all your data, before coming to the Fest! In addition, make a list of all hardware and media you bring to the Fest, and check that you have all your hardware and media when you leave the Fest. Useful reading: http://www.netcom.com/~casandra/mirror-of-luny-site/installfest/guidelines.… http://linuxmafia.com/bale/linuxprep.html http://www.luv.asn.au/if/preparation.php3 The LDP hardware HOW-TO: http://www.linuxdoc.org/HOWTO/Hardware-HOWTO/index.html Linux pre-install checklist: http://www.linuxdoc.org/HOWTO/mini/Pre-Installation-Checklist/index.html Linux post-install mini-checklist: http://algolog.tripod.com/postlnx.htm http://www.linuxdoc.org/HOWTO/mini/Post-Installation-Checklist/index.html http://www.lxny.org http://www.gnubies.org http://www.nylug.org http://www.sixgirls.org http://www.fsf.org http://www.debian.org http://www.multicians.org http://www.gnu.org/projects/dotgnu http://tinfoilhat.cultists.net http://www.nsa.gov/selinux http://www.linux.org http://www.debian.org/ports/hurd http://www.squeak.org http://www.freebsd.org http://www.netbsd.org http://www.openbsd.org http://www2.ics.hawaii.edu/~esb/prof/proj/hello http://www.daemonnews.org http://slashdot.org http://dmoz.org/Computers/Software/Operating_Systems http://www2.tunes.org/Review/OSes.html </blockquote> ----- End forwarded message -----

1 0

Re: [p2p-hackers] Verifying Claims of Full-Disk Encryption in Hard Drive Firmware
by Tom Ritter 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After reviewing the FIPs approval document for the drive[1], I've tried to put together a complete threat model outlining the major classes of attack on the hard drive in the interest of being rigorous. I'd like your input to see if I missed any you can think of. I've explicitly excluded DriveTrust (the proprietary stuff) from the threat model, and am only focusing on the ATA Standard. [1] http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1388.pdf ==================== In approximate physical/logical order, this is every attack I can conceive of: 1. The BIOS may have been replaced to record passwords 2. The keyboard or keyboard connection may be tapped/keylogged 3. The physical computer may have been tampered with physically installing hardware in any of its components 4. The Operating System may have been tampered with 5. The application used to interact with the hard drive (hdparm) may have been subverted 6. The SATA connection to the HDD may have been tapped 7. On the Drive 1. The hardware of the drive may been tampered with 2. Firmware 1. The firmware may be buggy allowing code execution on the Hard Disk Drive 2. The firmware may have been replaced. Supposedly, the firmware replace requires the firmware be signed with a private RSA key AND that the drive have the Load Firmware capability active. The public key is stored on the system storage area of the media 1. The firmware may be able to be loaded despite the load firmware capability inactive 2. The firmware load process may have a bug invalidating the signature 3. The malicious firmware may be appropriately signed 4. The public key in the system storage area may have been replaced, allowing untrustworthy firmware be loaded 3. The RAM of the device may be able to be read, allowing unknown compromising vectors. 1. The encryption key may be stored in RAM 2. The Seed Key and Seed used in the Random Number Generator may be read, allowing any new key that is generated to be guessed. 3. Internal states to the encryption process, or other operation of the firmware may be exposed 4. System Storage Area - An area of the drive that is supposed to only be able to be read by the firmware, and not the computer. 1. Secure ID aka Drive Owner (SHA Digest) 1. If the system area is able to be read, an unsalted simple SHA may be crackable 2. If the system area is able to be written, this may be replaced with a hash of a known password. 3. If the Drive Owner PIN has not been changed upon initialization, the PIN is printed on the drive 2. User & Master Passwords (SHA Digest) 1. If the System Area is able to be read, an unsalted simple SHA digest may be crackable 2. If the system area is able to be written, this may be replaced with a hash of a known password. 3. User/Master Encryption Keys (Plaintext?) 1. The the System Area is able to be read, plaintext storage of the keys allows full data recovery 2. If the Random Number Generator is not cryptographically secure, the encryption key may follow a guessable pattern 4. Firmware Public RSA Key 1. The the System Area is able to be written to, the firmware key may be replaced and new firmware loaded 5. User Storage Area - where your data is stored. 1. The data may not be encrypted with AES as promised 2. The cipher mode may not be suitable for filesystem encryption 3. The drive may be initialized in a non-random pattern, allowing usage analysis 4. The ciphertext may be stored in a way allowing block swapping, ciphertext injection, or otherwise damaging the integrity of the ciphertext 6. The Drive may be vulnerable to side channel attacks 1. Crypto operations may not be constant-time leaking data about the key structure or value 2. Drive may not draw power equally during crypto operations leaking data about the key structure or value 3. The drive may not be acoustically silent, leaking information about where on the platters the data is being written by listening to drive head movements. 4. The drive may not be protected against induced faults such as power manipulation, temperature extremes, electrical shocks, or physical shocks. 8. AT Password Security Protocol 1. Passwords may be attempted at a rapid sequence if a mechanism to reset the module is created. ==================== This groups those attacks together, and notes whether I consider them within the realm of testing for the drive. I'm not sure what will be doable easily or cheaply, but if I can verify the firmware, I'll try. Not Considered for evaluation User Coercion or Cooperation / "Evil Maid" Attacks 1. Hardware tampering or tapping of the Keyboard, Keyboard connection, Computer, SATA connection or HDD Pwnage 1. Subversion of the Operating System, BIOS, or hdparm Misconfiguration 1. Not changing the Master or Drive Owner password 2. Not enabling hard disk security Side Channel Attacks Considered for Evaluation 1. Buggy firmware 1. with regards to firmware signature verification 2. with regards to firmware replacement despite load firmware capability disabled 3. with regards to randomly selecting an encryption key 4. with regards to proper encryption 5. with regards to backdoors 6. with regards to memory trespass or other ?standard? vulnerabilities 2. Key Management 1. plaintext storage of encryption keys in system area 2. poor password hashing practices of passwords 3. Encryption 1. lack of encryption of user data 2. Improper cipher mode 3. Patterned initial fill of disk 4. Lack of ciphertext integrity 4. System Area 1. ability to read system area 2. ability to write system area ==================== Again, all comments welcome, but particularly interesting in talking to - Anyone familiar with these Seagate drives or DriveTrust. - Anyone familiar with BIOS support for the AT Security Spec, who can help me locate a new netbook to work with. - Anyone familiar with Data Recovery Services who could provide information on disk unlocking, AT password bypass, or moving platters between disks. - Anyone who has done this before. - -tom -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAk65zqYACgkQJZJIJEzU09sNfwCfX3APmmrtFBke2CI3Ia1Rot+4 cDQAn00ezd8VPehRXAYCIM80bh464I6A =AwIs -----END PGP SIGNATURE----- _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- 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: [ZS] ZS reboot seed
by Bryce Lynch 06 Jul '18

06 Jul '18

On Thu, Sep 20, 2012 at 8:14 AM, ZeroState.net <info(a)zerostate.net> wrote: > The important issue right this very moment, I think, is the one Niles has > raised. How might you create a 'reboot seed' (is there a technical term for > such things, if we were to go with a computer science analogy?) that somehow > avoids compromising specific individuals? Perhaps not, but let's at least > *attempt* a little creative brainstorming here... Why not publish the design pattern that the Zero State is using for its superstructure? hackerspaces.org has documented numerous design patterns that a small group can choose from if they want to bootstrap a hackerspace. All of them are formal descriptions of how hackerspaces did it so new ones don't have to reinvent the wheel: http://hackerspaces.org/wiki/Design_Patterns Telecomix has not only documented the quasi-design pattern of their collective but they've run workshops at conferences to teach other people how to do it. Alvin Toffler would be proud. Note that I'm not able to reach their wiki from work right now, others might be able to: werebuild.telecomix.org What I'm suggesting is that we take a page from the Hakatak Records Manifesto. Once we've got a good working structure and set of resources, let's document them someplace and make sure that everyone can access them. All it would take is a single copy of the design pattern document/software bundle to bootstrap another Zero State (-like group) somewhere else. If anything does happen, the bundle can be leaked for others to download and make use of; or some of us could use it to re-bootstrap. -- The Doctor [412/724/301/703] [ZS] https://drwho.virtadpt.net/ "I am everywhere." -- -- Zero State mailing list: http://groups.google.com/group/DoctrineZero ----- 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 Ian Grigg 06 Jul '18

06 Jul '18

Gecko/20040113 Thunderbird/0.4 To: Ivan Krstic <ccikrs1(a)cranbrook.edu> Cc: Metzdowd Crypto <cryptography(a)metzdowd.com> Subject: Re: Bank transfer via quantum crypto Sender: owner-cryptography(a)metzdowd.com Ivan Krstic wrote: > I have to agree with Perry on this one: I simply can't see a compelling > reason for the push currently being given to ridiculously overpriced > implementations of what started off as a lab toy, and what offers - in > all seriousness - almost no practical benefits over the proper use of > conventional techniques. You are looking at QC from a scientific perspective. What is happening is not scientific, but business. There are a few background issues that need to be brought into focus. 1) The QC business is concentrated in the finance industry, not national security. Most of the fiber runs are within range. 10 miles not 100. 2) Within the finance industry, the security of links is done majorly by using private lines. Put in a private line, and call it secure because only the operator can listen in to it. 3) This model has broken down somewhat due to the arisal of open market net carriers, open colos, etc. So, even though the mindset of "private telco line is secure" is still prevalent, the access to those lines is much wider than thought. 4) there is eavesdropping going on. This is clear, although it is difficult to find confirmable evidence on it or any stats: "Security forces in the US discovered an illegally installed fiber eavesdropping device in Verizon's optical network. It was placed at a mutual fund company ..shortly before the release of their quarterly numbers" Wolf Report March, 2003 (some PDF that google knows about.) These things are known as vampire taps. Anecdotal evidence suggests that it is widespread, if not exactly rampant. That is, there are dozens or maybe hundreds of people capable of setting up vampire taps. And, this would suggest maybe dozens or hundreds of taps in place. The vampires are not exactly cooperating with hard information, of course. 5) What's in it for them? That part is all too clear. The vampire taps are placed on funds managers to see what they are up to. When the vulnerabilities are revealed over the fibre, the attacker can put in trades that take advantage. In such a case, the profit from each single trade might be in the order of a million (plus or minus a wide range). 6) I have not as yet seen any suggestion that an *active* attack is taking place on the fibres, so far, this is simply a listening attack. The use of the information happens elsewhere, some batch of trades gets initiated over other means. 7) Finally, another thing to bear in mind is that the mutual funds industry is going through what is likely to be the biggest scandal ever. Fines to date are at 1.7bn, and it's only just started. This is bigger than S&L, and LTCM, but as the press does not understand it, they have not presented it as such. The suggested assumption to draw from this is that the mutual funds are *easy* to game, and are being gamed in very many and various fashions. A vampire tap is just one way amongst many that are going on. So, in the presence of quite open use of open lines, and in the presence of quite frequent attacking on mutual funds and the like in order to game their systems (endemic), the question has arisen how to secure the lines. Hence, quantum cryptogtaphy. Cryptographers and engineers will recognise that this is a pure FUD play. But, QC is cool, and only cool sells. The business circumstances are ripe for a big cool play that eases the fears of funds that their info is being collected with impunity. It shows them doing something. Where we are now is the start of a new hype cycle. This is to be expected, as the prior hype cycle(s) have passed. PKI has flopped and is now known in the customer base (finance industry and government) as a disaster. But, these same customers are desparate for solutions, and as always are vulnerable to a sales pitch. QC is a technology who's time has come. Expect it to get bigger and bigger for several years, before companies work it out, and it becomes the same disputed, angry white elephant that PKI is now. If anyone is interested in a business idea, now is the time to start building boxes that do "just like QC but in software at half the price." And wait for the bubble to burst. iang PS: Points 1-7 are correct AFAIK. Conclusions, beyond those points, are just how I see it, IMHO. --------------------------------------------------------------------- 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] The Code Breakers - A BBC World Documentary on Free/Open Source Software and Development
by Dewayne Hendricks 06 Jul '18

06 Jul '18

[Note: For those of you who don't get the BBC, this documentary will most likely be available soon on your friendly, neighborhood Darknet. DLH] ======================================================================== == COMING SOON! "The Code Breakers" A BBC World Documentary on Free/Open Source Software and Development http://www.apdip.net/news/fossdoc ======================================================================== == The famous digital divide is getting wider. A two-part documentary, "The Code Breakers," to be aired on BBC World starting 10 May 2006 examines whether free/open source software (FOSS) might be the bridge? FOSS contains 'source code' that can be used, copied, studied, modified and redistributed without restriction. It has been around for over 20 years but most PC owners are not aware that the Internet search engines and many computer applications run on FOSS. "It's not that FOSS has had a bad press, it has had no press because there is no company that 'owns' it," says executive producer Robert Lamb. "But we found that in the computer industry and among the afficionados, it is well known and its virtues well understood." The crew of the independent producers who made the film went to nearly a dozen countries around the world to see how the adoption of FOSS presents opportunities for industry and capacity development, software piracy reduction, and localization and customization for diverse cultural and development needs. Stories from "The Code Breakers" include computer and Internet access for school children in Africa, reaching the poor in Brazil, tortoise breeding programmes in the Galapagos, connecting villages in Spain, and disaster management in Sri Lanka. The documentary also includes interviews from key figures around the world. Intel, IBM, Sun and Microsoft all seem to agree that FOSS is a welcome presence in computer software. According to Jonathan Murray of Microsoft "The Open Source community stimulates innovation in software, it's something that frankly we feel very good about and it's something that we absolutely see as being a partnership with Microsoft." BBC World will air the two-part documentary at the following times: Episode One Wednesday 10 May 19:30 GMT Thursday 11 May 09:30 GMT Friday 12 May 16:30 GMT Monday 15 May 01:30 and 07:30 GMT Episode Two Wednesday 17 May 19:30 GMT Thursday 18 May 09:30 GMT Friday 19 May 16:30 GMT Monday 22 May 01:30 and 07:30 GMT For local times, please lookup your country in the TV Listings on BBC World's website http://www.bbcworld.com/content/template_tvlistings.asp?pageid=668. The International Open Source Network (IOSN), UNDP Asia-Pacific Development Information Programme (UNDP-APDIP), International Development Research Centre of Canada and UNESCO have participated in the production of this documentary. 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: Tor nodes blocked by e-gold
by Andrew Del Vecchio 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 We shall see what happens. In the meantime, I need to make sure that my Private Banking Guide product is updated to reflect these changes, and hopefully offer viable alternatives. I have some ideas in mind, but the trick is making them affordable/accessible. eGold is good because it has such a wide customer base, or at least did. Last year, the treasury sued the Liberty Dollar, and did some other iron fisted things. I don't think it is a coincidence that this kind of intimidation comes at a time when the US economy is showing signs of serious underlying weakness. The tor relevance is that hidden transaction network sites may be the wave of the future. eCache is one possible contender. Any thoughts? ~Andrew - --- Frivolous lawsuits. Unlawful government seizures. What's YOUR defense? Protect your assets, keep what you earn, and generate more income at the same time! Visit http://www.mpassetprotection.com/ today. On 05/01/2007 08:57 PM, KT wrote: > On 4/27/07, force44(a)safe-mail.net <force44(a)safe-mail.net> wrote: > >> ...Since 24 hours, e-gold has decided to block all TOR >> nodes...<snip> > > Didn't do them much good[1], did it? > > [1] http://www.e-gold.com/letter3.html > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGOB/agwZR2XMkZmQRA0t1AJ98jv5yi0nU+Y3sLT772O9GQiYnIACgwjc1 uTfeK1B10nVTSKvTCAVZKn0= =yyVi -----END PGP SIGNATURE----- ----- 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: [p2p-hackers] What we should build for the Egyptian (and other) protesters
by Jeff Rose 06 Jul '18

06 Jul '18

Great thread David. Helping in this kind of situation is what drew me to P2P, and I wish we would have this kind of discussion more often here. On Sat, Feb 5, 2011 at 12:28 AM, Julian Cain <julian(a)junglecat.org> wrote: > The answer is alternative communications. Ham, CB, etc. With those the possibilities are endless. They are very reliable. They are very scalable. They can carry "any" message payload. With the consolidation of ISPs building alternative networks is going to be the major hurdle we'll have to cross to enable a P2P internet, even on a local scale. Otherwise the people will be beholden to the kill switch, and (P2P) traffic that is deemed undesirable will be easily filtered. These steerable plasma antennas that are being looked at for future versions of wifi could be one technology that opens the door for community driven mesh networks: http://www.newscientist.com/article/mg20827904.600-wireless-at-the-speed-of… Maybe one important step for rapid adoption in crisis situations is P2P application download and install. If it was a one click operation to grab a mesh-enabled twitter app from your friend it would spread quickly. -Jeff _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- 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