- cypherpunks - lists.cpunks.org

Re: [bitcoin-list] [Bitcoin-development] BitMail - p2p Email 0.1. beta
by Eugen Leitl 30 Jul '13

30 Jul '13

----- Forwarded message from Mike Hearn <mike(a)plan99.net> ----- Date: Tue, 30 Jul 2013 14:12:51 +0200 From: Mike Hearn <mike(a)plan99.net> To: Wendell <w(a)grabhive.com> Cc: Bitcoin Dev <bitcoin-development(a)lists.sourceforge.net>, Gregory Maxwell <gmaxwell(a)gmail.com>, bitcoin-list(a)lists.sourceforge.net Subject: Re: [bitcoin-list] [Bitcoin-development] BitMail - p2p Email 0.1. beta The TPM is a piece of secure* hardware that provides various cryptographic services to the host system. It is important to understand that it is not a crypto accelerator. It is a place to store keys and small pieces of data (like hashes, counters) where it's difficult for someone to extract them even if they have physical access. The TPM is designed to support trusted computing, a rather splendid set of extensions to the x86 architecture that let you do remote attestation, software sealing and other things. Or at least it would be splendid if it had been really finished off and pushed to completion by the designers. Unfortunately due to various political issues it exists in a quasi-finished, semi-broken state which only experts can use. Without a doubt you have never run any software in a TC environment. As part of that role, the TPM provides some permanent storage in the form of NVRAM. Because the TPM is designed to be as cheap as possible, it has a limited number of write cycles. Normally you're meant to store Intel TXT launch control policies and sealed keys there, but Pond uses it in a different way by storing keys there that it encrypts local data with. By erasing the key in the TPM chips memory area, the data on disk is effectively destroyed too. This is useful because modern "disks" are often SSD drives, or physical metal disks that use log structured file systems. Because flash memory has a limited number of write cycles per cell, internally SSDs have firmware that remap writes from logical addresses to different physical addresses, the goal is to avoid wearing down the drive and extend its useful life. Normally it doesn't matter, but if you want to delete data such that it's really really gone, it obviously poses a problem. Using TPM NVRAM solves it, albiet, at a high usability cost. *note: actual tamper resistance of real-world TPM chips is not something that seems to have been studied much On Tue, Jul 30, 2013 at 1:27 PM, Wendell <w(a)grabhive.com> wrote: > Can you explain this process for those of us not too familiar with TPM > chips? > > -wendell > > grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 > > On Jul 30, 2013, at 10:40 AM, Mike Hearn wrote: > > > As a testament to the seriousness with which Pond takes forward > security, it can use the NVRAM in a TPM chip to reliably destroy keys for > data that an SSD device might have otherwise made un-erasable. > ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ 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://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

ZeroReserve -- a friend 2 friend payment scheme and Bitcoin exchange
by Eugen Leitl 30 Jul '13

30 Jul '13

Implemented as a RetroShare plugin. https://github.com/zeroreserve/ZeroReserve ZeroReserve Friend 2 Friend Payment and Bitcoin exchange Prerequisite for building is a successful RetroShare build and sqlite3. To build, checkout the sources to the plugins directory of Retroshare and build with $ qmake && make clean && make To install on Windows, drop the resulting DLL into the %APPDATA%\Retroshare\extensions directory. To install on Linux, drop the resulting shared object into ~/.retroshare/extensions

1 0

[cryptography] evidence for threat modelling -- street-sold hardware has been compromised
by Eugen Leitl 30 Jul '13

30 Jul '13

----- Forwarded message from ianG <iang(a)iang.org> ----- Date: Tue, 30 Jul 2013 14:07:44 +0300 From: ianG <iang(a)iang.org> To: Crypto discussion list <cryptography(a)randombit.net> Subject: [cryptography] evidence for threat modelling -- street-sold hardware has been compromised User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 It might be important to get this into the record for threat modelling. The suggestion that normally-purchased hardware has been compromised by the bogeyman is often poo-pooed, and paying attention to this is often thought to be too black-helicopterish to be serious. E.g., recent discussions on the possibility of perversion of on-chip RNGs. This doesn't tell us how big the threat is, but it does raise it to the level of 'evidenced'. http://www.afr.com/p/technology/spy_agencies_ban_lenovo_pcs_on_security_HVg… Computers manufactured by the world’s biggest personal computer maker, Lenovo, have been banned from the “secret” and ‘‘top secret” networks of the intelligence and defence services of Australia, the US, Britain, Canada, and New Zealand, because of concerns they are vulnerable to being hacked. Multiple intelligence and defence sources in Britain and Australia confirmed there is a written ban on computers made by the Chinese company being used in “classified” networks. The ban was introduced in the mid-2000s after intensive laboratory testing of its equipment allegedly documented “back-door” hardware and “firmware” vulnerabilities in Lenovo chips. ... _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [bitcoin-list] [Bitcoin-development] BitMail - p2p Email 0.1. beta
by Eugen Leitl 30 Jul '13

30 Jul '13

----- Forwarded message from Mike Hearn <mike(a)plan99.net> ----- Date: Tue, 30 Jul 2013 10:40:45 +0200 From: Mike Hearn <mike(a)plan99.net> To: Gregory Maxwell <gmaxwell(a)gmail.com> Cc: Bitcoin Dev <bitcoin-development(a)lists.sourceforge.net>, bitcoin-list(a)lists.sourceforge.net Subject: Re: [bitcoin-list] [Bitcoin-development] BitMail - p2p Email 0.1. beta For people who are interested in such technologies, I recommend looking at Pond: https://pond.imperialviolet.org/ It is written by Adam Langley, so it comes with some serious credentials behind it. It provides asynchronous email-like messaging that's forward secure, resistant to traffic analysis and the whole thing runs over Tor. Messages are stored for a week and are strictly limited in size. There's no spam because nobody has an address - instead you have to grant someone the ability to message you by giving them a small file. So, not really intended as an email competitor convenience wise, but it has many interesting ideas and a reasonable GUI. As a testament to the seriousness with which Pond takes forward security, it can use the NVRAM in a TPM chip to reliably destroy keys for data that an SSD device might have otherwise made un-erasable. The main downside - it's written in Go :) On Tue, Jul 30, 2013 at 8:50 AM, Gregory Maxwell <gmaxwell(a)gmail.com> wrote: > On Mon, Jul 29, 2013 at 10:01 PM, Randolph D. <rdohm321(a)gmail.com> wrote: > > Secure P2P Email from Friend to Friend without relying on a central > server. > > Key- / Repleo-Exchange. > > Full decentral Email-Network using the Echo Protocol. > > Store Email for Offline-Friends in the P2P Network. > > Chat and Instant Messaging is build in. Define & Add your friends. > > Strong e2e Multi-Encryption (PGP-kind/AES over SSL: using libgcrypt). > > Libspoton Integration. > > Additional Security Layer with the GB-Feature for Emails. > > Preventing Data Retention (VDS). WoT-less. > > HTTP & HTTPS Connections. > > Open Source. BSD License. > > > > anyone with a Server? Key? > > Keep safe everyone: > > A number of apparent sock accounts has been posting about what appears > to be the same software under the name "goldbug" for a couple days > now: > > e.g. > https://lists.torproject.org/pipermail/tor-talk/2013-July/029107.html > https://lists.torproject.org/pipermail/tor-talk/2013-July/029125.html > http://lists.gnupg.org/pipermail/gnupg-users/2013-July/047137.html > > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ 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://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[bitcoin-list] BitMail - p2p Email 0.1. beta
by Eugen Leitl 30 Jul '13

30 Jul '13

----- Forwarded message from "Randolph D." <rdohm321(a)gmail.com> ----- Date: Tue, 30 Jul 2013 07:01:02 +0200 From: "Randolph D." <rdohm321(a)gmail.com> To: bitcoin-development(a)lists.sourceforge.net, bitcoin-list(a)lists.sourceforge.net Subject: [bitcoin-list] BitMail - p2p Email 0.1. beta http://bitmail.sourceforge.net/ - Secure P2P Email from Friend to Friend without relying on a central server. - Key- / Repleo-Exchange. - Full decentral Email-Network using the Echo Protocol. - Store Email for Offline-Friends in the P2P Network. - Chat and Instant Messaging is build in. Define & Add your friends. - Strong e2e Multi-Encryption (PGP-kind/AES over SSL: using libgcrypt<http://www.gnu.org/software/libgcrypt/>). - Libspoton Integration. - Additional Security Layer with the GB-Feature for Emails. - Preventing Data Retention (VDS). WoT-less. - HTTP & HTTPS Connections. - Open Source. BSD License. anyone with a Server? Key? ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ 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://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Moscow Metro says new tracking system is to find stolen phones; no one believes them
by Eugen Leitl 30 Jul '13

30 Jul '13

http://arstechnica.com/tech-policy/2013/07/moscow-metro-says-new-tracking-s… Moscow Metro says new tracking system is to find stolen phones; no one believes them Experts: Russians are probably using fake cell tower devices for surveillance. by Cyrus Farivar - July 29 2013, 11:10pm +0200 On Monday, a major Russian newspaper reported that Moscow’s metro system is planning what appears to be a mobile phone tracking device in its metro stations—ostensibly to search for stolen phones. According to Izvestia (Google Translate), Andrey Mokhov, the operations chief of the Moscow Metro system’s police department, said that the system will have a range of five meters (16 feet). “If the [SIM] card is wanted, the system automatically creates a route of its movement and passes that information to the station attendant,” Mokhov said. Many outside experts, both in and outside Russia, though, believe that what local authorities are actually deploying is a “stingray,” or “IMSI catcher”—a device that can fool a phone and SIM into reading from a fake mobile phone tower. (IMSI, or an International Mobile Subscriber Identity number, is a 15-digit unique number that sits on every SIM card.) Such devices can be used as a simple way to see what phone numbers are being used in a given area or even to intercept the audio of voice calls. The Moscow Metro did not immediately respond to our request for comment. “Many surveillance technologies are created and deployed with legitimate aims in mind, however the deploying of IMSI catchers sniffing mobile phones en masse is neither proportionate nor necessary for the stated aims of identifying stolen phones,” Eric King of Privacy International told Ars. “Likewise the legal loophole they claim to be using to legitimize the practice—distinguishing between tracking a person from a SIM card—is nonsensical and unjustifiable. It's surprising it's being discussed so openly, given in many countries like the United Kingdom, they refuse to even acknowledge the existence of IMSI catchers, and any government use of the technology is strictly national security exempted.” These devices are in use, typically by law enforcement agencies worldwide, including some in the United States. Portable, commercial IMSI catchers are made by Swiss and British companies, among others, but in 2010, security researcher Chris Paget announced that he built his own IMSI catcher for only $1,500. Still, mobile security remains spy-versus-spy to some degree, each measure matched by a countermeasure. In December 2011, Karsten Nohl, another noted mobile security researcher, released "Catcher Catcher"—a piece of software that monitors network traffic and looks at the likelihood an IMSI catcher is in use. Keir Giles, of the Conflict Studies Research Centre, an Oxford-based Russian think tank, told Ars that Russian authorities are claiming a legal technicality. "They are claiming that although they are legally prohibited from indiscriminate surveillance of people, the fact that they are following SIM cards which are the property of the mobile phone operators rather than the individuals carrying those SIM cards makes the tracking plans perfectly legal," he said, adding that this reasoning is "weaselly and ridiculous." The Russian newspaper also quoted Alexander Ivanchenko, executive director of the Russian Security Industry Association, who pointed out that even to be effective, such a system would need these devices every 10 meters (32 feet). “It is obvious that the cost of the system is not commensurate with the value of all the stolen phones,” he said. “Also, effective anti-theft technology is already known: in the US, for example, the owner of the stolen phone knows enough to call the operator—and the stolen device stops working, even if another SIM-card is inserted.” Two major Russian mobile providers, Beeline and Megafon, have told Russian media (Google Translate) that they are unaware of this supposed anti-theft measure. On the other hand, BBC Russian reports (Google Translate) that the system is due to come online in late 2013 or early 2014.

1 0

[Cryonet_AP] Lawyers in Thailand ban Bitcoin
by Eugen Leitl 30 Jul '13

30 Jul '13

----- Forwarded message from John de Rivaz <John(a)deRivaz.com> ----- Date: Tue, 30 Jul 2013 09:07:32 +0100 From: John de Rivaz <John(a)deRivaz.com> To: Cryonet_AP(a)yahoogroups.com Subject: [Cryonet_AP] Lawyers in Thailand ban Bitcoin X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 Reply-To: Cryonet_AP(a)yahoogroups.com Thailand has become the first country to ban bitcoins after the central bank ruled it is not a currency. In a statement on its website , Bitcoin said it had given a presentation to the Bank of Thailand about how the currency works in a bid to operate in the country. However, at the end of the meeting, "senior members of the Foreign Exchange Administration and Policy Department advised that due to lack of existing applicable laws, capital controls and the fact that Bitcoin straddles multiple financial facets... Bitcoin activities are illegal in Thailand". more on http://uk.finance.yahoo.com/news/bitcoins-banned-thailand-203840004.html -- Sincerely, John de Rivaz: http://John.deRivaz.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

NSA Utah Data Center Cabling, Emanations and Bizarre Planning
by John Young 29 Jul '13

29 Jul '13

Not much publicly available on the cabling and emanations protection of the NSA Utah Data Center. Surely highly advanced measures are being applied. Google Earth shows a couple of stages of construction, Bing Maps a couple more. AP has published a dozen or so hi-rez photos of construction. A lot of earthwork was done to create a flat site on a mountain side (preceded by a small air field). No indication of underground construction except pits and trenches under the buildngs. With none on the surface there must be trenches for power and signal cable. No antenna have appeared on the site for transceiving data like those of other of its data centers, so presumably it is done by UG fiber optic (or antenna are hidden or remote). Photos of construction progress of the two data buildings show windowless envelopes made of panels and flat roofs without various rooftop ductwork, grilles, piping and the like which appear on roofs of other NSA and TLA facilities which might emanate signal although not likely. (Some are littered with the stuff which might be decoy.) Steel structural framing is shown at Utah despite its known transmittal of inadvertent signal, compared to say, reinforced concrete, metalized fabric or synthetics. although are ample countermeasures available. The pairing of structures at Utah, two of each type, data center, generator, AC, fuel tanks, etc., show redundancy also not seen elsewhere. Not much to see of protection against missiles and aerial attack but that is the same at other NSA facilities. Wonder what supports that confidence. The odd bent shape of the site plan, with buildings not parallel to one another is intriguing. Could be aesthetic but may have another role, say to disperse richochet of inadvertent emanations. Quite a few recent government buildings avoid the traditional rectilinear site planning of buildings long considered to be most cost effective and authoritarian. Some like NGA HQ, NSA Utah and several at Ft. Meade look almost byzantine in layout, if not a shrewd design to limit echo, amplification, richochet, or best, to befuddle satellite peepers.

3 2

Re: [p2p-hackers] Dealing with malicious nodes in decentralized p2p network
by Eugen Leitl 29 Jul '13

29 Jul '13

----- Forwarded message from Michael Rogers <michael(a)briarproject.org> ----- Date: Mon, 29 Jul 2013 16:46:35 +0100 From: Michael Rogers <michael(a)briarproject.org> To: theory and practice of decentralized computer networks <p2p-hackers(a)lists.zooko.com> Subject: Re: [p2p-hackers] Dealing with malicious nodes in decentralized p2p network User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 Reply-To: theory and practice of decentralized computer networks <p2p-hackers(a)lists.zooko.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm not sure whether your message just came through to the list or whether I just noticed it. Either way, I hope it's not too late to reply. The following papers describe attacks that can be carried out by malicious nodes in structured P2P networks: E. Sit and R. Morris. Security considerations for peer-to-peer distributed hash tables. 1st International Workshop on Peer-to-Peer Systems (IPTPS ?02), Cambridge, MA, USA, March 2002. http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.11.7175 M. Castro, P. Druschel, A. Ganesh, A. Rowstron, and D.S. Wallach. Secure routing for structured peer-to-peer overlay networks. 5th Symposium on Operating Systems Design and Implementation, Boston, MA, USA, December 2002. http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.118.1870 I'd recommend checking out the papers that cite those papers, some of which propose solutions to some of the attacks. Cheers, Michael On 13/03/13 05:44, offbynull wrote: > Hi, > > Does anyone know of any strategies to prevent, identify, or > work-around malicious nodes in a structured overlay? I'm > specifically interested in Chord's ring overlay. It seems like > there are a lot of things a malicious node could to to interfere > with normal operations (e.g. routing / lookup / etc..), or to > bypass certain regions of the ring. > > Examples of things that a malicious node could do ... > > 1. Imagine someone wanted to prevent others from accessing a > key-value pair. That person would create a malicious node with an > id of hash(key), ensuring that queries for that key would end up at > the malicious node. When the malicious node receives queries for > that key, it simply ignores them or responds that the key was never > set. > > 2. This is similar to the one above. Imagine someone wanted to > prevent others from accessing a key-value pair, but a legitimate > node already existed with an id of hash(key). That person would > create a malicious node with an id of hash(key) - 1. When other > nodes ask the malicious node to be routed to that key, the > malicious node would respond with a node other than it's successor, > ensuring that the request never gets routed to its true > destination. > > 3. Imagine someone wanted to cut out a portion of the nodes in the > overlay. That person would create a malicious node that has its > finger table set to skip over a bunch of existing nodes in front of > it. > > > Are there strategies to deal with this, or is this just something > that's expected with Chord's design (as in peers can't be untrusted > nodes)? > > _______________________________________________ p2p-hackers mailing > list p2p-hackers(a)lists.zooko.com > http://lists.zooko.com/mailman/listinfo/p2p-hackers > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJR9o5bAAoJEBEET9GfxSfMj0AIALZ+lSnA7GDh+Y3iifdVotwK YXdjGjv+qJcvOIO/rHtTEyPMzp7yqz0X0VxeiC8XIjXP6rwvFGOXuClqd0NAjFW9 lHYtO9tHBkCV/LOU5hHrD3510Ry6gYkuDnyDeWBlwQ2i/zUU160PqGr+Esd1IpNP zu5JKSHHq61wr5GisXOB+pWOxrKEEKtQAtv3ibFNBDXhGyJwg+U/LCe9Q14V9Q4t BiOKgce8xHhbytY8B/5t3HW6cCavQAq/TR0CfjpWRtz823hs0lTdepJJXPnKVYIo HD0u+cwnCGr7LNF5szMvkvdEkyXsbXGLYX+2cK7aHBPO4kGoXw5DrNAhS2Gkh+g= =xMmD -----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://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

how much havoc can a compromised baseband do to a Guardian ROM device?
by Eugen Leitl 29 Jul '13

29 Jul '13

Anyone knows whether a Nexus 4 baseband processor has r/w access to system memory? The firmware doesn't seem to be loaded at boot, so I presume it's entirely out of reach/ reversing?

2 1