July 2018 - cypherpunks-legacy

Re: [tahoe-dev] switching from introducers to gossip?
by Brian 06 Jul '18

06 Jul '18

On 6/14/12 1:02 PM, Zooko Wilcox-O'Hearn wrote: > Brian has been posting patches that move away from using introducers > at all in favor of "gossip". Now if I understand correctly, gossip is > simply "every node is an introducer (in addition to whatever other > jobs it does)". Yeah, the general idea is that all nodes provide the "grid-control" service, in addition to the "storage" service they might be providing right now. Nodes announce both "grid-control" and "storage" via the same introducer Announcements as before. The old Introducer becomes a node that only provides "grid-control", on a pre-published FURL. "grid-control" lets you publish Announcements (either your own or ones you're forwarding from others), and subscribe to the same. Once that is in place, and we have some code to prevent infinite flooding loops, there are several different approaches you could take: * fully-connected mesh: every node makes a Foolscap connection to every grid-control provider they hear about, subscribe to hear about all announcements, and publish any announcements that the other side doesn't already know about. * opportunistic: clients only connect to storage servers, and storage servers don't make outbound connections to anybody, but if you *do* happen to be connected to someone who also offers "grid-control", then connect to their grid-control object too and exchange Announcements * cluster-of-Introducers: normal nodes don't offer grid-control, but multiple Introducers do, and all of them know about each other. All nodes connect to all grid-control providers (which means all Introducers). * one Introducer: this is just a degenerate cluster-of-Introducers > Hrm. This idea of gossip conflicts with my idea that each server > should attempt to connect to all clients -- and only to clients -- and > that each client should attempt to connect to all servers -- and only > to servers (#344, #1086). I think we can probably accomodate that. I'm optimizing for our two main use cases: friendnet and paid-service. In the friendnet, nearly all nodes are both a client *and* a server. Client-only nodes (like the one I occasionally connect to VG2 to investigate bug reports), or server-only nodes (imagine a paid storage server, the "rent-a-friend" idea I've talked about before) are rare. So ruling out C->C or S->S connections doesn't change very much. In the paid-service case (allmydata), we don't want clients talking to each other (they're all behind NAT anyways). But we could allow S->S connections without problems, and if all servers know about all other servers, then we could add new servers to the grid by just connecting them to at least one existing server, and knowledge of them would flood quickly and reliably to everyone else. > It would also interact somewhat poorly with #444 Note that we don't need active+online connections to all other nodes all the time. Connecting with less than 100% duty cycle would still get the information distributed eventually. What I'm really expecting is that we'll use Zooko's clever log-scaling flooding techniques (from Mnet) to limit the amount of traffic and connections but still achieve rapid+reliable diffusion of knowledge. > In fact, why do we need to switch from introducers to gossip at all? > Could we finish the rest of the #466 new-introduction-protocol and > related accounting infrastructure while leaving the current > centralized introducer (or the #68 multiple introducers) alone? They aren't interdependent, for sure. Now that #466 is in trunk, we've got a handle on Announcements (i.e. the node key that signs each one) so recipients can make decisions about whether they'll accept the thing being introduced or not, independently of the channel by which they received the announcement. *That* is important to unlock alternate introduction topologies: without signed announcements, the only form of grid control you can get is to limit who gets access to the Introducer (as the VG2 folks accomplish by changing the introducer.furl each time it is accidentally leaked). But with signed announcements, you don't need control over the channel to retain control over which servers your client uses, or over which clients your server will serve. You could even safely use a single massive universe-spanning broadcast channel, if you could make it efficient enough. And the first steps of Accounting don't require changes to introduction at all. These steps will enable tracking of who-uses-what, and manual control (probably by pasting nodeids into tahoe.cfg) over both which-servers-should-I-use and which-clients-should-I-accept. This needs signed announcements (to get a strong nodeid of a server) and signed accounting-facet-of-storage-server FURLification messages (so clients can demonstrate control of a key). The main question is whether nodes which are both clients and servers should have a single key, or two separate keys (I prefer a single key, because it makes reciprocal storage-permission grants easier). The second steps of Accounting, where we try to make things easy and automatic for our common use cases, is where we start getting into my Invitation scheme, and is where gossip becomes more interesting. What I really want is to make it super-easy for a new user to get their node running and connected to their friend's existing grid. And, more importantly, for that *first* friend to set up that grid. Imagine for a moment that we have a nicely-packaged OS-X or debian app, already distributed via the mac App Store or through apt/etc. And also imagine that we've got uPnP working (or something equivalent, maybe involving a relay or some helper service that we run), so NAT isn't a problem. Then this is my goal: The first friend (Alice) hears about Tahoe from her favorite blog, and installs it with her favorite package manager. She lauches it for the first time, and it asks "start your own grid, or join someone else's?", and she picks "start your own". Her node starts up, establishes an external IP address, sets itself up to restart at reboot, and announces that Alice is now the proud member of a 1-node grid, and that she should invite a few friends to join before she'll get more than educational value out of the system. She hits the "Invite A Friend" button, types Bob's (pet)name and email address into the box, and the node sends Bob a message with links to the application, instructions, and an invitation code. Bob gets Alice's email, downloads+installs the app, and pastes in the invitation code. The next thing he sees is a picture of the two-node grid, with the Alice and Bob nodes labeled, and he can upload files and either retrieve them locally or share them with Alice. Later, Alice and Bob invite other people to join in their grid. The only grid-specific coordinates that each new member needs is a single-use invitation code like "d77hbsmkgeufjpwacu3ywkbwem". Eventually, Alice leaves the grid, but her departure doesn't affect the remaining members: they can still connect and exchange shares as usual. All grid members get a control panel where they can see who else is using their storage, allow/deny access, and control where their own node places shares. By default, anyone who gets invited to join the grid gets full access to storage on all members' servers, but access can be revoked at any time. The corresponding story with an AllMyData-like paid-service is: Alice visits allmydata.com, signs up for the service with a credit card, downloads the client app and gets an invitation code for her account. She pastes the invitation code into the "accept an invitation" box when her app starts up. Her app connects to all AllMyData storage servers and is allowed storage access. New servers can be added without Alice's involvement. Any subset of the servers can go away without affecting her ability to connect to (or learn about) the rest. To support those stories, I don't want Alice (or AllMyData) to be running a single Introducer, or even a cluster of Introducers. Alice, Bob, and the other members of the friendnet should *all* be helping each other connect to the rest of their grid.. otherwise they have to pay attention to how many Introducers are present, and who's responsible for them, and make sure there are enough left available to accomodate changes. Does that help explain my interest in gossip-based introduction? cheers, -Brian _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- 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: [IP] Can you be compelled to give a password? [was:
by Jonathan H. Care 06 Jul '18

06 Jul '18

Police Blotter: Laptop border searches OK'd] > >From: "Patrick W. Gilmore" <patrick(a)ianai.net> >Date: July 28, 2006 2:11:45 PM EDT >To: dave(a)farber.net >Cc: "Patrick W. Gilmore" <patrick(a)ianai.net> >Subject: Can you be compelled to give a password? [was: Police >Blotter: Laptop border searches OK'd] > > In the UK, it is a crime under the Regulation of Investigatory Powers Act 2000 not to disclose a password, encryption key, session key, or plaintext when required to do so by law enforcement. This applies both to end parties in the communication, and intermediates (such as telecommunication companies). Note that some people have been known to perform a risk assessment, and have elected the milder penalty associated with refusal to disclose, rather than face the harsher penalties that come with conviction of the crime that led to them being the target of investigation. I have a feeling the the Police and Justice bill 2006 has some further measures planned in this direction, but can't cite references at the moment. > >Seems there might be some 'self-incriminatory' arguments here. >Perhaps even an "unreasonable search" argument. But IANAL. > Kind Regards, Jonathan Care Director, The Security Practice Ltd. Tel: +44 (0)845 123 5413 Email: j.care(a)securitypractice.com Skype: jonathancare ------------------------------------- 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> 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

[IP] more on Can you be compelled to give a password? [was: Police Blotter: Laptop border searches OK'd]
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

Re: [tahoe-dev] switching from introducers to gossip?
by Brian 06 Jul '18

06 Jul '18

On 6/14/12 1:02 PM, Zooko Wilcox-O'Hearn wrote: > Brian has been posting patches that move away from using introducers > at all in favor of "gossip". Now if I understand correctly, gossip is > simply "every node is an introducer (in addition to whatever other > jobs it does)". Yeah, the general idea is that all nodes provide the "grid-control" service, in addition to the "storage" service they might be providing right now. Nodes announce both "grid-control" and "storage" via the same introducer Announcements as before. The old Introducer becomes a node that only provides "grid-control", on a pre-published FURL. "grid-control" lets you publish Announcements (either your own or ones you're forwarding from others), and subscribe to the same. Once that is in place, and we have some code to prevent infinite flooding loops, there are several different approaches you could take: * fully-connected mesh: every node makes a Foolscap connection to every grid-control provider they hear about, subscribe to hear about all announcements, and publish any announcements that the other side doesn't already know about. * opportunistic: clients only connect to storage servers, and storage servers don't make outbound connections to anybody, but if you *do* happen to be connected to someone who also offers "grid-control", then connect to their grid-control object too and exchange Announcements * cluster-of-Introducers: normal nodes don't offer grid-control, but multiple Introducers do, and all of them know about each other. All nodes connect to all grid-control providers (which means all Introducers). * one Introducer: this is just a degenerate cluster-of-Introducers > Hrm. This idea of gossip conflicts with my idea that each server > should attempt to connect to all clients -- and only to clients -- and > that each client should attempt to connect to all servers -- and only > to servers (#344, #1086). I think we can probably accomodate that. I'm optimizing for our two main use cases: friendnet and paid-service. In the friendnet, nearly all nodes are both a client *and* a server. Client-only nodes (like the one I occasionally connect to VG2 to investigate bug reports), or server-only nodes (imagine a paid storage server, the "rent-a-friend" idea I've talked about before) are rare. So ruling out C->C or S->S connections doesn't change very much. In the paid-service case (allmydata), we don't want clients talking to each other (they're all behind NAT anyways). But we could allow S->S connections without problems, and if all servers know about all other servers, then we could add new servers to the grid by just connecting them to at least one existing server, and knowledge of them would flood quickly and reliably to everyone else. > It would also interact somewhat poorly with #444 Note that we don't need active+online connections to all other nodes all the time. Connecting with less than 100% duty cycle would still get the information distributed eventually. What I'm really expecting is that we'll use Zooko's clever log-scaling flooding techniques (from Mnet) to limit the amount of traffic and connections but still achieve rapid+reliable diffusion of knowledge. > In fact, why do we need to switch from introducers to gossip at all? > Could we finish the rest of the #466 new-introduction-protocol and > related accounting infrastructure while leaving the current > centralized introducer (or the #68 multiple introducers) alone? They aren't interdependent, for sure. Now that #466 is in trunk, we've got a handle on Announcements (i.e. the node key that signs each one) so recipients can make decisions about whether they'll accept the thing being introduced or not, independently of the channel by which they received the announcement. *That* is important to unlock alternate introduction topologies: without signed announcements, the only form of grid control you can get is to limit who gets access to the Introducer (as the VG2 folks accomplish by changing the introducer.furl each time it is accidentally leaked). But with signed announcements, you don't need control over the channel to retain control over which servers your client uses, or over which clients your server will serve. You could even safely use a single massive universe-spanning broadcast channel, if you could make it efficient enough. And the first steps of Accounting don't require changes to introduction at all. These steps will enable tracking of who-uses-what, and manual control (probably by pasting nodeids into tahoe.cfg) over both which-servers-should-I-use and which-clients-should-I-accept. This needs signed announcements (to get a strong nodeid of a server) and signed accounting-facet-of-storage-server FURLification messages (so clients can demonstrate control of a key). The main question is whether nodes which are both clients and servers should have a single key, or two separate keys (I prefer a single key, because it makes reciprocal storage-permission grants easier). The second steps of Accounting, where we try to make things easy and automatic for our common use cases, is where we start getting into my Invitation scheme, and is where gossip becomes more interesting. What I really want is to make it super-easy for a new user to get their node running and connected to their friend's existing grid. And, more importantly, for that *first* friend to set up that grid. Imagine for a moment that we have a nicely-packaged OS-X or debian app, already distributed via the mac App Store or through apt/etc. And also imagine that we've got uPnP working (or something equivalent, maybe involving a relay or some helper service that we run), so NAT isn't a problem. Then this is my goal: The first friend (Alice) hears about Tahoe from her favorite blog, and installs it with her favorite package manager. She lauches it for the first time, and it asks "start your own grid, or join someone else's?", and she picks "start your own". Her node starts up, establishes an external IP address, sets itself up to restart at reboot, and announces that Alice is now the proud member of a 1-node grid, and that she should invite a few friends to join before she'll get more than educational value out of the system. She hits the "Invite A Friend" button, types Bob's (pet)name and email address into the box, and the node sends Bob a message with links to the application, instructions, and an invitation code. Bob gets Alice's email, downloads+installs the app, and pastes in the invitation code. The next thing he sees is a picture of the two-node grid, with the Alice and Bob nodes labeled, and he can upload files and either retrieve them locally or share them with Alice. Later, Alice and Bob invite other people to join in their grid. The only grid-specific coordinates that each new member needs is a single-use invitation code like "d77hbsmkgeufjpwacu3ywkbwem". Eventually, Alice leaves the grid, but her departure doesn't affect the remaining members: they can still connect and exchange shares as usual. All grid members get a control panel where they can see who else is using their storage, allow/deny access, and control where their own node places shares. By default, anyone who gets invited to join the grid gets full access to storage on all members' servers, but access can be revoked at any time. The corresponding story with an AllMyData-like paid-service is: Alice visits allmydata.com, signs up for the service with a credit card, downloads the client app and gets an invitation code for her account. She pastes the invitation code into the "accept an invitation" box when her app starts up. Her app connects to all AllMyData storage servers and is allowed storage access. New servers can be added without Alice's involvement. Any subset of the servers can go away without affecting her ability to connect to (or learn about) the rest. To support those stories, I don't want Alice (or AllMyData) to be running a single Introducer, or even a cluster of Introducers. Alice, Bob, and the other members of the friendnet should *all* be helping each other connect to the rest of their grid.. otherwise they have to pay attention to how many Introducers are present, and who's responsible for them, and make sure there are enough left available to accomodate changes. Does that help explain my interest in gossip-based introduction? cheers, -Brian _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- 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: [cryptography] attacks against bitcoin
by Adam Back 06 Jul '18

06 Jul '18

I was thinking a DoS might be a problem. If you could prevent the p2p network broadcasting or receiving broadcasts, maybe you could be the only person able to proceed with minting. If you could keep that up for a while you could reduce the difficulty and create bitcoins with lower cost. A full enough DoS maybe difficult to do as the network is p2p. Also maybe if you could temporarily come in with significantly more compute power than the rest of the network - eg rent ec2's entire gpcpu farm for a little while, or use of a huge bot farm, you could undo transactions. If those transactions were you selling bitcoins, you could then sell them again. eg buy, then sell $100k coins (minus the spread/fluctuation), rent $50k worth of compute for a while; sell the $100k of coins again ... profit :) Adam On Sun, Jun 12, 2011 at 12:16:01PM +0200, Eugen Leitl wrote: > > How safe is the bitcoin cryptosystem and the communication network > against targeted attacks? _______________________________________________ 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://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
by Ondrej Mikle 06 Jul '18

06 Jul '18

This thread is amazing. I've known just a fractions/hints of the practices described here. Few comments/questions inline/below. On 12/04/11 07:37, Lucky Green wrote: > Concur. The standard sub-CA contracts contain a right to audit the > number of certs issued, like any enterprise-wide software license > agreement does include a right to audit used seats. Not once in over 30 > years have I seen such an audit performed. There is no reason to audit: > when you buy a sub-CA, the public CA's rep will work out a contract that > gives you the right to use as many certs and more as you conceivably > could use given the application to which you plan to put the sub-CAs. > Keeping count of actual certs issued would only add cost to both the > sub-CA customer and the root CA provider. There is simply no business > case for auditing the number of certs issued. On 12/02/11 11:02, Peter Gutmann wrote: > It's not just a claim, I've seen them too. For example I have a cert issued > for google.com from such a MITM proxy. I was asked by the contributor not to > reveal any details on it because it contains the name and other info on the > intermediate CA that issued it, but it's a cert for google.com used for deep > packet inspection on a MITM proxy. I also have a bunch of certs from private- > label CAs that chain directly up to big-name public CAs, there's no technical > measure I can see in them anywhere that would prevent them from issuing certs > under any name. How do MitM boxes react when they MitM connection to a server with self-signed cert (or cert issued by an obsure CA not trusted by MitM box)? Do the boxes send to client also an auto-generated self-signed cert that generates warning or "re-sign" it so that client sees valid chain? MitM-re-signing an unverifiable chain of server to a chain that's trusted at the MitM-ed client would be hilarious, allowing to MitM a MitM box (though this would be an easily avoidable mistake to make). Given the state of security/auditing of "private sub-CAs" as described, was there ever a report of a breach (e.g. stolen key, fraudulently issued certs)? <blatant_CA_bashing> While chasing data from my scans around, I checked history of few CAs. Most oddly hilarious "trusted" CA is probably SAIC (Science Applications International Corporation). Reason: SAIC led the development of Trailblazer Project for NSA (in my book this tops much-too-obvious CAs of other TLA agencies). Also, Network Solutions, L.L.C (also a CA) was owned by SAIC at some time. Later, Network Solutions did not acquire exactly "good guy" reputation. Don't get me wrong: I'm not claiming either of the mentioned CAs did anything egregious subverting CA-trust placed in them. I have no intention to single them out as "shady", additional search would turn up many more CAs. </blatant_CA_bashing> Hypothetical question: assume enough people get educated how to spot the MitM box at work/airport/hotel. Let's say few of them post the MitM chains publicly which point to a big issuing CA. It was said (by Peter I think) that nothing would likely happen to big issuing CAs (too-big-to-fail). Would the MitM-ing sub-CAs take the fall? (lose license and invested funds) Ondrej _______________________________________________ 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://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [silk] Flame is Lame
by Udhay Shankar N 06 Jul '18

06 Jul '18

On 12/06/12 12-Jun-2012;6:04 PM, Biju Chacko wrote: > http://www.f-secure.com/weblog/archives/00002383.html More on this, for those not following along: http://www.wired.com/threatlevel/2012/06/us-and-israel-behind-flame/ Report: US and Israel Behind Flame Espionage Tool By Kim Zetter June 19, 2012 | The United States and Israel are responsible for developing the sophisticated espionage rootkit known as Flame, according to anonymous Western sources quoted in a news report. The malware was designed to provide intelligence about Iranbs computer networks and spy on Iranian officials through their computers as part of an ongoing cyberwarfare campaign, according to the Washington Post. The program was a joint effort of the National Security Agency, the CIA and Israelbs military, which also produced the Stuxnet worm that is believed to have sabotaged centrifuges used for Iranbs uranium enrichment program in 2009 and 2010. b This is about preparing the battlefield for another type of covert action,b a former high-ranking US intelligence official told the Post. b Cyber collection against the Iranian program is way further down the road than this.b Flame was discovered last month by Russia-based antivirus firm Kaspersky Lab, following reports in Iran that malware aimed at computers belonging to that countrybs oil industry had wiped data from the computers. In trying to investigate that issue, Kaspersky came across components of the Flame malware, which the researcher believed was not directly connected to the malware that wiped the Iranian computers clean but which they believed was created by the same nation states behind Stuxnet. Kaspersky disclosed last week that Flame in fact contained some of the same code as Stuxnet, directly tying the two pieces of malware together. According to the Post Flame was designed to infiltrate highly secure networks in order to siphon intelligence from them, including information that would help the attackers map a target network. Flame, as previously reported, can activate a computerbs internal microphone to record conversations conducted via Skype or in the vicinity of the computer. It also contains modules that log keyboard strokes, take screen shots of whatbs occurring on a machine, extract geolocation data from images and turn an infected computer into a Bluetooth beacon to siphon information from Bluetooth-enabled phones that are near the computer. Flame exploited a vulnerability in Microsoftbs terminal service system to allow the attackers to obtain a fraudulent Microsoft digital certificate to sign their code, so that it could masquerade as legitimate Microsoft code and be installed on a target machine via the Microsoft software update function. Flame was developed at least five years ago as part of a classified program code-named Olympic Games, the same program that produced Stuxnet. b It is far more difficult to penetrate a network, learn about it, reside on it forever and extract information from it without being detected than it is to go in and stomp around inside the network causing damage,b said Michael V. Hayden, a former NSA director and CIA director who left office in 2009, told the Post. Itbs still unclear whether the malware used to attack computers in Iranbs oil ministry is the same malware now known as Flame. According to the Post, the attack on the oil ministry computers was directed by Israel alone, a matter which apparently caught US officials off guard, according to anonymous sources who spoke with the newspaper. Kim Zetter Kim Zetter is a senior reporter at Wired covering cybercrime, privacy, security and civil liberties. -- ((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.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 http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [cryptography] attacks against bitcoin
by Adam Back 06 Jul '18

06 Jul '18

I was thinking a DoS might be a problem. If you could prevent the p2p network broadcasting or receiving broadcasts, maybe you could be the only person able to proceed with minting. If you could keep that up for a while you could reduce the difficulty and create bitcoins with lower cost. A full enough DoS maybe difficult to do as the network is p2p. Also maybe if you could temporarily come in with significantly more compute power than the rest of the network - eg rent ec2's entire gpcpu farm for a little while, or use of a huge bot farm, you could undo transactions. If those transactions were you selling bitcoins, you could then sell them again. eg buy, then sell $100k coins (minus the spread/fluctuation), rent $50k worth of compute for a while; sell the $100k of coins again ... profit :) Adam On Sun, Jun 12, 2011 at 12:16:01PM +0200, Eugen Leitl wrote: > > How safe is the bitcoin cryptosystem and the communication network > against targeted attacks? _______________________________________________ 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://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
by Ondrej Mikle 06 Jul '18

06 Jul '18

This thread is amazing. I've known just a fractions/hints of the practices described here. Few comments/questions inline/below. On 12/04/11 07:37, Lucky Green wrote: > Concur. The standard sub-CA contracts contain a right to audit the > number of certs issued, like any enterprise-wide software license > agreement does include a right to audit used seats. Not once in over 30 > years have I seen such an audit performed. There is no reason to audit: > when you buy a sub-CA, the public CA's rep will work out a contract that > gives you the right to use as many certs and more as you conceivably > could use given the application to which you plan to put the sub-CAs. > Keeping count of actual certs issued would only add cost to both the > sub-CA customer and the root CA provider. There is simply no business > case for auditing the number of certs issued. On 12/02/11 11:02, Peter Gutmann wrote: > It's not just a claim, I've seen them too. For example I have a cert issued > for google.com from such a MITM proxy. I was asked by the contributor not to > reveal any details on it because it contains the name and other info on the > intermediate CA that issued it, but it's a cert for google.com used for deep > packet inspection on a MITM proxy. I also have a bunch of certs from private- > label CAs that chain directly up to big-name public CAs, there's no technical > measure I can see in them anywhere that would prevent them from issuing certs > under any name. How do MitM boxes react when they MitM connection to a server with self-signed cert (or cert issued by an obsure CA not trusted by MitM box)? Do the boxes send to client also an auto-generated self-signed cert that generates warning or "re-sign" it so that client sees valid chain? MitM-re-signing an unverifiable chain of server to a chain that's trusted at the MitM-ed client would be hilarious, allowing to MitM a MitM box (though this would be an easily avoidable mistake to make). Given the state of security/auditing of "private sub-CAs" as described, was there ever a report of a breach (e.g. stolen key, fraudulently issued certs)? <blatant_CA_bashing> While chasing data from my scans around, I checked history of few CAs. Most oddly hilarious "trusted" CA is probably SAIC (Science Applications International Corporation). Reason: SAIC led the development of Trailblazer Project for NSA (in my book this tops much-too-obvious CAs of other TLA agencies). Also, Network Solutions, L.L.C (also a CA) was owned by SAIC at some time. Later, Network Solutions did not acquire exactly "good guy" reputation. Don't get me wrong: I'm not claiming either of the mentioned CAs did anything egregious subverting CA-trust placed in them. I have no intention to single them out as "shady", additional search would turn up many more CAs. </blatant_CA_bashing> Hypothetical question: assume enough people get educated how to spot the MitM box at work/airport/hotel. Let's say few of them post the MitM chains publicly which point to a big issuing CA. It was said (by Peter I think) that nothing would likely happen to big issuing CAs (too-big-to-fail). Would the MitM-ing sub-CAs take the fall? (lose license and invested funds) Ondrej _______________________________________________ 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://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [silk] Flame is Lame
by Udhay Shankar N 06 Jul '18

06 Jul '18

On 12/06/12 12-Jun-2012;6:04 PM, Biju Chacko wrote: > http://www.f-secure.com/weblog/archives/00002383.html More on this, for those not following along: http://www.wired.com/threatlevel/2012/06/us-and-israel-behind-flame/ Report: US and Israel Behind Flame Espionage Tool By Kim Zetter June 19, 2012 | The United States and Israel are responsible for developing the sophisticated espionage rootkit known as Flame, according to anonymous Western sources quoted in a news report. The malware was designed to provide intelligence about Iranbs computer networks and spy on Iranian officials through their computers as part of an ongoing cyberwarfare campaign, according to the Washington Post. The program was a joint effort of the National Security Agency, the CIA and Israelbs military, which also produced the Stuxnet worm that is believed to have sabotaged centrifuges used for Iranbs uranium enrichment program in 2009 and 2010. b This is about preparing the battlefield for another type of covert action,b a former high-ranking US intelligence official told the Post. b Cyber collection against the Iranian program is way further down the road than this.b Flame was discovered last month by Russia-based antivirus firm Kaspersky Lab, following reports in Iran that malware aimed at computers belonging to that countrybs oil industry had wiped data from the computers. In trying to investigate that issue, Kaspersky came across components of the Flame malware, which the researcher believed was not directly connected to the malware that wiped the Iranian computers clean but which they believed was created by the same nation states behind Stuxnet. Kaspersky disclosed last week that Flame in fact contained some of the same code as Stuxnet, directly tying the two pieces of malware together. According to the Post Flame was designed to infiltrate highly secure networks in order to siphon intelligence from them, including information that would help the attackers map a target network. Flame, as previously reported, can activate a computerbs internal microphone to record conversations conducted via Skype or in the vicinity of the computer. It also contains modules that log keyboard strokes, take screen shots of whatbs occurring on a machine, extract geolocation data from images and turn an infected computer into a Bluetooth beacon to siphon information from Bluetooth-enabled phones that are near the computer. Flame exploited a vulnerability in Microsoftbs terminal service system to allow the attackers to obtain a fraudulent Microsoft digital certificate to sign their code, so that it could masquerade as legitimate Microsoft code and be installed on a target machine via the Microsoft software update function. Flame was developed at least five years ago as part of a classified program code-named Olympic Games, the same program that produced Stuxnet. b It is far more difficult to penetrate a network, learn about it, reside on it forever and extract information from it without being detected than it is to go in and stomp around inside the network causing damage,b said Michael V. Hayden, a former NSA director and CIA director who left office in 2009, told the Post. Itbs still unclear whether the malware used to attack computers in Iranbs oil ministry is the same malware now known as Flame. According to the Post, the attack on the oil ministry computers was directed by Israel alone, a matter which apparently caught US officials off guard, according to anonymous sources who spoke with the newspaper. Kim Zetter Kim Zetter is a senior reporter at Wired covering cybercrime, privacy, security and civil liberties. -- ((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.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 http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0