From gwen at cypherpunks.to Sat Feb 1 01:16:33 2014 From: gwen at cypherpunks.to (gwen hastings) Date: Sat, 01 Feb 2014 01:16:33 -0800 Subject: our drone future Message-ID: <52ECBB71.10306@cypherpunks.to> for those that have not seen this... http://www.youtube.com/watch?v=CgLkWT246qU -- Tentacle #99 ecc public key curve p25519(pcp 0.15) 1l0$WoM5C8z=yeZG7?$]f^Uu8.g>4rf#t^6mfW9(rr910 Governments are instituted among men, deriving their just powers from the consent of the governed, that whenever any form of government becomes destructive of these ends, it is the right of the people to alter or abolish it, and to institute new government, laying its foundation on such principles, and organizing its powers in such form, as to them shall seem most likely to effect their safety and happiness.’ https://github.com/TLINDEN/pcp.git to get pcp(curve25519 cli) https://github.com/stef/pbp.git (curve 25519 python based cli) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x42AA24D5.asc Type: application/pgp-keys Size: 70878 bytes Desc: not available URL: From segordon at gmx.com Sat Feb 1 06:31:07 2014 From: segordon at gmx.com (Sam Gordon) Date: Sat, 01 Feb 2014 06:31:07 -0800 Subject: our drone future In-Reply-To: <52ECBB71.10306@cypherpunks.to> References: <52ECBB71.10306@cypherpunks.to> Message-ID: <52ED052B.7090309@gmx.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I liked it, but the realistic portions were destroyed by the A.I. 'argument' with the operator. I have a hard time believing that to be the future, especially when in the video itself it shows the A.I. making a poor decision and getting the craft destroyed. I can't imagine a military buying weapons that can routinely overrule their chain of command Now explain to me that the female voice was actually a higher ranking secondary operator, and i'd start to see the benefits. *operator 1 : do not want to sacrifice craft for discovery of enemy* *operator 2 : override previous command, potential enemy discovery of greater priority.* Making a superior officer appear as if they are 'Siri' could possibly reduce confrontation and the feeling of being overruled, and thus increase individual operator happiness, job satisfaction, etc etc. It could also reduce the chances that an operator takes personal responsibility for their actions. "That stupid AI fucked up, not me. I KNEW they were innocent!" I liked it, though. Neat footage. On Sat 01 Feb 2014 01:16:33 AM PST, gwen hastings wrote: > for those that have not seen this... > > > http://www.youtube.com/watch?v=CgLkWT246qU > - -- http://about.me/sam.gordon Keep the net free Electronic Frontier Foundation https://supporters.eff.org/donate Free Software Foundation https://my.fsf.org/associate/support_freedom/join_fsf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS7QUrAAoJEBNrXBfj4zc+UZ4IANNkIBsEOZ/+SloZ/SWeLWhf l4DnWoa1Ooq0KfR0/lt6HtPIQiz+Pq4xi5TQY9P2qTpdGA9rWNog5r8FjGnfGXEv zBmuw7s1DCWnxz5f7FjnmrxQiFXvOzmfx888ov2tam72gYo5WFPKEtbA4qU65V1M UhshdGaMYo9m6b1hXdp0MyxEW1TaJ5h0cg+Be92PXBTd3jCqeCGDdYNL49rEqVot mL0pCNGgMuBrvYMjPZuX46aklYfFmvug+8V/OXKqugPprq1Cds9SaIYp7zJP0Do3 UX1lfZdPfnqXSB/akhE6oTr2QuUUJoVudmpP+9tlBjATgYh+zYesE0MQidUOZzk= =CV4W -----END PGP SIGNATURE----- From grarpamp at gmail.com Sat Feb 1 13:35:41 2014 From: grarpamp at gmail.com (grarpamp) Date: Sat, 1 Feb 2014 16:35:41 -0500 Subject: [Cryptography] The crypto behind the blackphone In-Reply-To: <90C99BDF-BDA5-4D04-9C79-CF5AA2D91629@callas.org> References: <2A1FFA4B-9768-48A7-8838-4AB6729CB8B5@callas.org> <7DFE3277-2ED4-492F-B5DF-F00F01A32B13@callas.org> <90C99BDF-BDA5-4D04-9C79-CF5AA2D91629@callas.org> Message-ID: On Fri, Jan 31, 2014 at 4:13 PM, Jon Callas wrote: >> Note some open phone HW projects are selling hardware >> to which you apply your droid SW rom. Though we're likely >> at least a handful of years away from seeing a genuinely >> 'open design' baseband HW layer in a phone, they are >> talking about approaching it. > > If/when they do, I'd love to see it. I don't have time to make an open, secure baseband, but want to include one. The world needs one. Maybe we can arrange some sort of trade. I would suggest that profit making companies who would in fact benefit greatly from being able to advertise their use of such an open secure baseband when said is developed, and who do not have such interest/capability in house, should wish to donate promote and support external efforts to produce said baseband. Corral and coordinate partnerships therein, etc. From grarpamp at gmail.com Sat Feb 1 13:43:27 2014 From: grarpamp at gmail.com (grarpamp) Date: Sat, 1 Feb 2014 16:43:27 -0500 Subject: [Cryptography] The crypto behind the blackphone In-Reply-To: References: <2A1FFA4B-9768-48A7-8838-4AB6729CB8B5@callas.org> <7DFE3277-2ED4-492F-B5DF-F00F01A32B13@callas.org> <90C99BDF-BDA5-4D04-9C79-CF5AA2D91629@callas.org> Message-ID: > not have such interest/capability in house, should wish to donate > promote and support external efforts to produce said baseband. > Corral and coordinate partnerships therein, etc. And apply industry and legislative pressure/voice from their position as business company to assist in enabling and driving production of said baseband until such time as the initial development producer organisation group of it have sufficient voice. On Sat, Feb 1, 2014 at 4:35 PM, grarpamp wrote: > On Fri, Jan 31, 2014 at 4:13 PM, Jon Callas wrote: >>> Note some open phone HW projects are selling hardware >>> to which you apply your droid SW rom. Though we're likely >>> at least a handful of years away from seeing a genuinely >>> 'open design' baseband HW layer in a phone, they are >>> talking about approaching it. >> >> If/when they do, I'd love to see it. I don't have time to make an open, secure baseband, but want to include one. The world needs one. Maybe we can arrange some sort of trade. > > I would suggest that profit making companies who would in fact > benefit greatly from being able to advertise their use of such > an open secure baseband when said is developed, and who do > not have such interest/capability in house, should wish to donate > promote and support external efforts to produce said baseband. > Corral and coordinate partnerships therein, etc. From grarpamp at gmail.com Sat Feb 1 14:18:48 2014 From: grarpamp at gmail.com (grarpamp) Date: Sat, 1 Feb 2014 17:18:48 -0500 Subject: [p2p-hackers] The next gen P2P secure email solution In-Reply-To: <52EC7A72.5020702@broadley.org> References: <52BD4826.3070309@broadley.org> <52D0D2AF.90509@broadley.org> <08e901cf0fd5$07ebac50$17c304f0$@huitema.net> <52EC7A72.5020702@broadley.org> Message-ID: On Fri, Jan 31, 2014 at 11:39 PM, Bill Broadley wrote: > On 01/30/2014 08:51 PM, grarpamp wrote: >> Other than for latency issues in our protocols, there's enough >> fiber to generally ignore our global traffic impact... torrent, video >> and cloud are dominating that, not messaging anymore. > > Indeed. Even the "3rd world" of home internet connections the USA > (ranked 14th) has an average speed of 7mbit/sec. Any reasonable > multiple of Email/IM traffic is basically zero. Not particularly worth > discussing. > > The hardest part of the problem is the feature set and social aspect of > launching a new messaging network. Clearly it's still happening with > Mxit, WhatsApp, WeChat, Line, Viber, MessageMe, Voxer, etc. > > I think WhisperPush's approach with TextSecure is interesting: > * they partnered with cyanogen to because the default on a substantial > number of phones > * It "just works" with any SMS user, granted no security/encryption > * It "just works" securely with any other TextSecure user > * It also "just works" on IOS, granted a user has to track it down > and install it. Why these 'social launches' work for crappy apps is becuase the windows writers cater to and know the forum using, bling ridden, pop, idiot-sphere. While cpunk writers / good apps such as might be found below have historically shied away from that catering/knowing, there is no reason they cannot engage it, or that they cannot partner with people that do to enable their own social launch. https://prism-break.org/ > As far as I know Cyanogen does not have a secure IM app yet. > >>On Sun, Jan 12, 2014 at 3:29 PM, Christian Huitema >>> I believe this is actually an issue. The number of pings per host scales as >>> O(log N), which means the amount of maintenance traffic scales as O(N log N) >>> -- more than linearly with the size of the network. Given the nature of the >>> DHT, the addresses to be pinged > > So yes, per node bandwidth scales with O(log N). System bandwidth with > O(N log N). But it's so small that it's mostly irrelevant. Sure some > phone users will be power limited or have a very low data cap, in those > cases they should install a raspberry pi at home or share a node with > more resources. > > Don't worry about 2 billion users before you get 2000. I don't agree. If you do not design for say 2bn users upfront (as is the general subject of this thread re: nexgen global p2p solutions) and instead target 200k or less, you will hit major roadblocks that are very difficult to rip out and cure becuase your entire mindset from day one was only scaling to a dreamy 200k. Mindset and failure to think big traps projects like these, and if they somehow capture and grow users they'll get overloaded to the point of unusability. The best case they then embarrasingly have is to take a year basically rewriting from scratch, or they fail and users move on. And once a project hits unusability issues, that is a hard image to shake... fool me once. This is a classic issue in systems history, where better upfront design would have prevented it. The examples are plenty, there's really no excuse anymore. >> I think the question is, can we do what we want to do within >> the bandwidth that our target users have available to them... >> such as say a 56k channel, 128k, 512k, etc. If we're using >> 32 of 56k for maintenance, that may leave little left for the >> signal you want to send through. > > 10M users DHTs work today with minimal bandwidth overhead (kbit/sec) > while maintaining MByte/sec (factor of 8000 different). The huge > majority of node bandwidth goes to actually downloading torrents. > > So basically I don't see any particularly big technical hurdles. Not > that there aren't others. The network effect and social issues being > the big ones. > > ChatSecure looks pretty reasonable. In a perfect world I'd hope for a > client that: > * fully decentralized, only has find the bit-torrent mainline DHT to > be able to find peers. Why not use the existing 10M peers to help > find compatible peers. > * IPv6 capable, clearly the easiest way to directly connect other peers > in the future. Comcast is already over 25% and IPv6 seems to be > gathering steam. > * Simple tit-for-tat bandwidth and storage trading between owners. > Reputation based on direct observation (no 3rd parties). > * support for 2 tiers of peers, those with long connection times > bandwidth and power to burn and those with intermittent connections > and are power/bandwidth limited. > * allowing people to have a home node that trades bandwidth/storage > with peers and then a mobile node with the same crypto identify > that can leverage the home node and any of it's peers. > > Ideally I could have a 2TB disk ($100) at hosting my more important > files (200GB) and earning the good will of it's peers by hosting > encrypted blobs for them. Leave it connected to a raspberry pi/beagle > board black for $40. Then as needed I can use the goodwill of those > peers to record for whatever bandwidth/storage needs I have. > > So basically my node and it's friends could act collectively as my > IM/Mail/File server. The p2p pooled anon secure model is interesting. I think MaidSecure was the most recent thing making the rounds in this area. Maybe FreeNet is also similar. > _______________________________________________ > p2p-hackers mailing list > p2p-hackers at lists.zooko.com > http://lists.zooko.com/mailman/listinfo/p2p-hackers From rysiek at hackerspace.pl Sat Feb 1 09:54:35 2014 From: rysiek at hackerspace.pl (rysiek) Date: Sat, 01 Feb 2014 18:54:35 +0100 Subject: our drone future In-Reply-To: <52ED052B.7090309@gmx.com> References: <52ECBB71.10306@cypherpunks.to> <52ED052B.7090309@gmx.com> Message-ID: <2660995.3NCKEEbaGm@lap> Dnia sobota, 1 lutego 2014 06:31:07 Sam Gordon pisze: > I liked it, but the realistic portions were destroyed by the A.I. > 'argument' with the operator. > > I have a hard time believing that to be the future, especially when in > the video itself it shows the A.I. making a poor decision and getting > the craft destroyed. I can't imagine a military buying weapons that can > routinely overrule their chain of command When you put it like that, sure. When you put it like it's not "overruling the chain of command", but "correcting operator mistakes in accordance with procedures", it's a whole different story! The latter creates the appearance as if a drone would not be be able make any "wrong" decisions, as all it would base its decisions on would be procedures written and implemented by "the right people". What gets hidden in such a scenario is that (obviously): - procedures are bound to have mistakes themselves (oh, the irony of unintended consequences!); - people implementing them will make mistakes. But that will not stop the introduction of such drones, if properly packaged in marketing mumbo-jumbo. Never underestimate the power of new shiny toys for the uniformed (just one letter away from "uninformed", eh?) boys! > Now explain to me that the female voice was actually a higher ranking > secondary operator, and i'd start to see the benefits. > > *operator 1 : do not want to sacrifice craft for discovery of enemy* > *operator 2 : override previous command, potential enemy discovery of > greater priority.* > > Making a superior officer appear as if they are 'Siri' could possibly > reduce confrontation and the feeling of being overruled, and thus > increase individual operator happiness, job satisfaction, etc etc. It > could also reduce the chances that an operator takes personal > responsibility for their actions. > > "That stupid AI fucked up, not me. I KNEW they were innocent!" Consider: http://en.wikipedia.org/wiki/Firing_squad#Blank_cartridge http://en.wikipedia.org/wiki/Diffusion_of_responsibility -- Pozdr rysiek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: From jamesdbell9 at yahoo.com Sat Feb 1 19:12:04 2014 From: jamesdbell9 at yahoo.com (jim bell) Date: Sat, 1 Feb 2014 19:12:04 -0800 (PST) Subject: Jim Bell's Email crash: Why not sue Yahoo AND the NSA? Message-ID: <1391310724.7927.YahooMailNeo@web126202.mail.ne1.yahoo.com> I just received a seeming 'boilerplate' (pre-canned) email from Yahoo email, saying that my previous account  (jamesdbell8 at yahoo.com)  will be deleted.  It does not repeat the previous claim of "abuse" on the account, but the timing of the events strongly suggests that the source of the problem was an attack on probably millions of Yahoo email addresses that has occurred over the last week or so.  Naturally, I am completely outraged that they allowed such an event to result in actual loss of 'all' data in the account.  Could it be that Yahoo's system was truly damaged so seriously as to cause the complete loss of my email and address-list database?     However, I am reminded of the old saying, "If you get lemons, make lemonade".   Because of Edward Snowden's revelations, we have known that the NSA has been storing all domestic, and probably as many foreign, emails as they could get their grubby little hands on.   Why not a class-action lawsuit demanding that Yahoo obtain prior emails from the NSA?      While it is difficult to sue the US (primarily due to something called "Sovereign Immunity"),  I am aware that the Federal government has already waived Sovereign immunity for everything except money damages.  (In other words, you can sue them for 'declaratory' and 'injunctive' relief:  A court could order the NSA to deliver the data back to Yahoo.)        Does anyone out in the Wide World of Cypherpunks know of an attorney wanting to take on this kind of issue?  It could put the NSA in a world of hurt for taking the data, and make them realize that one consequence of taking hold of such a massive amount of data is that they will ultimately be sued if it is necessary to recover.  It would also put email providers such as Yahoo on notice that they have additional obligations (other than those they think they have) to recover lost emails.        Jim Bell -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 2710 bytes Desc: not available URL: From shelley at misanthropia.info Sat Feb 1 20:22:36 2014 From: shelley at misanthropia.info (shelley at misanthropia.info) Date: Sat, 1 Feb 2014 20:22:36 -0800 Subject: Jim Bell's Email crash: Why not sue Yahoo AND the NSA? In-Reply-To: <1391310724.7927.YahooMailNeo@web126202.mail.ne1.yahoo.com> Message-ID: <20140202042241.E90C9C00003@frontend1.nyi.mail.srv.osa> Good point.  This guy's attempt was humorous http://www.theblaze.com/stories/2013/09/01/hilarious-video-shows-man-call-nsa-in-attempt-to-recover-deleted-email/ , but I'd x-post this to libtech because there are several lawyers and EFF staff on that list who might be able to advise on whether there are any suits already pending, and if it's feasible. That's complete bullshit.  We know damn well Yahoo (et al) has backups of backups.  I'd try to fight with them a bit before letting the account go. -Shelley  On Feb 1, 2014 8:03 PM, jim bell <jamesdbell9 at yahoo.com> wrote: I just received a seeming 'boilerplate' (pre-canned) email from Yahoo email, saying that my previous account  (jamesdbell8 at yahoo.com)  will be deleted.  It does not repeat the previous claim of "abuse" on the account, but the timing of the events strongly suggests that the source of the problem was an attack on probably millions of Yahoo email addresses that has occurred over the last week or so.  Naturally, I am completely outraged that they allowed such an event to result in actual loss of 'all' data in the account.  Could it be that Yahoo's system was truly damaged so seriously as to cause the complete loss of my email and address-list database?     However, I am reminded of the old saying, "If you get lemons, make lemonade".   Because of Edward Snowden's revelations, we have known that the NSA has been storing all domestic, and probably as many foreign, emails as they could get their grubby little hands on.   Why not a class-action lawsuit demanding that Yahoo obtain prior emails from the NSA?     While it is difficult to sue the US (primarily due to something called "Sovereign Immunity"),  I am aware that the Federal government has already waived Sovereign immunity for everything except money damages.  (In other words, you can sue them for 'declaratory' and 'injunctive' relief:  A court could order the NSA to deliver the data back to Yahoo.)        Does anyone out in the Wide World of Cypherpunks know of an attorney wanting to take on this kind of issue?  It could put the NSA in a world of hurt for taking the data, and make them realize that one consequence of taking hold of such a massive amount of data is that they will ultimately be sued if it is necessary to recover.  It would also put email providers such as Yahoo on notice that they have additional obligations (other than those they think they have) to recover lost emails.       Jim Bell -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 3747 bytes Desc: not available URL: From jamesdbell9 at yahoo.com Sat Feb 1 22:25:55 2014 From: jamesdbell9 at yahoo.com (jim bell) Date: Sat, 1 Feb 2014 22:25:55 -0800 (PST) Subject: Yet another interesting take on assassination markets. Message-ID: <1391322355.22712.YahooMailNeo@web126201.mail.ne1.yahoo.com> See the article by Tomasz.Wegrzanowski at gmail.com   (Spell that 5 times really fast!) http://t-a-w.blogspot.com/2013/11/if-assassination-markets-were-real.html     I'd praise this guy's take on assassination markets, but since 90% of it is virtually identical to my own from January 1995 (before I'd published Part 1 of AP), that would pretty much be me patting myself on the back.      Even so, there are some things on which we disagree:  For example, TAW (Tomasz Wegrzanowski) says he believes that today's 'assassination markets' are probably scams.  (I know only of Sanjuro's "Assassination Market", and David's DPL, or Digital Prediction Lottery; Technically, DPL doesn't label itself as an 'assassination market', but for purposes of my analysis I will label it one.)  It is hypothetically possible that either or both of these are some government honey-pot, although I don't think so.  I have previously pointed out that I see little reason for any government to, now, promote a system similar to my AP idea, particularly when I wasn't promoting AP itself since my release from the Federal governments' 'gated communities' in March 2012.  Indeed, to do so would have been about as much a mistake as 2003's FutureMAP system.  http://en.wikipedia.org/wiki/Information_Awareness_Office#Futures_Markets_Applied_to_Prediction_.28FutureMAP.29      (And I'm not implying FutureMAP was a bad idea; rather I think that to float the idea as they did led to so much negative reaction that they had to withdraw it, amazingly within one day too!)      But I also don't believe that either system is likely to be a money- (Bitcoin-) seeking scam, either.  The reason is based on Game theory.  Imagine somebody starts up an AP-type operation.  Imagine further that it is acting is what I'd call a 'healthy' fashion, actively collecting at least dozens of hundreds of individual donations per day.   (This would be strongly impeded if the system collected minimum  donations of 1.0 BTC, like Sanjuro's system started out doing , or it was somehow not sufficiently easy to use, or it did not provide the various proofs of operational security sufficient to induce confidence in potential donors.)  I think if it was 'working', such a system would quickly develop hundreds of target-names, albeit some with tiny reward amounts,  and would certainly collect enough donations within, say, three months to raise the bounties to a level sufficient to result in at least one, uh, 'hit'.  Prior to that, many potential donors would still hold back, either because they weren't confident that somebody would be rewarded, or they would wait to see if something 'happened'.      But suppose that one 'hit' occurred.  Suppose the system demonstrated that some unknown-named person had correctly predicted the date of death of the person listed. (This should be unavoidable:  It should not be possible for the system to conceal the existence of a correct donation; in any case, the public and all potential future donors would insist on the exposure of all relevant donations naming that particular target.) Would the operator 'defect' or 'cooperate' (both are terms used in Game Theory.)  Would the operator of that system actually pay the stated  amount, or would he refuse?  (I am assuming that the system was at least set up to have the technical ability to prove, to the public, that the reward had been paid to the correct predictor.)     To me, it is obvious that if the operator indeed pays the reward, and this fact can be proven to the public without revealing the true name of the correct predictor, for every Bitcoin paid out as a reward, this confidence-building measure will result in at least tens, and probably many hundreds of Bitcoins of further donations from other themselves naming other targets.  In other words, at that point it would become totally illogical for the system operator  to 'defect', to refuse to pay a (relatively) small donation, because by doing that he would be foregoing further donations that would be collectively hundreds of times larger.  (Nobody would donate to a system which provably refused to pay on a correction 'prediction', or failed to sufficiently disprove the non-payment of the reward.)        This same analysis would apply after the second 'hit', and the third, and the fourth, etc.  At no point, I think, would the 'assassination market' system operator find it financially more advantageous to refuse to pay the reward, than to pay it and remain in operation and collect far more donations.  He will always be better off by paying the reward.     There is, however, one exception that I can think of to this analysis.  A person (or persons, or a government) might conceivably run an 'AM'-type organization, for a while, specifically for the purpose of discrediting the entire concept of AP.  That person might run the system, for a while, even paying off one, or a dozen or two, predictions, and collect a substantial reward in the process, eventually intending to run away, thereby leading to 'fear, uncertainty, and doubt' over the question of whether a credible 'AP'-type system could exist.  The big problem, for that person, is that by doing so he would be inadvertently demonstrating the proper (for awhile) functioning, and effect of, that system.  Once demonstrated to work, for that period of time, it would become obvious that such a system could, indeed, function 'properly' if the person or people involved are motivated to do so.  And, there would be nothing they could do about stopping credible, reliable people from initiating and running an honest AP-type organization.  Eventually, reputable systems would win out, because they would build up the longevity leading confidence as to their offers.            Jim Bell -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 8516 bytes Desc: not available URL: From jya at pipeline.com Sun Feb 2 04:03:55 2014 From: jya at pipeline.com (John Young) Date: Sun, 02 Feb 2014 07:03:55 -0500 Subject: Alleged NSA-GCHQ Attack on Jean-Jacques Quisquater Message-ID: Any further information on the alleged NSA-GCHQ attack on Jean-Jacques Quisquater than these two reports? http://cryptome.org/2014/02/nsa-gchq-quisquater.pdf Apparently Quisquater would not have known about the attack if not told by an insider. Insider comsec disclosures may be finally getting legs, not yet long, but more than NDA-official secrecy paralysis. Any other cryptographer attacked (as if it would be known)? From rysiek at hackerspace.pl Sun Feb 2 01:23:55 2014 From: rysiek at hackerspace.pl (rysiek) Date: Sun, 02 Feb 2014 10:23:55 +0100 Subject: [p2p-hackers] The next gen P2P secure email solution In-Reply-To: <52D123A5.4050706@cathalgarvey.me> References: <52D123A5.4050706@cathalgarvey.me> Message-ID: <11615442.BbncsVJtn1@lap> Dnia sobota, 11 stycznia 2014 10:57:41 Cathal Garvey pisze: > >>> So sad. I have a clue and don't trust Skype. But I can't for the > > life of > > >>> me migrate my friends off of it. It's as addictive as crack. It's just > >>> better than the alternatives. > >> > >> Anything that is as good as skype is going to allow contact tracing, that > >> this person talks to that person. > > Red herring-ish, but if you want to get your friends off Skype, don't > wait for the golden solution. Pick something good-enough and use that. > I've had moderate success migrating people to Jitsi. Similar ease of use > once set up, and they now allow jit.si account creation within the > application (under the XMPP option). > > Obviously not genuinely P2P. The only semi-viable alternative I can > think of that *is* P2P, but have not yet tried, is VoiP in Retroshare. I have tried it, worked straight off the bat. Behind a NAT. > However, as I suggested in another thread, I'm not convinced Retroshare > is up to the hard-crypto standard some people here might demand. That > is, it'll block virtually everyone, but not the real fascists. Well, it seems "good enough" for Joe Schmoe, and is easy enough to set-up and use (still being much crypto-safer than Jitsi, I guess). -- Pozdr rysiek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: From jamesdbell9 at yahoo.com Sun Feb 2 13:18:12 2014 From: jamesdbell9 at yahoo.com (jim bell) Date: Sun, 2 Feb 2014 13:18:12 -0800 (PST) Subject: My contacts have been deleted [Incident: 140202-009907] In-Reply-To: <1391375145.14004.YahooMailNeo@web126204.mail.ne1.yahoo.com> References: <1391375145.14004.YahooMailNeo@web126204.mail.ne1.yahoo.com> Message-ID: <1391375892.40764.YahooMailNeo@web126205.mail.ne1.yahoo.com> Incidents:   140126-043015   140127-126735  140127-132061   140128-041612  140128-126181   140202-010643   140202-009907 I have discovered this article, showing that Yahoo staff like to play games with customers, trying to dissuade them from re-activating old accounts.  But my issue, today, is far stronger:  I did not allow an account to become 'old' and 'unused':  My account (jamesdbell8 at yahoo.com) was quite literally taken from me, one week ago while I was trying to use it daily, even hourly.  (I am now using a new account, 'jamesdbell9 at yahoo.com', to communicate with you.      Do not try to convince me that you have 'lost' my data.  That's not possible.  No doubt Yahoo has backups of backups of backups.  The data IS, indeed, 'there', somewhere. And if it's not 'there', it's in the NSA where you illegally sent it as it was being generated.  Maybe you don't want to take the time and trouble to access it and restore it to my use, but that merely shows how callous, rude, and malicious your staff really is!  Fix the problem immediately so I am only temporarily damaged, not permanently damaged.             Jim Bell ________________________________ From: jim bell To: Yahoo Customer Care Sent: Sunday, February 2, 2014 1:05 PM Subject: Re: My contacts have been deleted [Incident: 140202-009907] Incidents:   140126-043015   140127-126735  140127-132061   140128-041612  140128-126181   140202-010643 I am talking about restoring both my contacts and my emails in account 'jamesdbell8 at yahoo.com', NOT 'jamesdbell9 at yahoo.com .  I have gotten some (effectively) rude and certainly unhelpful emails from Yahoo staff claiming that my account is supposed to be deleted soon.  I have repeatedly challenged your staff's original assertion that the account was stopped due to 'abuse'.  Due to recent public news reports, it appears that millions of Yahoo email accounts were 'hacked', or at least were attempted to be 'hacked'.   You staff has, negligently and rudely, never acknowledge the existence of this 'hacking' in regard to my own email account. Effectively, you blamed me for something that (maybe) somebody else did.   I believe that your software reacted very badly to whatever malicious attempts were made against my email:  I think your system has effectively deleted my account ONLY due to your own mistakes, not specifically the actions of some 'hackers'.     You need to EXPLAIN what has actually happened, why it had the effect on my email account that it did, apologize, and then immediately restore the account (including all emails and address book entries) to me.  And, you must do so IMMEDIATELY.        Jim Bell ________________________________ From: Yahoo Customer Care To: jamesdbell9 at yahoo.com Sent: Sunday, February 2, 2014 12:31 PM Subject: My contacts have been deleted [Incident: 140202-009907] My contacts have been deleted Recently you requested personal assistance from our on-line support center. Below is a summary of your request and our response.  Subject My contacts have been deleted    Discussion Thread  Response Via Email (Curtis) 02/02/2014 12:31 PM Hello Jim,   Thank you for contacting Yahoo Mail.   I went to restore your contacts, and the only files I could restore from only contained the same contacts you have in your Address Book already. No action was taken.   I tried every option to restore your missing Yahoo Contacts, but unfortunately, I wasn’t able to get them back for you. The good news is that you can keep this from happening again by making the occasional backup copy of your contacts. Here’s how to export them as a CSV file.   Exporting your Yahoo Contacts as a Comma Separated Value (CSV) file   1. Sign in to your Yahoo Contacts page. 2. Select Actions | Export All. 3. Select the Export Now button that corresponds to the application you would like to export to. * If you're not sure, click Yahoo CSV. This file type can be easily imported into Yahoo Contacts.     All of your Yahoo Contacts are now saved in a CSV file on your computer, which is readable by Yahoo Contacts and programs like Microsoft Excel.   * To make it easier to find this CSV file in the future, we recommend moving it to a folder on your computer that you'll remember, or writing down its location. * You can make changes to the data in the file if you wish, as long as you don't change the field names in the first row of the file (changing these field names will make the file unreadable by Yahoo Contacts).   Need help with something else?   * Learn how to request restoration of email or instant messages. * If you have any other concerns that you need to contact Yahoo for, please submit another inquiry through our Yahoo Contacts help form. Thank you again for contacting Yahoo Mail.   Regards, Curtis Yahoo Customer Care  Auto-Response 02/02/2014 03:18 AM This is an automated message acknowledging your recent submission for help to Yahoo Customer Care.   Please do not reply to this automated message as replies will not been seen or answered by a Yahoo Customer Care representative.   • If you reported abuse, we will investigate and take action where appropriate, and may be contacted if additional information is required to complete our investigation. We appreciate your efforts to make our community better.   • If you are submitting a request for assistance, or asking a question, a representative will respond as soon as possible.   Your Incident ID is: 140202-009907   Sincerely, The Yahoo Customer Care Team     We will assume your issue has been resolved if we do not hear from you within 72 hours. Thank you for allowing us to be of service to you. [---001:002237:33423---] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 15472 bytes Desc: not available URL: From carimachet at gmail.com Sun Feb 2 17:58:32 2014 From: carimachet at gmail.com (Cari Machet) Date: Mon, 3 Feb 2014 01:58:32 +0000 Subject: My contacts have been deleted [Incident: 140202-009907] In-Reply-To: <1391375892.40764.YahooMailNeo@web126205.mail.ne1.yahoo.com> References: <1391375145.14004.YahooMailNeo@web126204.mail.ne1.yahoo.com> <1391375892.40764.YahooMailNeo@web126205.mail.ne1.yahoo.com> Message-ID: incredibly bizarre keep me posted about how it goes ... crazytown On 2/2/14, jim bell wrote: > > Incidents: 140126-043015 140127-126735 140127-132061 140128-041612 > 140128-126181 140202-010643 140202-009907 > > > I have discovered this article, showing that Yahoo staff like to play games > with customers, trying to dissuade them from re-activating old accounts. > But my issue, today, is far stronger: I did not allow an account to become > 'old' and 'unused': My account (jamesdbell8 at yahoo.com) was quite literally > taken from me, one week ago while I was trying to use it daily, even > hourly. (I am now using a new account, 'jamesdbell9 at yahoo.com', to > communicate with you. > > Do not try to convince me that you have 'lost' my data. That's not > possible. No doubt Yahoo has backups of backups of backups. The data IS, > indeed, 'there', somewhere. And if it's not 'there', it's in the NSA where > you illegally sent it as it was being generated. Maybe you don't want to > take the time and trouble to access it and restore it to my use, but that > merely shows how callous, rude, and malicious your staff really is! Fix the > problem immediately so I am only temporarily damaged, not permanently > damaged. > Jim Bell > > > > > ________________________________ > From: jim bell > To: Yahoo Customer Care > Sent: Sunday, February 2, 2014 1:05 PM > Subject: Re: My contacts have been deleted [Incident: 140202-009907] > > > > Incidents: 140126-043015 140127-126735 140127-132061 140128-041612 > 140128-126181 140202-010643 > > I am talking about restoring both my contacts and my emails in account > 'jamesdbell8 at yahoo.com', NOT 'jamesdbell9 at yahoo.com . I have gotten some > (effectively) rude and certainly unhelpful emails from Yahoo staff claiming > that my account is supposed to be deleted soon. I have repeatedly > challenged your staff's original assertion that the account was stopped due > to 'abuse'. Due to recent public news reports, it appears that millions of > Yahoo email accounts were 'hacked', or at least were attempted to be > 'hacked'. You staff has, negligently and rudely, never acknowledge the > existence of this 'hacking' in regard to my own email account. > Effectively, you blamed me for something that (maybe) somebody else did. > I believe that your software reacted very badly to whatever malicious > attempts were made against my email: I think your system has effectively > deleted my account ONLY due to your own mistakes, not specifically the > actions of some 'hackers'. > You need to EXPLAIN what has actually happened, why it had the effect on > my email account that it did, apologize, and then immediately restore the > account (including all emails and address book entries) to me. And, you > must do so IMMEDIATELY. > Jim Bell > > > > > ________________________________ > From: Yahoo Customer Care > To: jamesdbell9 at yahoo.com > Sent: Sunday, February 2, 2014 12:31 PM > Subject: My contacts have been deleted [Incident: 140202-009907] > > > My contacts have been deleted > > > > Recently you requested personal assistance from our on-line support center. > Below is a summary of your request and our response. > > > > Subject > My contacts have been deleted > > Discussion Thread > Response Via Email (Curtis) 02/02/2014 12:31 PM > Hello Jim, > > Thank you for contacting Yahoo Mail. > > I went to restore your contacts, and the only files I could restore from > only contained the same contacts you have in your Address Book already. No > action was taken. > > I tried every option to restore your missing Yahoo Contacts, but > unfortunately, I wasn't able to get them back for you. The good news is that > you can keep this from happening again by making the occasional backup copy > of your contacts. Here's how to export them as a CSV file. > > Exporting your Yahoo Contacts as a Comma Separated Value (CSV) file > > 1. Sign in to your Yahoo Contacts page. > 2. Select Actions | Export All. > 3. Select the Export Now button that corresponds to the application you > would like to export to. > * If you're not sure, click Yahoo CSV. This file type can be easily > imported into Yahoo Contacts. > > > All of your Yahoo Contacts are now saved in a CSV file on your computer, > which is readable by Yahoo Contacts and programs like Microsoft Excel. > > * To make it easier to find this CSV file in the future, we recommend > moving it to a folder on your computer that you'll remember, or writing down > its location. > * You can make changes to the data in the file if you wish, as long as you > don't change the field names in the first row of the file (changing these > field names will make the file unreadable by Yahoo Contacts). > > Need help with something else? > > * Learn how to request restoration of email or instant messages. > * If you have any other concerns that you need to contact Yahoo for, please > submit another inquiry through our Yahoo Contacts help form. > Thank you again for contacting Yahoo Mail. > > Regards, > Curtis > Yahoo Customer Care > Auto-Response 02/02/2014 03:18 AM > This is an automated message acknowledging your recent submission for help > to Yahoo Customer Care. > > Please do not reply to this automated message as replies will not been seen > or answered by a Yahoo Customer Care representative. > > * If you reported abuse, we will investigate and take action where > appropriate, and may be contacted if additional information is required to > complete our investigation. We appreciate your efforts to make our community > better. > > * If you are submitting a > request for assistance, or asking a question, a representative will respond > as soon as possible. > > Your Incident ID is: 140202-009907 > > Sincerely, > The Yahoo Customer Care Team > > > > > We will assume your issue has been resolved if we do not hear from you > within 72 hours. > > Thank you for allowing us to be of service to you. > > [---001:002237:33423---] -- Cari Machet NYC 646-436-7795 carimachet at gmail.com AIM carismachet Syria +963-099 277 3243 Amman +962 077 636 9407 Berlin +49 152 11779219 Twitter: @carimachet Ruh-roh, this is now necessary: This email is intended only for the addressee(s) and may contain confidential information. If you are not the intended recipient, you are hereby notified that any use of this information, dissemination, distribution, or copying of this email without permission is strictly prohibited. From savagejen at gmail.com Mon Feb 3 07:46:13 2014 From: savagejen at gmail.com (Jen Savage) Date: Mon, 3 Feb 2014 10:46:13 -0500 Subject: Inferring the NSA's MO from a short clip of Joel Brenner on BBC Message-ID: I want to preface this message with a disclaimer: I am in no way defending the actions of the NSA. I am merely attempting analysis of their motivations and their MO. https://www.youtube.com/watch?v=H33r2weM6Zc Joel Brenner says, "There is in all the intelligence agencies a tension between doing offense better and doing defense better" ...and, "but unless you think 0days are finite" Ok let's talk about this issue for a moment. - In the CTF world, it has been widely accepted that given a red team and a blue team of equal abilities, the red team always wins. - Academics say there is no way to create provably secure software. - Developers have a phrase, "there is no such thing as bug free software." - CISOs are using the term "risk" to describe pen test findings: a recognition that pen tests have become a measure of the risk that someone will find an exploitable flaw. Suppose that the NSA gave up on securing software because they view it as impossible. In fact, we know they view it as impossible because they have called it a Sisyphean Task. If there are diminishing returns from reporting software vulnerabilities to the vendor, then doing so is a losing battle. I hear people say that the NSA undermines the security of software by not releasing the vulnerabilities, but we know that historically companies have been very bad at actually fixing the vulnerabilities they are given. In some cases, a new product is released before a vulnerability is even looked into, thus rendering the effort useless. So, is defense dead? Is that an accepted fact these days? If offense is a type of defense, is the NSA perhaps aiming to use 0day for their offensive capabilities to effect a kind of defense? How would they accomplish this? Have any of you been to the Berlin Unterwelten? It is a tour of revision after revision of nuclear bomb shelters that could never possibly save the population they are tasked with saving. We are living in an age where there is an entire set of strategies that deal with war in a world with weapons so strong that no walls can possibly defend against them. Although the reach of nuclear weapons historically has been further reaching than so-called "cyber" weapons, that is changing. Despite the very many warnings from the infosec industry, that is changing. (Sometimes I think my Home Invasion 2.0 talk fell on deaf ears because smart home appliances are proliferating.) And in the future of smart homes, smart cities, even smart bodies, when everything is internet connected: everyone is vulnerable. Imagine cities that can be invaded without physical armies. If you were the NSA, and you believed these things to be true, what would you be doing? -Jen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 3179 bytes Desc: not available URL: From rich at openwatch.net Tue Feb 4 12:04:46 2014 From: rich at openwatch.net (Rich Jones) Date: Tue, 4 Feb 2014 12:04:46 -0800 Subject: Taint Review Team Message-ID: Docs via MuckRock show internal DEA training manuals instructing for parallel construction based on classified / illegally obtained information, combined with an internal review board to shield that information from the public courts. https://www.muckrock.com/news/archives/2014/feb/03/dea-parallel-construction-guides/ "Americans don't like it!" R -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 534 bytes Desc: not available URL: From jamesdbell9 at yahoo.com Tue Feb 4 14:26:17 2014 From: jamesdbell9 at yahoo.com (jim bell) Date: Tue, 4 Feb 2014 14:26:17 -0800 (PST) Subject: Taint Review Team In-Reply-To: References: Message-ID: <1391552777.89859.YahooMailNeo@web126204.mail.ne1.yahoo.com> From: Rich Jones >Docs via MuckRock show internal DEA training manuals instructing for parallel construction based on classified / illegally obtained information, >combined with an internal review board to shield that information from the public courts. >https://www.muckrock.com/news/archives/2014/feb/03/dea-parallel-construction-guides/ >"Americans don't like it!" It appears that these agencies are trying to teach their staff a way to commit a crime, let's call it "obstruction of justice".  In any criminal prosecution, the defense is entitled to receive various kinds of information, see 'Brady material',http://en.wikipedia.org/wiki/Brady_v._Maryland   .   My understanding is that the government is required to disclose to the defendant (and his attorney) any potentially exculpatory information.  This could include the method and manner the government obtained the evidence in question.  Similar is 'Jencks material',  http://en.wikipedia.org/wiki/Jencks_v._United_States  , and 'Giglio material', http://en.wikipedia.org/wiki/Giglio_v._United_States     The purpose of obstructing access to the source of the information is to prevent the defense from identifying and questioning the validity of the information, and to prevent the defense from impeaching witnesses who may otherwise want to remain anonymous.       The prosecution may want to hide behind their putative ignorance of the information, because it is in the hands of some government agency, but I believe that the prosecution is required to investigate and determine such contacts even if they weren't initially aware of them.  The problem is that the prosecution doesn't actually do that, in many cases.  If the defense learns of the possible true source of that information, they can demand that the material be provided, but if they don't get a relevant disclosure, they might not even know what to ask.         Jim Bell    -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 2865 bytes Desc: not available URL: From tom at vondein.org Tue Feb 4 07:07:29 2014 From: tom at vondein.org (Thomas von Dein) Date: Tue, 4 Feb 2014 16:07:29 +0100 Subject: consistent pcp/pbp formats (was: Curve p25519 Replacements for GnuPG?(x2 now) ..) In-Reply-To: References: <20140114111653.GD3900@r4> <20140115093443.GE3900@r4> <20140115134145.GF3900@r4> <20140120133104.GL3900@r4> Message-ID: <20140204150729.GB62910@r4> Hi, a short update about the progress. I've made the following changes to pcp[1] so far: - asymmetrically and symmetrically encrypted files are now created in the same format as pbp does (binary output only). Verified to work with symmetric mode only because of some open issues. - the same applies for signatures, binary only as well. pcp has another format for armored sigs (which I like better). - crypt+sign is supported now as well (pcp only). - pcp can import and export pbp public keys. - encryption keys are derived using scrypt(). - crypto and signing keypairs are generated separately. The todo list contains a bunch of open issues anyway: - we still need a consistent pubkey file format. - we also need an agreement on armoring (base85 va z85). - cipher mode: currently pbp (and pcp now) encrypts data in ECB mode with a blocksize of 32k. I think CBC would be better, and I already implemented it (enabled with ./configure --enable-cbc). We'd need an agreement here as well. best regards, Tom [1] https://github.com/TLINDEN/pcp -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From rysiek at hackerspace.pl Tue Feb 4 10:01:02 2014 From: rysiek at hackerspace.pl (rysiek) Date: Tue, 04 Feb 2014 19:01:02 +0100 Subject: consistent pcp/pbp formats (was: Curve p25519 Replacements for GnuPG?(x2 now) ..) In-Reply-To: <20140204150729.GB62910@r4> References: <20140114111653.GD3900@r4> <20140204150729.GB62910@r4> Message-ID: <17617059.6hh2fKKd5O@lap> Dnia wtorek, 4 lutego 2014 16:07:29 Thomas von Dein pisze: > Hi, > > a short update about the progress. I've made the following changes to > pcp[1] so far: > (...) Thanks for the update, much appreciated! -- Pozdr rysiek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: From yumkam at gmail.com Tue Feb 4 13:03:00 2014 From: yumkam at gmail.com (Yuriy Kaminskiy) Date: Wed, 05 Feb 2014 01:03:00 +0400 Subject: consistent pcp/pbp formats In-Reply-To: <20140204150729.GB62910@r4> References: <20140114111653.GD3900@r4> <20140115093443.GE3900@r4> <20140115134145.GF3900@r4> <20140120133104.GL3900@r4> <20140204150729.GB62910@r4> Message-ID: Thomas von Dein wrote: > a short update about the progress. I've made the following changes to > pcp[1] so far: > > - asymmetrically and symmetrically encrypted files are now created in > the same format as pbp does (binary output only). Verified to work > with symmetric mode only because of some open issues. > > - the same applies for signatures, binary only as well. pcp has another > format for armored sigs (which I like better). > > - crypt+sign is supported now as well (pcp only). Hmm... so, it sign plaintext, but transmit signature unencrypted. If attacker knows/expect content of message, he can discover (and prove) message authorship. This is not most likely scenario, but still totally not good. Signature should be encrypted too. And, same with pgp & co, it is vulnerable to "Surreptitious Forwarding" [1]: Alice sends to Bob "I love you", Bob decrypt message, re-encrypt it to Charlie, keeping Alice signature intact. To avoid this problem, you can include "len(recipients list)|recipients list" in signed material (thus, any attempt to alter recipient list will automagically invalidate signature) [XXX: not exactly usual, requires review]. [1] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html#tth_sEc1.1 When you invent new protocol, it is very good idea too look at *existing standards first*. And then learn from known mistakes in them :-) > - pcp can import and export pbp public keys. > > - encryption keys are derived using scrypt(). > > - crypto and signing keypairs are generated separately. > > > The todo list contains a bunch of open issues anyway: > > - we still need a consistent pubkey file format. > > - we also need an agreement on armoring (base85 va z85). > > - cipher mode: currently pbp (and pcp now) encrypts data in ECB mode > with a blocksize of 32k. I think CBC would be better, and I already ????????????????????????????? What ???????????????????????????????? With ECB, if you encrypt same block with same key, you have same ciphertext. Attacker can identify repetitive content, identify blocks that are same with blocks of known plaintext, etc. All that, obviously, bad. With pbp encryption scheme, each 32kb block is encrypted with stream cipher with *explicit random nonce*. Unlike ECB, if you encrypt same blocks on same key, you'll have *different* ciphertext (as they used different nonces). None of above ECB problems apply. > implemented it (enabled with ./configure --enable-cbc). We'd need an > agreement here as well. > [1] https://github.com/TLINDEN/pcp From hettinga at gmail.com Wed Feb 5 02:24:23 2014 From: hettinga at gmail.com (Robert Hettinga) Date: Wed, 5 Feb 2014 06:24:23 -0400 Subject: Fwd: [Cryptography] (MIT) TALK: Thursday 02-06-2014 Thursday 02-06-14 NSA Surveillance and What To Do About It References: Message-ID: <05BF1E60-443D-4DDB-A8C1-129E89A4F6A3@gmail.com> Pass it along, if you know someone local who should be there. Cheers, RAH Begin forwarded message: > From: Peter Trei > Subject: [Cryptography] (MIT) TALK: Thursday 02-06-2014 Thursday 02-06-14 NSA Surveillance and What To Do About It > Date: February 4, 2014 at 7:54:47 PM AST > To: cryptography at metzdowd.com > > I know this is late notice, but some here may be interested. > > > > Subject: TALK: Thursday 02-06-2014 Thursday 02-06-14 NSA Surveillance and What To Do About It > > NSA Surveillance and What To Do About It > Speaker: Bruce Schneier > > Host: MIT Big Data Initiative at CSAIL > Host Affiliation: MIT CSAIL > > Date: Thursday, February 06, 2014 > Time: 5:00 PM to 6:00 PM > Refreshments Time: 4:45 PM > Location: 32-123 > > ABSTRACT: > Edward Snowden has given us an unprecedented window into the NSA's surveillance activities. Drawing from both the Snowden documents and revelations from previous whistleblowers, this talk describes the sorts of surveillance the NSA conducts and how it conducts it. The emphasis will be on the technical capabilities of the NSA, and not the politics or legality of their actions. I will then discuss what sorts of countermeasures are likely to frustrate any nation-state adversary with these sorts of capabilities. These will be techniques to raise the cost of wholesale surveillance in favor of targeted surveillance: ubiquitous encryption, target dispersal, anonymity tools, and so on. > > [I cut out Bruce's bio - no one here needs it - pt] > > Relevant URL: http://bigdata.csail.mit.edu/ For more information please contact: Susana Kevorkova, 617-324-8424, skevorkova at csail.mit.edu > _______________________________________________ > The cryptography mailing list > cryptography at metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 4051 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From tom at vondein.org Tue Feb 4 23:34:20 2014 From: tom at vondein.org (Thomas von Dein) Date: Wed, 5 Feb 2014 08:34:20 +0100 Subject: consistent pcp/pbp formats In-Reply-To: References: <20140114111653.GD3900@r4> <20140115093443.GE3900@r4> <20140115134145.GF3900@r4> <20140120133104.GL3900@r4> <20140204150729.GB62910@r4> Message-ID: <20140205073420.GD62910@r4> On Wed, Feb 05, 2014 at 01:03:00AM +0400, Yuriy Kaminskiy wrote: > If attacker knows/expect content of message, he can discover (and prove) message > authorship. > This is not most likely scenario, but still totally not good. Signature should > be encrypted too. Well, I can change that, no problem. > With pbp encryption scheme, each 32kb block is encrypted with stream cipher with > *explicit random nonce*. Unlike ECB, if you encrypt same blocks on same key, > you'll have *different* ciphertext (as they used different nonces). None of > above ECB problems apply. Which is the very same I do in pcp. It was just a question, i.e. "may cbc provide even more security than ecb+nonces?" - Tom -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From griffin at cryptolab.net Wed Feb 5 06:42:24 2014 From: griffin at cryptolab.net (Griffin Boyce) Date: Wed, 05 Feb 2014 09:42:24 -0500 Subject: FB's Conceal secure-storage API Message-ID: <52F24DD0.5050408@cryptolab.net> Bullshit or not? It has some interesting elements to it, and would be a step in the right direction for more-secure app content storage. Though at its base, it has some conceptual flaws. If you root the device, you can get the private key. By design, there's no way to put the key on external media (there's only one external microSD slot, and that contains your encrypted files). Files could be cached once decrypted. And of course it doesn't prevent a Finfisher-style screenshot-taking backdoor from just viewing what's displayed on the screen. That's not going into the quality of encryption (which remains to be seen). Conceal uses a stripped-down version of OpenSSL for its encryption algorithms. Still, could be fun. =) ~Griffin https://code.facebook.com/posts/1419122541659395/introducing-conceal-efficient-storage-encryption-for-android/ "Caching and storage are tricky problems for mobile developers because they directly impact performance and data usage on a mobile device. Caching helps developers speed up their apps and reduce network costs for the device owner by storing information directly on the phone for later access. However, internal storage capacity on Android phones is often limited, especially with lower to mid range phone models. A common solution for Android is to store some data on an expandable SD card to mitigate the storage cost. What many people don't realize is that Android's privacy model treats the SD card storage as a publicly accessible directory. This allows data to be read by any app (with the right permissions). Thus, external storage is normally not a good place to store private information. We saw an opportunity to do things better and decided to encrypt the private data that we stored on the SD card so that it would not be accessible to other apps. To do this efficiently, we built Conceal, a set of Java APIs to perform cryptography on Android and make storage more secure and lightweight. We created Conceal to be small and faster than existing Java crypto libraries on Android while using memory responsibly." From tom at vondein.org Wed Feb 5 04:51:10 2014 From: tom at vondein.org (Thomas von Dein) Date: Wed, 5 Feb 2014 13:51:10 +0100 Subject: consistent pcp/pbp formats In-Reply-To: References: <20140114111653.GD3900@r4> <20140115093443.GE3900@r4> <20140115134145.GF3900@r4> <20140120133104.GL3900@r4> <20140204150729.GB62910@r4> Message-ID: <20140205125110.GE62910@r4> On Wed, Feb 05, 2014 at 01:03:00AM +0400, Yuriy Kaminskiy wrote: > And, same with pgp & co, it is vulnerable to "Surreptitious Forwarding" [1]: > Alice sends to Bob "I love you", Bob decrypt message, re-encrypt it to Charlie, > keeping Alice signature intact. To avoid this problem, you can include > "len(recipients list)|recipients list" in signed material (thus, any attempt to > alter recipient list will automagically invalidate signature) [XXX: not exactly > usual, requires review]. Good, I changed the scheme then. However, instead of adding the recipient list to the signature, I add it to the hash, since I sign the hash only anyway; and because it is a) easier to code and b) results in a signature with a static size. So, now the signature looks like this: nonce|crypto_secret_box( crypto_sign( crypto_generichash(cleartext + encrypted-recipientlist) ), nonce, symkey) Everything else is unchanged. So, an encrypted+signed file contains the number of recipients, the recipient-list (which consists of the pk-encrypted ephemeral key per user), the 32k-blockwise sym-encrypted message, followed by the encrypted signature. As usual the nonce used to encrypt the sig is prepended. - Tom -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From rich at openwatch.net Thu Feb 6 10:08:22 2014 From: rich at openwatch.net (Rich Jones) Date: Thu, 6 Feb 2014 10:08:22 -0800 Subject: Taint Review Team In-Reply-To: <9183C6C0-F0D5-41EB-9E70-730100B2E99A@mac.com> References: <9183C6C0-F0D5-41EB-9E70-730100B2E99A@mac.com> Message-ID: Yeah, it does have to do directly with traffic stops. Check out p180 of the PDF (279 is the number in the document). They even put "traffic stop" in quotes. [image: Inline image 1] And I'm guessing that the B7E redacted word is "bullshit." Essentially, they have constructed an intelligence laundering system. DEA agent asks the spooksfor intel on an operation, spook uses illegal surveillance to find out intel, spook tells a paid informant, informant anonymously tells DEA agent, DEA agents get local law enforcement to make a "traffic" stop to create a parallel construction, then in the court case none of the original intelligence is used. All perfectly "legal." Since the prosecution is legally required to hand over any information is has which might exonerate a defendant, such as evidence harvested from the "poisonous tree," the Taint Review Board is used as an intermediary to make sure that nobody on the prosecution has any idea where the poison came from. There are a bunch of other gems in here too. p324: True or False, Is racial profiling okay? Answer: [[ Redacted. b(7)(E) ]] R On Thu, Feb 6, 2014 at 8:29 AM, MARK GORE wrote: > "Any agency that is above the law [such as CIA] can get away with > anything. It's sad, and most people don't know it, or care, but it's true," > the source says. "When they invoke national security, everyone just craps > their pants, even judges." > > Above is from Narco News, check it Rich, Narco news follows all the crap > the DEA does, now my question is can we vector the muckrock training mans' > to another leak maybe located in cryptome- > in order to obtain the code name for HOW the spooks tip-off LEA's to get > into court only to reverse engineer (parallel construct) evidence to cover > source methods. > Its something to do w/ traffic stops? _Mg > > mag_foto / blacksetstudio.com > > > On Feb 4, 2014, at 3:04 PM, Rich Jones wrote: > > Docs via MuckRock show internal DEA training manuals instructing for > parallel construction based on classified / illegally obtained information, > combined with an internal review board to shield that information from the > public courts. > > > https://www.muckrock.com/news/archives/2014/feb/03/dea-parallel-construction-guides/ > > "Americans don't like it!" > > R > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 4177 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-02-06 at 9.49.42 AM.png Type: image/png Size: 26969 bytes Desc: not available URL: From jya at pipeline.com Thu Feb 6 07:34:44 2014 From: jya at pipeline.com (John Young) Date: Thu, 06 Feb 2014 10:34:44 -0500 Subject: Penetration of Target's HVAC Controls Message-ID: Good to see the report on Target's penetration through its remote heating and cooling controls. These and a slew of other building automation systems are often run on central computers along with data processing. Data processing may be protected but the other systems often are not, for IT sec tends to focus on the data of businesses housed in a structure but not the systems running or monitoring the structure with its operating systems most often overseen by maintenance and operation staff seldom skilled in cybersec. We have seen quite a few buildings with decent data protection and building physical and electronic security systems, but lacking oversight of the security of building automation systems often remote from the facilities with 24x7 access, and from there who knows where else -- central automation firms may link up to hundreds of other buildings in a batch of countries. Critical infrastructure protection seldom covers the great variety of buildings. Some use the same Internet connection, separated only by software and folders, with folders of the automation system in obscure locations seldom seen by principal IT data admins. Different duties, contracts, staff, budgets. Much interest in data security, hardly any for automation security. This is not the case for experienced designers, constructors and operators of buildings. Although compartmentalization among them continues to erect easy to penetrate "firewalls" and gaps of responsibility. Spies very much like the porosity and attention to data protection. From jya at pipeline.com Thu Feb 6 07:45:49 2014 From: jya at pipeline.com (John Young) Date: Thu, 06 Feb 2014 10:45:49 -0500 Subject: Penetration of Target's HVAC Controls In-Reply-To: References: Message-ID: Building data security from 1995: http://cryptome.org/datasec.htm Much changed since then. From sdw at lig.net Thu Feb 6 11:08:23 2014 From: sdw at lig.net (Stephen D. Williams) Date: Thu, 06 Feb 2014 11:08:23 -0800 Subject: Taint Review Team In-Reply-To: References: <9183C6C0-F0D5-41EB-9E70-730100B2E99A@mac.com> Message-ID: <52F3DDA7.1000203@lig.net> "(b)(7)(E)" seems like a cite to a section of a document or regulation, not a retraction: Section b, subsection 7, paragraph E. It is a relative cite URI, with base URI (document ID) implied here. Stephen On 2/6/14, 10:08 AM, Rich Jones wrote: > Yeah, it does have to do directly with traffic stops. Check out p180 of the PDF (279 is the number in the document). They even put > "traffic stop" in quotes. > > Inline image 1 > And I'm guessing that the B7E redacted word is "bullshit." > > Essentially, they have constructed an intelligence laundering system. DEA agent asks the spooks > for intel on an operation, spook uses illegal > surveillance to find out intel, spook tells a paid informant, informant anonymously tells DEA agent, DEA agents get local law > enforcement to make a "traffic" stop to create a parallel construction, then in the court case none of the original intelligence > is used. All perfectly "legal." Since the prosecution is legally required to hand over any information is has which might > exonerate a defendant, such as evidence harvested from the "poisonous tree," the Taint Review Board is used as an intermediary to > make sure that nobody on the prosecution has any idea where the poison came from. > > There are a bunch of other gems in here too. p324: True or False, Is racial profiling okay? Answer: [[ Redacted. b(7)(E) ]] > > R > > > On Thu, Feb 6, 2014 at 8:29 AM, MARK GORE > wrote: > > "Any agency that is above the law [such as CIA] can get away with anything. It's sad, and most people don't know it, or care, > but it's true," the source says. "When they invoke national security, everyone just craps their pants, even judges." > > > Above is from Narco News, check it Rich, Narco news follows all the crap the DEA does, now my question is can we vector the > muckrock training mans' to another leak maybe located in cryptome- > in order to obtain the code name for HOW the spooks tip-off LEA's to get into court only to reverse engineer (parallel > construct) evidence to cover source methods. > Its something to do w/ traffic stops? _Mg > > mag_foto / blacksetstudio.com > > > On Feb 4, 2014, at 3:04 PM, Rich Jones > wrote: > >> Docs via MuckRock show internal DEA training manuals instructing for parallel construction based on classified / illegally >> obtained information, combined with an internal review board to shield that information from the public courts. >> >> https://www.muckrock.com/news/archives/2014/feb/03/dea-parallel-construction-guides/ >> >> "Americans don't like it!" >> >> R > -- Stephen D. Williams sdw at lig.net stephendwilliams at gmail.com LinkedIn: http://sdw.st/in V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407 AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 7587 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 26969 bytes Desc: not available URL: From rich at openwatch.net Thu Feb 6 11:12:50 2014 From: rich at openwatch.net (Rich Jones) Date: Thu, 6 Feb 2014 11:12:50 -0800 Subject: Taint Review Team In-Reply-To: <52F3DDA7.1000203@lig.net> References: <9183C6C0-F0D5-41EB-9E70-730100B2E99A@mac.com> <52F3DDA7.1000203@lig.net> Message-ID: It's a reference to the FOIA law itself. 7E is the exemption saying they don't have to talk about police tactics, basically, and that's why that information was redacted. Exemption 7(E) affords protection to all law enforcement information that "would disclose techniques and procedures for law enforcement investigations or prosecutions, or would disclose guidelines for law enforcement investigations or prosecutions if such disclosure could reasonably be expected to risk circumvention of the law." http://www.justice.gov/oip/exemption7e.htm R On Thu, Feb 6, 2014 at 11:08 AM, Stephen D. Williams wrote: > "(b)(7)(E)" seems like a cite to a section of a document or regulation, > not a retraction: Section b, subsection 7, paragraph E. It is a relative > cite URI, with base URI (document ID) implied here. > > Stephen > > > On 2/6/14, 10:08 AM, Rich Jones wrote: > > Yeah, it does have to do directly with traffic stops. Check out p180 of > the PDF (279 is the number in the document). They even put "traffic stop" > in quotes. > > [image: Inline image 1] > And I'm guessing that the B7E redacted word > is "bullshit." > > Essentially, they have constructed an intelligence laundering system. DEA > agent asks the spooksfor intel on an operation, spook uses illegal surveillance to find out > intel, spook tells a paid informant, informant anonymously tells DEA agent, > DEA agents get local law enforcement to make a "traffic" stop to create a > parallel construction, then in the court case none of the original > intelligence is used. All perfectly "legal." Since the prosecution is > legally required to hand over any information is has which might exonerate > a defendant, such as evidence harvested from the "poisonous tree," the > Taint Review Board is used as an intermediary to make sure that nobody on > the prosecution has any idea where the poison came from. > > There are a bunch of other gems in here too. p324: True or False, Is > racial profiling okay? Answer: [[ Redacted. b(7)(E) ]] > > R > > > On Thu, Feb 6, 2014 at 8:29 AM, MARK GORE wrote: > >> "Any agency that is above the law [such as CIA] can get away with >> anything. It's sad, and most people don't know it, or care, but it's true," >> the source says. "When they invoke national security, everyone just craps >> their pants, even judges." >> >> Above is from Narco News, check it Rich, Narco news follows all the >> crap the DEA does, now my question is can we vector the muckrock training >> mans' to another leak maybe located in cryptome- >> in order to obtain the code name for HOW the spooks tip-off LEA's to get >> into court only to reverse engineer (parallel construct) evidence to cover >> source methods. >> Its something to do w/ traffic stops? _Mg >> >> mag_foto / blacksetstudio.com >> >> >> On Feb 4, 2014, at 3:04 PM, Rich Jones wrote: >> >> Docs via MuckRock show internal DEA training manuals instructing for >> parallel construction based on classified / illegally obtained information, >> combined with an internal review board to shield that information from the >> public courts. >> >> >> https://www.muckrock.com/news/archives/2014/feb/03/dea-parallel-construction-guides/ >> >> "Americans don't like it!" >> >> R >> >> > > -- > Stephen D. Williams sdw at lig.net stephendwilliams at gmail.com LinkedIn: http://sdw.st/in > V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres > Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 8340 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 26969 bytes Desc: not available URL: From mag_foto at mac.com Thu Feb 6 08:29:13 2014 From: mag_foto at mac.com (MARK GORE) Date: Thu, 06 Feb 2014 11:29:13 -0500 Subject: Taint Review Team In-Reply-To: References: Message-ID: <9183C6C0-F0D5-41EB-9E70-730100B2E99A@mac.com> "Any agency that is above the law [such as CIA] can get away with anything. It's sad, and most people don't know it, or care, but it's true,” the source says. “When they invoke national security, everyone just craps their pants, even judges." Above is from Narco News, check it Rich, Narco news follows all the crap the DEA does, now my question is can we vector the muckrock training mans' to another leak maybe located in cryptome- in order to obtain the code name for HOW the spooks tip-off LEA's to get into court only to reverse engineer (parallel construct) evidence to cover source methods. Its something to do w/ traffic stops? _Mg mag_foto / blacksetstudio.com On Feb 4, 2014, at 3:04 PM, Rich Jones wrote: > Docs via MuckRock show internal DEA training manuals instructing for parallel construction based on classified / illegally obtained information, combined with an internal review board to shield that information from the public courts. > > https://www.muckrock.com/news/archives/2014/feb/03/dea-parallel-construction-guides/ > > "Americans don't like it!" > > R -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 3115 bytes Desc: not available URL: From jya at pipeline.com Thu Feb 6 09:20:25 2014 From: jya at pipeline.com (John Young) Date: Thu, 06 Feb 2014 12:20:25 -0500 Subject: Jean-Jacques Quisquater on Alleged NSA-GCHQ Hack Message-ID: http://cryptome.org/2014/02/quisquater-comments.htm From gutemhc at gmail.com Thu Feb 6 06:48:41 2014 From: gutemhc at gmail.com (Gutem) Date: Thu, 6 Feb 2014 12:48:41 -0200 Subject: The Spies in Your 3D Printer Message-ID: This article remembered me a documentary about how Xerox's technicians intercepted Communications from Russia's embassy at Cold War... http://3dprintingindustry.com/2014/02/04/spies-3d-printer/ Att, - Gutem ------------------------------------------------------------------------------------------- Registered Linux User: 562142 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 509 bytes Desc: not available URL: From grarpamp at gmail.com Thu Feb 6 12:33:26 2014 From: grarpamp at gmail.com (grarpamp) Date: Thu, 6 Feb 2014 15:33:26 -0500 Subject: consistent pcp/pbp formats In-Reply-To: <20140206192412.GC20154@r4> References: <20140115093443.GE3900@r4> <20140115134145.GF3900@r4> <20140120133104.GL3900@r4> <20140204150729.GB62910@r4> <20140205125110.GE62910@r4> <20140206192412.GC20154@r4> Message-ID: On Thu, Feb 6, 2014 at 2:24 PM, Thomas von Dein wrote: > bobby at io: % pbp -l > valid b888 026a 38e2 cdf7 f0a6 6486 63a5 0fea Bob > invalid ed32 1935 0310 fe6f 35c6 b44d be6b 3ca8 Alicia [1] > alicia at io: % pcp -l > Key ID Type Creation Time Owner > 0xB497AFF45654CD98 primary 2014-02-06T19:58:09 Alicia <> > 0x87358A0988953A67 public 2014-02-06T18:58:02 bob <> Similar to gpg -k/-K, there should be some indication of the key width (parameters), algorithms, expiration, etc in the list of keys. An extended list option could work for that if not desired in a simple -l format. From tom at vondein.org Thu Feb 6 11:24:12 2014 From: tom at vondein.org (Thomas von Dein) Date: Thu, 6 Feb 2014 20:24:12 +0100 Subject: consistent pcp/pbp formats In-Reply-To: <20140205125110.GE62910@r4> References: <20140115093443.GE3900@r4> <20140115134145.GF3900@r4> <20140120133104.GL3900@r4> <20140204150729.GB62910@r4> <20140205125110.GE62910@r4> Message-ID: <20140206192412.GC20154@r4> So, here we go: # bob exports his pk bobby at io: % pbp -x -S Bob > bob.pbp Passphrase for decrypting master key for Bob: # alice exports her pk alicia at io: % pcp -p -b -O alice.pbp Enter passphrase to decrypt your secret key for signing the export: public key exported in PBP format. # bob imports alice' pk bobby at io: % pbp -X -i alice.pbp Success: imported public keys for Alicia bobby at io: % pbp -l valid b888 026a 38e2 cdf7 f0a6 6486 63a5 0fea Bob invalid ed32 1935 0310 fe6f 35c6 b44d be6b 3ca8 Alicia [1] # alice imports bobs pk alicia at io: % pcp -P -I bob.pbp -b key 0x87358A0988953A67 added to ~/.pcpvault. alicia at io: % pcp -l Key ID Type Creation Time Owner 0xB497AFF45654CD98 primary 2014-02-06T19:58:09 Alicia <> 0x87358A0988953A67 public 2014-02-06T18:58:02 bob <> # bob encrypts to alice bobby at io: % echo "HALLO ALICE, KNUTSCHI" > msg bobby at io: % pbp -c -i msg -o encrypted -r Alicia -S Bob Passphrase for decrypting encryption subkey for Bob: # alice decrypts it alicia at io: % pcp -d -I encrypted Enter passphrase to decrypt your secret key: HALLO ALICE, KNUTSCHI Decrypted 22 bytes successfully # other way around, alice encrypts to bob alicia at io: % echo "ACH, SCHNUCKI" | pcp -e -O encrypted -r Bob Enter passphrase to decrypt your secret key: Encrypted 164 bytes for: bob <> # and bob decrypts it bobby at io: % pbp -d -i encrypted -S Bob Passphrase for decrypting encryption subkey for Bob: ACH, SCHNUCKI good message from Alicia [1]: currently pbp shows pcp keys as "invalid", I'm not sure why, but it's on the todo list. Also, I didn't test if signatures are compatible yet, and there are many more things left to solve/agree, like keyformats, sign+crypt support in pbp, among others. best regards, Tom -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From david.vorick at gmail.com Thu Feb 6 20:27:19 2014 From: david.vorick at gmail.com (David Vorick) Date: Thu, 6 Feb 2014 23:27:19 -0500 Subject: Proof of Stake... In-Reply-To: <068380C434AB120536414E89@F74D39FA044AA309EAEA14B9> References: <068380C434AB120536414E89@F74D39FA044AA309EAEA14B9> Message-ID: >From what I can tell, it does not. The problem is that there's nothing preventing hosts from mining on forks simultaneously. In bitcoin, if you mine on forks simultaneously you'll be working with different headers and wasting hashes. In POS, you have nothing to lose from mining forks, and then picking the fork that benefits you the greatest. Some bitcoin devs have called it the nothing-at-stake problem. On Thu, Feb 6, 2014 at 9:44 PM, Juan Garofalo wrote: > > > ...does it work? > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 883 bytes Desc: not available URL: From juan.g71 at gmail.com Thu Feb 6 18:44:55 2014 From: juan.g71 at gmail.com (Juan Garofalo) Date: Thu, 06 Feb 2014 23:44:55 -0300 Subject: Proof of Stake... Message-ID: <068380C434AB120536414E89@F74D39FA044AA309EAEA14B9> ...does it work? From l at odewijk.nl Fri Feb 7 02:40:20 2014 From: l at odewijk.nl (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?=) Date: Fri, 7 Feb 2014 11:40:20 +0100 Subject: Proof of Stake... In-Reply-To: References: <068380C434AB120536414E89@F74D39FA044AA309EAEA14B9> Message-ID: Any functional complaint + it being illogical economically. Power to those that rule. Fantastic plan. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 119 bytes Desc: not available URL: From seanl at literati.org Fri Feb 7 11:53:33 2014 From: seanl at literati.org (Sean Lynch) Date: Fri, 7 Feb 2014 11:53:33 -0800 Subject: Proof of Stake... In-Reply-To: References: <068380C434AB120536414E89@F74D39FA044AA309EAEA14B9> Message-ID: AIUI there are multiple ways to implement proof-of-stake. A friend of mine proposed treating the chain with the most coin days destroyed (along with correct difficulties for the standard proof-of-work function) as the "longest" one rather than only the most difficult chain. Does that not work? On Fri, Feb 7, 2014 at 2:40 AM, Lodewijk andré de la porte wrote: > Any functional complaint + it being illogical economically. Power to those > that rule. Fantastic plan. > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 804 bytes Desc: not available URL: From seanl at literati.org Fri Feb 7 12:09:36 2014 From: seanl at literati.org (Sean Lynch) Date: Fri, 7 Feb 2014 12:09:36 -0800 Subject: Proof of Stake... In-Reply-To: References: <068380C434AB120536414E89@F74D39FA044AA309EAEA14B9> Message-ID: The different transactions change the block hash, though, so it's the same problem for the attacker that you originally pointed out with proof-of-work, no? On Fri, Feb 7, 2014 at 12:06 PM, David Vorick wrote: > The problem is that you have a bunch of your own coins, so you are mining > the chains that have been announced, but you are also mining possible > chains that involve you that you never announced. > > So if I never announce that I destroy 10 coin days, but I have 10 coin > days to destroy, there is an alternate reality that I'm also mining, If I > don't like the current chain, I can add my own coin days to a different > fork in the past to make that fork now the heaviest fork. Then I announce > it. Especially if I'm working with a bunch of other people, they can add > their own coins and we can work together to make it the longest chain. If > it becomes the longest chain, they get back any coins they destroyed in an > alternate history. > > So basically, it's very cheap for a set of collaborating nodes to build a > forest of alternate chains, and the longest can change anytime we > collectively alter the history or add another fork somewhere to make it the > new longest. It's relatively inexpensive to balance all these forks. > > So it works as long as the powerful individuals aren't mining multiple > chain simultaneously. But what's to stop them? So it's ultimately not very > secure once powerful groups start attacking the currency. > > > On Fri, Feb 7, 2014 at 2:53 PM, Sean Lynch wrote: > >> AIUI there are multiple ways to implement proof-of-stake. A friend of >> mine proposed treating the chain with the most coin days destroyed (along >> with correct difficulties for the standard proof-of-work function) as the >> "longest" one rather than only the most difficult chain. Does that not work? >> >> >> On Fri, Feb 7, 2014 at 2:40 AM, Lodewijk andré de la porte wrote: >> >>> Any functional complaint + it being illogical economically. Power to >>> those that rule. Fantastic plan. >>> >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 3099 bytes Desc: not available URL: From seanl at literati.org Fri Feb 7 14:55:03 2014 From: seanl at literati.org (Sean Lynch) Date: Fri, 7 Feb 2014 14:55:03 -0800 Subject: Proof of Stake... In-Reply-To: References: <068380C434AB120536414E89@F74D39FA044AA309EAEA14B9> Message-ID: Sorry, meant to include the list before. Switching to inline reply since I want to reply to separate points separately. On Fri, Feb 7, 2014 at 12:40 PM, Lodewijk andré de la porte wrote: > 2014-02-07 Sean Lynch : > > Substitute "CPU power" for "wealth," and your claim about trust equally >> applies to the current proof-of-work function. I don't accept your premise >> that giving more power to wealthy people is somehow worse than giving more >> power to people with lots of CPU power (i.e. wealthy people). > > > Ah, yes. But now you're confusing some things. > > I can calculate that a certain transaction is no longer worth falsifying. > Let's say that there's 10,000 USD (10kusd) required to fake a single block. > > Now my transaction is buried 5 blocks. Setting apart a block just for the > sake of luck-prevention I can say that if my transaction is <40kUSD it is > now entirely safe. It is not worth it to revert it. > > Unless someone wants to mess with me (specifically me) it will not be > done. If I suspect someone wants to mess with me I only have to estimate > how much he can spend messing with me. > > Block reward kind of throws a wrench into the story. It drastically > reduces the actual cost of mining a block. Still I can say with math that > it isn't worth it after a while. > > With proof of stake I cannot do such math. I'm subjected not to the will > of the rich to mess with me. Not the will of the rich to waste money on me. > And the cost of faking a chain does not grow with it's length, unless it's > a proof-of-work-and-stake. In which case I'm really wondering why you're > taking two risks. > Either way, this is not equivalent to introducing trust into the system where it did not exist before. My claim about proof-of-stake not being trust any more than proof-of-work is stands. I was proposing using coin days destroyed as part of the "difficulty" computation, which would mean they actually DO have value, since you cannot use the same coin days more than once, and they would reduce the number of CPU cycles you need to burn in order to produce a block. The idea is to reduce the cost of mining in terms of pure CPU cycles by giving value to something that currently has no value: coin days. So you actually CAN do such math still. This is not a pure proof-of-stake system, though. I am as skeptical of pure proof of stake as you are. > I'm more strongly in favor of using citizen's ID's as provided by > governments for the purpose of voting on blocks than in proof of stake. > Not knowing you, this doesn't tell me much, since the same could be said of the most statist friend I actually tolerate, the one who thinks Bitcoin should die in a fire. I'm guessing that this means "not in favor of it at all." There are a couple of problems people are trying to solve with proof-of-stake. The first is that the value of mining will eventually go down, meaning people will be willing to devote less computing power to it, reducing the cost of an attack. The second is that, even if it didn't go down, we don't necessarily want a huge fraction of the world's computing power devoted to mining. The goal is to take some limited resource that doesn't depend on a trusted third party and that is difficult to corner and use that to distribute voting authority. In addition, we'd like the people doing the voting to have an economic incentive to vote correctly. Bitcoin does that by paying them to vote and revoking the payment if their block doesn't end up in the main chain. Proof-of-stake does it by hoping that the voters care about the integrity of the system, similar to only allowing landowners to vote, only (hopefully) without the ability to prevent others from becoming stakeholders, which I think is your main worry about it. Incidentally, the coin days are from ALL of the transactions in the block, not just your own. I'm not sure if I was clear about that before. You could maybe override a transaction that had fewer coin days, but you'd have to burn a similar amount (though less) of CPU time in addition. Speaking of which, is there any reason peers couldn't watch for forks and incorporate any still-valid transactions into new blocks and permanently blacklist any outputs that get double-spent? You could create a special "blacklist" transaction that just incorporates the two separate spends into the main chain, so that everyone could validate that the account holder attempted to double spend. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 6119 bytes Desc: not available URL: From david.vorick at gmail.com Fri Feb 7 12:06:04 2014 From: david.vorick at gmail.com (David Vorick) Date: Fri, 7 Feb 2014 15:06:04 -0500 Subject: Proof of Stake... In-Reply-To: References: <068380C434AB120536414E89@F74D39FA044AA309EAEA14B9> Message-ID: The problem is that you have a bunch of your own coins, so you are mining the chains that have been announced, but you are also mining possible chains that involve you that you never announced. So if I never announce that I destroy 10 coin days, but I have 10 coin days to destroy, there is an alternate reality that I'm also mining, If I don't like the current chain, I can add my own coin days to a different fork in the past to make that fork now the heaviest fork. Then I announce it. Especially if I'm working with a bunch of other people, they can add their own coins and we can work together to make it the longest chain. If it becomes the longest chain, they get back any coins they destroyed in an alternate history. So basically, it's very cheap for a set of collaborating nodes to build a forest of alternate chains, and the longest can change anytime we collectively alter the history or add another fork somewhere to make it the new longest. It's relatively inexpensive to balance all these forks. So it works as long as the powerful individuals aren't mining multiple chain simultaneously. But what's to stop them? So it's ultimately not very secure once powerful groups start attacking the currency. On Fri, Feb 7, 2014 at 2:53 PM, Sean Lynch wrote: > AIUI there are multiple ways to implement proof-of-stake. A friend of mine > proposed treating the chain with the most coin days destroyed (along with > correct difficulties for the standard proof-of-work function) as the > "longest" one rather than only the most difficult chain. Does that not work? > > > On Fri, Feb 7, 2014 at 2:40 AM, Lodewijk andré de la porte wrote: > >> Any functional complaint + it being illogical economically. Power to >> those that rule. Fantastic plan. >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 2496 bytes Desc: not available URL: From juan.g71 at gmail.com Fri Feb 7 13:14:08 2014 From: juan.g71 at gmail.com (Juan Garofalo) Date: Fri, 07 Feb 2014 18:14:08 -0300 Subject: Proof of Stake... In-Reply-To: References: <068380C434AB120536414E89@F74D39FA044AA309EAEA14B9> Message-ID: <78140E357E94EC8A0AD9CF7D@F74D39FA044AA309EAEA14B9> --On Thursday, February 06, 2014 11:27 PM -0500 David Vorick wrote: >> From what I can tell, it does not. > > The problem is that there's nothing preventing hosts from mining on forks > simultaneously. In bitcoin, if you mine on forks simultaneously you'll be > working with different headers and wasting hashes. In POS, you have > nothing to lose from mining forks, and then picking the fork that > benefits you the greatest. > > Some bitcoin devs have called it the nothing-at-stake problem. Thanks David. I guess I won't get the full picture until I spend some mental effort understanding the mechanism. Which is something I've been procrastinating on =P At any rate, an attack against, say, nextcoin should be 'feasible' and would be proof that proof of stake isn't too robust? > > > On Thu, Feb 6, 2014 at 9:44 PM, Juan Garofalo wrote: > >> >> >> ...does it work? >> >> >> >> > From l at odewijk.nl Fri Feb 7 12:23:48 2014 From: l at odewijk.nl (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?=) Date: Fri, 7 Feb 2014 21:23:48 +0100 Subject: Proof of Stake... In-Reply-To: References: <068380C434AB120536414E89@F74D39FA044AA309EAEA14B9> Message-ID: 2014-02-07 Sean Lynch : > The different transactions change the block hash, though, so it's the same > problem for the attacker that you originally pointed out with > proof-of-work, no? The problem is that you've introduced trust into a trust-free system. And you didn't even pick wisely, you picked wealthy. The assumption used to justify wealthy is that people that are wealthy will want to preserve the system, and it's value. They are actually more likely driven with increasing their wealth. This, of course, is not unreasonable. But a "pretty cracked up currency" is still okay to enough people. You can't trust people to judge the crackedupness of a (psuedonymous) system. This is the same reason "regular banking" fails. @David, this would probably cause some trouble amongst those wealthy people. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 1424 bytes Desc: not available URL: From tom at ritter.vg Fri Feb 7 20:02:18 2014 From: tom at ritter.vg (Tom Ritter) Date: Fri, 7 Feb 2014 23:02:18 -0500 Subject: FB's Conceal secure-storage API In-Reply-To: <52F24DD0.5050408@cryptolab.net> References: <52F24DD0.5050408@cryptolab.net> Message-ID: It's not like preventing root from getting the key is some attribute they omitted by accident or incompetence - it's a significant design change that changes the way the application would work. It seems like everyone criticizing Facebook is angry that they're not compromising their design principals for added security. They have very clear priorities: We are _going_ to benchmark and make sure any code we add does not increase UI latency beyond an unacceptable limit. We are _going_ to cache some large MB of data on the phone, because it makes the app faster. We are _not_ going to take up more space than we need. We are _going_ to support old phones that have an SD Card, and if that's where we cache the data, then so be it. We are _not_ going to require the user to enter a password or PIN on app startup. We are _not_ going to require the phone to be online to used the cached data. With requirements like those, what you get is exactly this library. It adds some small level of security against a very specific attack: data stored on the SD Card and accessible to other programs. (It may even be a way to get the security they need to permit themselves to store cached data on the SD Card, which is a desirable situation because it makes the app faster.) If you relax some of those requirements, you can add security features. Relax the latency or minimal storage requirement and you can create an encrypted container, and hide metadata like filenames, sizes, and times (like IOCipher). Relax the password requirement, and you can have the user enter a password on app startup and prevent root from getting the key unless it's in memory or entered. Relax the latency and offline requirement, and you can have the server send down a key to decrypt the data. Facebook is starting with the User Experience and adding as much security as it allows. -tom From l at odewijk.nl Sat Feb 8 06:02:11 2014 From: l at odewijk.nl (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?=) Date: Sat, 8 Feb 2014 15:02:11 +0100 Subject: Proof of Stake... In-Reply-To: References: <068380C434AB120536414E89@F74D39FA044AA309EAEA14B9> Message-ID: > > Either way, this is not equivalent to introducing trust into the system > where it did not exist before. My claim about proof-of-stake not being > trust any more than proof-of-work is stands. > > I was proposing using coin days destroyed as part of the "difficulty" > computation, which would mean they actually DO have value, since you cannot > use the same coin days more than once, and they would reduce the number of > CPU cycles you need to burn in order to produce a block. The idea is to > reduce the cost of mining in terms of pure CPU cycles by giving value to > something that currently has no value: coin days. So you actually CAN do > such math still. > No. Rewriting the blockchain gives back those coin days. I imagine it's pretty hard to use many people's coin days for the same block, whereas a nonce to a block is very easy to communicate. > This is not a pure proof-of-stake system, though. I am as skeptical of > pure proof of stake as you are. > Why? If it works it works and if it doesn't it doesn't. A mix between the two is an extremely political and complicating choice. > > >> I'm more strongly in favor of using citizen's ID's as provided by >> governments for the purpose of voting on blocks than in proof of stake. >> > > Not knowing you, this doesn't tell me much, since the same could be said > of the most statist friend I actually tolerate, the one who thinks Bitcoin > should die in a fire. I'm guessing that this means "not in favor of it at > all." > I'm stuck with a democracy problem. Is Plutocracy better? Is Democracy better? Is any Obliarchy better? I tend to think that the people are incapable of making the best choice. Things turn into a trust/populism issue as the people thinks emotionally. Additionally it just often lacks the domain specific knowledge for a good choice. Thus a form of obliarchy should be better. The selection criteria is the real problem. Elections typically reintroduce the previous problems. A higher level of education is a start as it correlates with domain specific knowledge. It correlates too weakly for my taste. And it lacks testing for critical thinking and similar skills, although they also correlate. This also puts a pressure on determining the level of education that isn't in the best interest of academics. Simple intelligence testing would be preferable. But it is as of yet impossible to accurately determine intelligence. Wealthy is a selector that would work if it were not for a distorted political situation and different levels of economic engagement present even amongst the most capable human beings. Ultimately the obliarchs can be trusted to make choices best for them, and not the rest, in the ideal situation. Thus I feel it is not adequate. In the end however the social/political/economical power wins anyway. Might as well hardcode it. Even with all choices made up front a system will only thrive with the support of people. People can be convinced and coerced with political or economic power, or the social pressure of their peers. The standing arguments against POS are: * "Stake" is reverted/restored when the blockchain is rewritten * It's a political choice, not so much a functional one * Bitcoin days become a commodity of it's own (it is now too, as it speeds up transactions, but it becomes something worth buying not something that's nice to have. Can you imagine trading 1 btc for 1.2 btc and it being worth it? Sidetracking by exchanging private keys -_-'.... ) * One's investment might change in a single trade. This might also be true of mining, but it doesn't have to be. * Large scale mining is traceable. This is an interesting notion, actually. It'd seem that POS mining is more government-resistant as it does not require large energy expenses. I think if someone can solve the "investedness" in a certain blockchain it gets very interesting. > There are a couple of problems people are trying to solve with > proof-of-stake. The first is that the value of mining will eventually go > down, meaning people will be willing to devote less computing power to it, > reducing the cost of an attack. > The relative cost of an attack. It is also assumed that the overal usage goes up. Mining not going down is a change I would make. > The second is that, even if it didn't go down, we don't necessarily want a > huge fraction of the world's computing power devoted to mining. > The everlasting counter argument is that money now is costlier still. There's a simple trade between fraction of computing power devoted to mining and security. There's also stuff like http://www.gridcoin.us/ that, if properly implemented, could drive down computing costs for scientific application. > The goal is to take some limited resource that doesn't depend on a trusted > third party and that is difficult to corner and use that to distribute > voting authority. > I think this sort of clarity is valuable. There's a lot of stuff that needs additional support. If it has to be trusted it is usually not called a third party. The wealth of individuals is definitely something governments have* a lot* of influence on. Difficult to corner for who? Why and how do you want to distributed voting authority, that's the ultimate question. Ideally there wouldn't be such a thing as votes, just transactions. > In addition, we'd like the people doing the voting to have an economic > incentive to vote correctly. > Correctly is undefined. If you give people economic incentive the most profitable choice would be the one taken. Making the voters take a choice best for the system, thus the most profitable, might also not have desirable results. Depending, of course, on the ultimate question. > Bitcoin does that by paying them to vote and revoking the payment if their > block doesn't end up in the main chain. > You don't name the cost of voting. They are allowed to extend the blockchain and get compensated for it. If they were wrong about their extension, as defined by the mayority of extenders, their payment gets revoked. This is enough to ensure each will apply the same rule to maximize profit. > Proof-of-stake does it by hoping that the voters care about the integrity > of the system, similar to only allowing landowners to vote, only > (hopefully) without the ability to prevent others from becoming > stakeholders, which I think is your main worry about it. > You incentivise becoming a greater stakeholder. I also think that people with a lot of money will have ulterior motives. They don't just sit on their money. There's also interplay between many currencies and their exchange. It all complicates the system tremendously. The chief concern for the blockchain is ensuring a singular sequence of transactions. Nothing else is vital. As a side effect the miners can change the policies, but this is not a pleasant feature. Voluntary entrance to a system is ideal. No need to run with BitcoinXKE, I prefer BitcoinXKA. Blockchain forking does enable that. But transactions could cross between chains where they are legitimate and it could get very messy. I'm worried about wanting a digital gold and getting a digital euro. Reducing the flexibility of votes is a good means to that end. In Bitcoin a policy change is agreed on before hand, a switchover date is arranged, etc, in order to not lose money. That's pretty good. > Incidentally, the coin days are from ALL of the transactions in the block, > not just your own. I'm not sure if I was clear about that before. > You weren't and I'm not sure how this would work. If I sent in a transaction to the network, someone else can claim reward for it? Do I get rewarded for it? This sounds like I'd have to re-announce my presence on the network pretty frequently, allowing for easier tracking of participants. > You could maybe override a transaction that had fewer coin days, but > you'd have to burn a similar amount (though less) of CPU time in addition. > ASIC time? But why override? I just change the order and that's enough. How does POS factor into POW in this case? I suspect reminting older blocks with more transactions would be feasible. But you have to link to or explain how you want to do POS. > Speaking of which, is there any reason peers couldn't watch for forks and > incorporate any still-valid transactions into new blocks and permanently > blacklist any outputs that get double-spent? You could create a special > "blacklist" transaction that just incorporates the two separate spends into > the main chain, so that everyone could validate that the account holder > attempted to double spend. > There may be legitimate incidents of accidental double spending. You're also only fucking the recipient of the transaction, the sender has it's trade long behind him. It even means I could do a legitimate transaction and later destroy the money I sent. Close but no ball. Without psuedonyms this is more feasible. You could kill the sender's address, but that won't have much effect. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 13827 bytes Desc: not available URL: From jya at pipeline.com Sat Feb 8 15:28:44 2014 From: jya at pipeline.com (John Young) Date: Sat, 08 Feb 2014 18:28:44 -0500 Subject: Snowden Drop to Poitras and Greenwald Described Message-ID: http://cryptome.org/2014/02/snowden-drop.pdf (7.6MB) From jya at pipeline.com Sun Feb 9 04:56:35 2014 From: jya at pipeline.com (John Young) Date: Sun, 09 Feb 2014 07:56:35 -0500 Subject: [cryptography] Snowden Drop to Poitras and Greenwald Described In-Reply-To: <52F72498.9020907@iang.org> References: <52F72498.9020907@iang.org> Message-ID: Correct, page 13 was missing. Thanks. Now added. Page begins with "his head. But Snowden told her:" Ends with "Even with Assange's" At 01:47 AM 2/9/2014, you wrote: >On 9/02/14 02:28 AM, John Young wrote: > > http://cryptome.org/2014/02/snowden-drop.pdf (7.6MB) > > >page 12: After all, coming forward would bring the law down on > >... > >Next page: skills, Snowden realised it would be difficult to punch > >Seems like a missing page? > >iang From jya at pipeline.com Sun Feb 9 07:32:45 2014 From: jya at pipeline.com (John Young) Date: Sun, 09 Feb 2014 10:32:45 -0500 Subject: Snowden Meets MacAskill, Poitras and Greenwald Message-ID: http://cryptome.org/2014/02/snowden-meet.pdf Snowden to MacAskill, vehemently: "GCHQ is worse than NSA. It's even more intrusive." From Jamesd at echeque.com Sun Feb 9 00:57:34 2014 From: Jamesd at echeque.com (James A. Donald) Date: Sun, 09 Feb 2014 18:57:34 +1000 Subject: Proof of Stake... In-Reply-To: References: <068380C434AB120536414E89@F74D39FA044AA309EAEA14B9> Message-ID: <52F742FE.1080400@echeque.com> We need a solution to the Byzantine generals problem for generating a hash that reflects a globally agreed truth as to who owns what coins, in which influence is proportional primarily to value owned, provided one also provides adequate connectivity and computing power. If influence proportional to cpu power, problem. From l at odewijk.nl Sun Feb 9 17:23:46 2014 From: l at odewijk.nl (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?=) Date: Mon, 10 Feb 2014 02:23:46 +0100 Subject: FB's Conceal secure-storage API In-Reply-To: References: <52F24DD0.5050408@cryptolab.net> Message-ID: This is purely to circumvent the "SD card is public space" issue. The only idea is to have the same measure of security in memory as on the SD card, to allow for large caches. So: Private key in memory. Fast encryption streaming algorithm to write and read to the SD card with the private key in memory. Fast. That's it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 521 bytes Desc: not available URL: From tom at vondein.org Mon Feb 10 07:39:07 2014 From: tom at vondein.org (Thomas von Dein) Date: Mon, 10 Feb 2014 16:39:07 +0100 Subject: consistent pcp/pbp formats In-Reply-To: References: <20140115134145.GF3900@r4> <20140120133104.GL3900@r4> <20140204150729.GB62910@r4> <20140205125110.GE62910@r4> <20140206192412.GC20154@r4> Message-ID: <20140210153907.GF43866@r4> Hi, On Thu, Feb 06, 2014 at 03:33:26PM -0500, grarpamp wrote: > Similar to gpg -k/-K, there should be some indication of > the key width (parameters), algorithms, expiration, etc in > the list of keys. Would be easily possible but doesn't make much sense currently, since there's only 1 algorithm supported and the key size for it is static. Btw, at least in pcp there's a -t option which can be used to display all details about a key. regards, Tom -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From rich at openwatch.net Tue Feb 11 11:32:54 2014 From: rich at openwatch.net (Rich Jones) Date: Tue, 11 Feb 2014 11:32:54 -0800 Subject: Snowden and Compilers Message-ID: In all of the Snowden docs that have been released so far, has anybody seen any mention of any NSA programs designed to subvert compilers? Compilers seems like an extremely prime target for manipulation, but as far as I am aware there hasn't been anything mentioned about this yet. Has anybody here heard anything that I haven't? R -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 392 bytes Desc: not available URL: From gutemhc at gmail.com Tue Feb 11 07:11:38 2014 From: gutemhc at gmail.com (Gutem) Date: Tue, 11 Feb 2014 13:11:38 -0200 Subject: A Surprisingly Easy Tool for Encrypting Email, Courtesy of an Ex-NSA Employee Message-ID: Encrypting for the masses? http://motherboard.vice.com/blog/a-surprisingly-easy-tool-for-encrypting-email-courtesy-an-ex-nsa-employee Att, - Gutem ------------------------------------------------------------------------------------------- Registered Linux User: 562142 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 481 bytes Desc: not available URL: From iam at kjro.se Tue Feb 11 13:47:01 2014 From: iam at kjro.se (Kelly John Rose) Date: Tue, 11 Feb 2014 14:47:01 -0700 Subject: Snowden and Compilers In-Reply-To: References: Message-ID: I could see them more easily subverting chip designs themselves then trying to subvert the entire compiler ecosystem. On Tue, Feb 11, 2014 at 2:05 PM, CypherPunk wrote: > > On 02/11/2014 01:32 PM, Rich Jones wrote: > > In all of the Snowden docs that have been released so far, has anybody > > seen any mention of any NSA programs designed to subvert compilers? > > > > Compilers seems like an extremely prime target for manipulation, but as > > far as I am aware there hasn't been anything mentioned about this yet. > > Has anybody here heard anything that I haven't? > > Given that compilers are both a fairly easy to attack and amazingly > convenient target, it wouldn't surprise me if the NSA has subverted a > few specific compilers that are in common use. An attack of this nature > has been hypothised since the early to mid-1980's. They would have to be > amazingly dense not to have at least considered it. > > On the flip side, the NSA likes to do things where it has the least > opportunity to be caught. Compiler subversion, while not "easy" to catch > by any means, might offer too big a risk of being caught for them to do > it. Being that they have a multitude of weirdly named programs > specifically set up to compromise software, the evidence would lean > towards they haven't done it but I'm sure it was, at the very least, > discussed. > -- Kelly John Rose Toronto, ON Phone: +1 647 638-4104 Twitter: @kjrose Skype: kjrose.pr Gtalk: iam at kjro.se MSN: msn at kjro.se Document contents are confidential between original recipients and sender. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 2297 bytes Desc: not available URL: From cypherpunk at cpunk.us Tue Feb 11 13:05:10 2014 From: cypherpunk at cpunk.us (CypherPunk) Date: Tue, 11 Feb 2014 15:05:10 -0600 Subject: Snowden and Compilers In-Reply-To: References: Message-ID: On 02/11/2014 01:32 PM, Rich Jones wrote: > In all of the Snowden docs that have been released so far, has anybody > seen any mention of any NSA programs designed to subvert compilers? > > Compilers seems like an extremely prime target for manipulation, but as > far as I am aware there hasn't been anything mentioned about this yet. > Has anybody here heard anything that I haven't? Given that compilers are both a fairly easy to attack and amazingly convenient target, it wouldn't surprise me if the NSA has subverted a few specific compilers that are in common use. An attack of this nature has been hypothised since the early to mid-1980's. They would have to be amazingly dense not to have at least considered it. On the flip side, the NSA likes to do things where it has the least opportunity to be caught. Compiler subversion, while not "easy" to catch by any means, might offer too big a risk of being caught for them to do it. Being that they have a multitude of weirdly named programs specifically set up to compromise software, the evidence would lean towards they haven't done it but I'm sure it was, at the very least, discussed. From hozer at hozed.org Tue Feb 11 14:17:51 2014 From: hozer at hozed.org (Troy Benjegerdes) Date: Tue, 11 Feb 2014 16:17:51 -0600 Subject: Snowden and Compilers In-Reply-To: References: Message-ID: <20140211221751.GW3180@nl.grid.coop> All the 'NDA'/proprietary/confidential information that goes with chip designs provide plenty of cover to insert backdoors. GCC would be a lot harder and people would be looking for it. But your USB chip, graphics card, hard drive, or two factor authentication token, on the other hand... The chinese are probably even copying the subverted chip designs without even knowing it's there. On Tue, Feb 11, 2014 at 02:47:01PM -0700, Kelly John Rose wrote: > I could see them more easily subverting chip designs themselves then trying > to subvert the entire compiler ecosystem. > > > On Tue, Feb 11, 2014 at 2:05 PM, CypherPunk wrote: > > > > > On 02/11/2014 01:32 PM, Rich Jones wrote: > > > In all of the Snowden docs that have been released so far, has anybody > > > seen any mention of any NSA programs designed to subvert compilers? > > > > > > Compilers seems like an extremely prime target for manipulation, but as > > > far as I am aware there hasn't been anything mentioned about this yet. > > > Has anybody here heard anything that I haven't? > > > > Given that compilers are both a fairly easy to attack and amazingly > > convenient target, it wouldn't surprise me if the NSA has subverted a > > few specific compilers that are in common use. An attack of this nature > > has been hypothised since the early to mid-1980's. They would have to be > > amazingly dense not to have at least considered it. > > > > On the flip side, the NSA likes to do things where it has the least > > opportunity to be caught. Compiler subversion, while not "easy" to catch > > by any means, might offer too big a risk of being caught for them to do > > it. Being that they have a multitude of weirdly named programs > > specifically set up to compromise software, the evidence would lean > > towards they haven't done it but I'm sure it was, at the very least, > > discussed. > > > > > > -- > Kelly John Rose > Toronto, ON > Phone: +1 647 638-4104 > Twitter: @kjrose > Skype: kjrose.pr > Gtalk: iam at kjro.se > MSN: msn at kjro.se > > Document contents are confidential between original recipients and sender. From drwho at virtadpt.net Tue Feb 11 16:55:07 2014 From: drwho at virtadpt.net (The Doctor) Date: Tue, 11 Feb 2014 16:55:07 -0800 Subject: Snowden and Compilers In-Reply-To: References: Message-ID: <52FAC66B.1060000@virtadpt.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/11/2014 11:32 AM, Rich Jones wrote: > Compilers seems like an extremely prime target for manipulation, > but as far as I am aware there hasn't been anything mentioned about > this yet. Has anybody here heard anything that I haven't? Read Dr. David A. Wheeler's dissertation, _Fully Countering Trusting Trust through Diverse Double-Compiling - Countering Trojan Horse attacks on Compilers_. It is also worth noting that there are more open source compilers out there than it seems at first scratch; one in particular called TCC (Tiny C Compiler) is relatively small as compilations go so it's much easier to read through and audit as a way of bootstrapping a compilation toolchain. It can also compile other compilers quite nicely... http://www.dwheeler.com/trusting-trust/ - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "We could be readin' a book." --Huey, _The Boondocks_ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlL6xmsACgkQO9j/K4B7F8ENGgCgiq4URGIfsIHxrQzQvdD6SIPC ypYAoIHtdVXkaYkLzwgXUGoXbThic3rR =ZkTL -----END PGP SIGNATURE----- From drwho at virtadpt.net Tue Feb 11 16:55:54 2014 From: drwho at virtadpt.net (The Doctor) Date: Tue, 11 Feb 2014 16:55:54 -0800 Subject: A Surprisingly Easy Tool for Encrypting Email, Courtesy of an Ex-NSA Employee In-Reply-To: <009101cf2765$6f91a5b0$4eb4f110$@net> References: <009101cf2765$6f91a5b0$4eb4f110$@net> Message-ID: <52FAC69A.5030409@virtadpt.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/11/2014 12:11 PM, Silent1 wrote: > ?Ex-nsa? employee leaves NSA and creates new encryption to stop the > NSA would be a good idea for the NSA to run as simple tradecraft! Announcing that one is a former NSA employee should be enough to cause people to run screaming from it... - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "We could be readin' a book." --Huey, _The Boondocks_ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlL6xpoACgkQO9j/K4B7F8EvtACfWc1h0oRaE123OkJy5X/PM9rW f5AAoLSYiRUgCyhx9wq7aBMlBitUAOjV =J3Z0 -----END PGP SIGNATURE----- From drwho at virtadpt.net Tue Feb 11 16:57:50 2014 From: drwho at virtadpt.net (The Doctor) Date: Tue, 11 Feb 2014 16:57:50 -0800 Subject: Snowden and Compilers In-Reply-To: <20140211221751.GW3180@nl.grid.coop> References: <20140211221751.GW3180@nl.grid.coop> Message-ID: <52FAC70E.9090907@virtadpt.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/11/2014 02:17 PM, Troy Benjegerdes wrote: > All the 'NDA'/proprietary/confidential information that goes with > chip designs provide plenty of cover to insert backdoors. We have already seen that they do not have to subvert the designs if they can intercept components and replace them with boobytrapped look- and work-alikes. > But your USB chip, graphics card, hard drive, or two factor > authentication token, on the other hand... Firmware bootkits are also potential vectors. Why go to the trouble of backdooring the hardware when you can go after the firmware blobs that few bother to reverse engineer anyway? - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "We could be readin' a book." --Huey, _The Boondocks_ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlL6xw4ACgkQO9j/K4B7F8GIggCfeTxAEk7xL/rGAP1XYS119CL3 RsMAoJbDUeUoLtthNEt/eIhE9Blq7Aa2 =8uwz -----END PGP SIGNATURE----- From rich at openwatch.net Tue Feb 11 17:51:33 2014 From: rich at openwatch.net (Rich Jones) Date: Tue, 11 Feb 2014 17:51:33 -0800 Subject: Snowden and Compilers In-Reply-To: <20140211221751.GW3180@nl.grid.coop> References: <20140211221751.GW3180@nl.grid.coop> Message-ID: > GCC would be a lot harder and people would be looking for it. GCC yes, but what about Visual Studio? The LLVM which ships with XCode? Javac? Those are much jucier targets than say, Debian's GCC. If I worked at the NSA, I'd make backdooring Visual Studio my 20% project. If anybody with Snowden cache access who is reading this could do me a quick favor and grep for 'compiler,' and then publish the output, I'd really appreciate it. Thanks, R On Tue, Feb 11, 2014 at 2:17 PM, Troy Benjegerdes wrote: > All the 'NDA'/proprietary/confidential information that goes with chip > designs > provide plenty of cover to insert backdoors. > > GCC would be a lot harder and people would be looking for it. > > But your USB chip, graphics card, hard drive, or two factor authentication > token, on the other hand... > > The chinese are probably even copying the subverted chip designs without > even knowing it's there. > > On Tue, Feb 11, 2014 at 02:47:01PM -0700, Kelly John Rose wrote: > > I could see them more easily subverting chip designs themselves then > trying > > to subvert the entire compiler ecosystem. > > > > > > On Tue, Feb 11, 2014 at 2:05 PM, CypherPunk wrote: > > > > > > > > On 02/11/2014 01:32 PM, Rich Jones wrote: > > > > In all of the Snowden docs that have been released so far, has > anybody > > > > seen any mention of any NSA programs designed to subvert compilers? > > > > > > > > Compilers seems like an extremely prime target for manipulation, but > as > > > > far as I am aware there hasn't been anything mentioned about this > yet. > > > > Has anybody here heard anything that I haven't? > > > > > > Given that compilers are both a fairly easy to attack and amazingly > > > convenient target, it wouldn't surprise me if the NSA has subverted a > > > few specific compilers that are in common use. An attack of this nature > > > has been hypothised since the early to mid-1980's. They would have to > be > > > amazingly dense not to have at least considered it. > > > > > > On the flip side, the NSA likes to do things where it has the least > > > opportunity to be caught. Compiler subversion, while not "easy" to > catch > > > by any means, might offer too big a risk of being caught for them to do > > > it. Being that they have a multitude of weirdly named programs > > > specifically set up to compromise software, the evidence would lean > > > towards they haven't done it but I'm sure it was, at the very least, > > > discussed. > > > > > > > > > > > -- > > Kelly John Rose > > Toronto, ON > > Phone: +1 647 638-4104 > > Twitter: @kjrose > > Skype: kjrose.pr > > Gtalk: iam at kjro.se > > MSN: msn at kjro.se > > > > Document contents are confidential between original recipients and > sender. > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 3801 bytes Desc: not available URL: From rysiek at hackerspace.pl Tue Feb 11 09:04:22 2014 From: rysiek at hackerspace.pl (rysiek) Date: Tue, 11 Feb 2014 18:04:22 +0100 Subject: A Surprisingly Easy Tool for Encrypting Email, Courtesy of an Ex-NSA Employee In-Reply-To: References: Message-ID: <1906909.tKIgGesFsW@lap> Dnia wtorek, 11 lutego 2014 13:11:38 Gutem pisze: > Encrypting for the masses? > http://motherboard.vice.com/blog/a-surprisingly-easy-tool-for-encrypting-ema > il-courtesy-an-ex-nsa-employee This has probably been already posted here, but here goes anyway: http://encrypt.to inb4 myriad of problems with that approach -- yes, it's all true, but still, that's a way of getting people to send encrypted e-mail. -- Pozdr rysiek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: From lists at silent1.net Tue Feb 11 12:11:16 2014 From: lists at silent1.net (Silent1) Date: Tue, 11 Feb 2014 20:11:16 -0000 Subject: A Surprisingly Easy Tool for Encrypting Email, Courtesy of an Ex-NSA Employee In-Reply-To: References: Message-ID: <009101cf2765$6f91a5b0$4eb4f110$@net> What is to say that it's not backdoored to buggery? 'Ex-nsa' employee leaves NSA and creates new encryption to stop the NSA would be a good idea for the NSA to run as simple tradecraft! From: cypherpunks [mailto:cypherpunks-bounces at cpunks.org] On Behalf Of Gutem Sent: Tuesday, February 11, 2014 3:12 PM To: Cypherpunks Subject: A Surprisingly Easy Tool for Encrypting Email, Courtesy of an Ex-NSA Employee Encrypting for the masses? http://motherboard.vice.com/blog/a-surprisingly-easy-tool-for-encrypting-ema il-courtesy-an-ex-nsa-employee Att, - Gutem ---------------------------------------------------------------------------- --------------- Registered Linux User: 562142 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 3259 bytes Desc: not available URL: From apx.808 at gmail.com Tue Feb 11 16:02:47 2014 From: apx.808 at gmail.com (APX 808) Date: Tue, 11 Feb 2014 22:02:47 -0200 Subject: Snowden and Compilers In-Reply-To: <20140211221751.GW3180@nl.grid.coop> References: <20140211221751.GW3180@nl.grid.coop> Message-ID: A few years ago some guys from Core security published a research were they found laptop's BIOS with a tool called Computrace that supposedly was to protect you if your computer was stolen, but contained a backdoor that allowed remote access and code execution. Computrace was installed in the BIOS for Notebooks of HP, Dell, Lenovo, Toshiba, Gateway, Asus, Panasonic, and more. No one can confirm it was the NSA yet... Snowden do you have something about it in your collection? Here is the paper http://www.blackhat.com/presentations/bh-usa-09/ORTEGA/BHUSA09-Ortega-DeactivateRootkit-PAPER.pdf Cheerz http://apx808.blogspot.com On Tue, Feb 11, 2014 at 7:17 PM, Troy Benjegerdes wrote: > All the 'NDA'/proprietary/confidential information that goes with chip > designs > provide plenty of cover to insert backdoors. > > GCC would be a lot harder and people would be looking for it. > > But your USB chip, graphics card, hard drive, or two factor authentication > token, on the other hand... > > The chinese are probably even copying the subverted chip designs without > even knowing it's there. > > On Tue, Feb 11, 2014 at 02:47:01PM -0700, Kelly John Rose wrote: > > I could see them more easily subverting chip designs themselves then > trying > > to subvert the entire compiler ecosystem. > > > > > > On Tue, Feb 11, 2014 at 2:05 PM, CypherPunk wrote: > > > > > > > > On 02/11/2014 01:32 PM, Rich Jones wrote: > > > > In all of the Snowden docs that have been released so far, has > anybody > > > > seen any mention of any NSA programs designed to subvert compilers? > > > > > > > > Compilers seems like an extremely prime target for manipulation, but > as > > > > far as I am aware there hasn't been anything mentioned about this > yet. > > > > Has anybody here heard anything that I haven't? > > > > > > Given that compilers are both a fairly easy to attack and amazingly > > > convenient target, it wouldn't surprise me if the NSA has subverted a > > > few specific compilers that are in common use. An attack of this nature > > > has been hypothised since the early to mid-1980's. They would have to > be > > > amazingly dense not to have at least considered it. > > > > > > On the flip side, the NSA likes to do things where it has the least > > > opportunity to be caught. Compiler subversion, while not "easy" to > catch > > > by any means, might offer too big a risk of being caught for them to do > > > it. Being that they have a multitude of weirdly named programs > > > specifically set up to compromise software, the evidence would lean > > > towards they haven't done it but I'm sure it was, at the very least, > > > discussed. > > > > > > > > > > > -- > > Kelly John Rose > > Toronto, ON > > Phone: +1 647 638-4104 > > Twitter: @kjrose > > Skype: kjrose.pr > > Gtalk: iam at kjro.se > > MSN: msn at kjro.se > > > > Document contents are confidential between original recipients and > sender. > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 4072 bytes Desc: not available URL: From sunder at sunder.net Wed Feb 12 04:26:40 2014 From: sunder at sunder.net (sunder) Date: Wed, 12 Feb 2014 07:26:40 -0500 Subject: Snowden and Compilers In-Reply-To: References: Message-ID: <52FB6880.6030702@sunder.net> On 02/11/2014 02:32 PM, Rich Jones wrote: > In all of the Snowden docs that have been released so far, has anybody > seen any mention of any NSA programs designed to subvert compilers? > > Compilers seems like an extremely prime target for manipulation, but > as far as I am aware there hasn't been anything mentioned about this > yet. Has anybody here heard anything that I haven't? My guess would be things like network card drivers, or the firmware in network cards - anything that has supervisor level access to the entire machine is a prime target, but as more NICs get things like iSCSI support/ToE and the like, have both opportunity to hide something in the onboard acceleration engines as well as a mechanism to communicate upstream. As we've seen there are plenty of "open source" linux kernel drivers for NICs and video cards that are really binaries. Plenty of room to hide stuff there, but the hardware itself is a better target, especially if the firmware they carry cannot be downloaded by the computer for forensic analysis, and especially if there's some sort of open DMA access from the device to the full memory of the machine that the OS cannot detect. Maybe they'd add stuff to tcp/udp packets as an out of band channel, or in the case of wireless stuff transmit on unused nearby frequencies that the hardware is capable of transmitting on, but cannot be detected with normal wifi/bluetooth sniffers. Bluetooth, and wifi would also be great targets because they can communicate with the outside world, or maybe the USB controllers themselves because stuff like bluetooth modules are often implemented as on-board USB devices - at least they are on Mac notebooks. On Mac notebooks, the keyboard, bluetooth controller, camera and IR receiver all run off the USB bus - so that would be a great place to sniff such traffic, and would also be able to transmit it out to nearby bugs. Even if the OS thinks the device is disabled and not in use, it could still be able to function as a sniffer/transmitter, and it's power consumption hidden in a low-power mode. If you have access to the kernel, or firmware in some critical part of a machine or the hardware itself, that's more than enough - no need to subvert the compilers. There's plenty of out of band access/theft recovery stuff in most notebooks/servers these days, and compiler generated output could always be analyzed by folks looking for vulnerabilities to exploit. Since there are only a handful of chip manufacturers, subverting those would be the path of least resistance and most gain, and companies like Dell, HP, or Apple wouldn't even have to know, nor detect the presence of such stuff. The other path is that 90% of the stuff out there runs windows, so you could always hide stuff as a worm/trojan, which we've seen with stuxnet and the like. From jya at pipeline.com Wed Feb 12 06:09:00 2014 From: jya at pipeline.com (John Young) Date: Wed, 12 Feb 2014 09:09:00 -0500 Subject: Snowden and Compilers In-Reply-To: <52FB6880.6030702@sunder.net> References: <52FB6880.6030702@sunder.net> Message-ID: Sunder posts, now this forum is getting serious. From drwho at virtadpt.net Wed Feb 12 11:46:19 2014 From: drwho at virtadpt.net (The Doctor) Date: Wed, 12 Feb 2014 11:46:19 -0800 Subject: Snowden and Compilers In-Reply-To: <52FB6880.6030702@sunder.net> References: <52FB6880.6030702@sunder.net> Message-ID: <52FBCF8B.3060707@virtadpt.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/12/2014 04:26 AM, sunder wrote: > My guess would be things like network card drivers, or the firmware > in network cards - anything that has supervisor level access to the > entire Like this? http://www.livehacking.com/tag/network-card-backdoor/ Proof of concept was been proven in 2010. Practical application is probably being done by now. Somebody is asleep behind the wheel if it is not. > As we've seen there are plenty of "open source" linux kernel > drivers for NICs and video cards that are really binaries. Plenty > of room to hide Hex-encoded blobs, if not binary blobs that show up under /lib/firmware. > stuff there, but the hardware itself is a better target, especially > if the firmware they carry cannot be downloaded by the computer > for forensic analysis, and especially if there's some sort of open > DMA access from the device to the full memory of the machine that > the OS cannot detect. Subverting hardware during design means getting lots of engineers in the private sector to shut up. That is not always easy. Spending time reversing the binaries they require (which few people do anyway) and developing a version that is subverted requires keeping the lid on fewer people, and can be done entirely in house (i.e. without telling the manufacturer). > Maybe they'd add stuff to tcp/udp packets as an out of band > channel, or Did somebody mention looking for outbound UDP packets encrypted with RC-6 or something? > in the case of wireless stuff transmit on unused nearby frequencies > that the hardware is capable of transmitting on, but cannot be > detected with normal wifi/bluetooth sniffers. That would work so long as the radio is not otherwise in use. Radio chipsets can be flipped around but it generates heat and uses up power faster. It should be more detectable than a subverted hardline. > Since there are only a handful of chip manufacturers, subverting > those would be the path of least resistance and most gain, and > companies like Until somebody that works there blabs about it. Is that a risk an intel agency would accept? Good question; my wild-assed guess is 'no, not these days'. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "Ziggy's got zip, zilch, zero." --Al -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlL7z4sACgkQO9j/K4B7F8Hx2wCg9CsrBuGsaYtHtRvOsQEO6b8T /SYAoIJXXmPpXdMfdWAsQ165Ng93ibEL =SnQe -----END PGP SIGNATURE----- From rsw at jfet.org Wed Feb 12 11:52:34 2014 From: rsw at jfet.org (Riad S. Wahby) Date: Wed, 12 Feb 2014 14:52:34 -0500 Subject: Snowden and Compilers In-Reply-To: <52FBCF8B.3060707@virtadpt.net> References: <52FB6880.6030702@sunder.net> <52FBCF8B.3060707@virtadpt.net> Message-ID: <20140212195234.GA13759@antiproton.jfet.org> The Doctor wrote: > Like this? > > http://www.livehacking.com/tag/network-card-backdoor/ > > Proof of concept was been proven in 2010. Practical application is > probably being done by now. Somebody is asleep behind the wheel if it > is not. Way before 2010. Couple buddies of mine built a backdoor into a network card circa 2003. Ditto a SCSI card, loading via the BIOS at boot and injecting itself in several stages via the bootloader into the kernel. -=rsw From bill.stewart at pobox.com Thu Feb 13 00:36:28 2014 From: bill.stewart at pobox.com (Bill Stewart) Date: Thu, 13 Feb 2014 00:36:28 -0800 Subject: Snowden and Compilers In-Reply-To: References: <52FBCF8B.3060707@virtadpt.net> Message-ID: <20140213201428.9F01910729@a-pb-sasl-quonix.pobox.com> At 06:42 PM 2/12/2014, Peter Gutmann wrote: > >http://www.livehacking.com/tag/network-card-backdoor/ > > > >Proof of concept was been proven in 2010. Practical application > is probably > >being done by now. Somebody is asleep behind the wheel if it is not. > >It was demonstrated well before then, Arrigo Triulzi had demonstrated running >an SSH server inside a NIC several years earlier. Back in the mid-80s I ran a secure computer center (with a huge VAX 11/780 :-) and the Army/DoD/NIST rules for secure computers needed to know who wrote the channel programs that the computer was using. Channels were a mainframe thing, which predated the VAX; the closest equivalent we had was a KMC11 processor that sat in the Unibus and handled interrupts and cooked-mode input for the serial cards. So yes, proofs of concept have been around for a while :-) From rysiek at hackerspace.pl Wed Feb 12 16:26:18 2014 From: rysiek at hackerspace.pl (rysiek) Date: Thu, 13 Feb 2014 01:26:18 +0100 Subject: and not a single Tor hacker was surprised... In-Reply-To: <52E00420.1090501@riseup.net> References: <4869289.mJZM0fiGMF@lap> <52E00420.1090501@riseup.net> Message-ID: <1698279.azhEInWeee@lap> Dnia środa, 22 stycznia 2014 18:47:12 katana pisze: > Hi, > > > About this. Is there a way to serve 2 (or more) certificates for a > > given HTTPS server/domain? What I would like to have is a way to: - > > serve a proper, vanilla SSL certificate bought from some provider for > > the general public accessing my service; - serve a different cert > > (for example, using MonkeySphere) for those that do not trust (and > > with good reasons) major CA's. > > > > This would have to work for the *same* domain on the *same* > > webserver. I haven't yet seen a way to do this, so this might need > > implementing, but maybe somebody here has heard about something along > > these lines? > > Like the Soveraign or TACKed keys perhaps? > d-email-more-secure> > before-theyre-accepted-by-browsers/> Thanks! -- Pozdr rysiek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: From rysiek at hackerspace.pl Wed Feb 12 16:30:51 2014 From: rysiek at hackerspace.pl (rysiek) Date: Thu, 13 Feb 2014 01:30:51 +0100 Subject: and not a single Tor hacker was surprised... In-Reply-To: References: <4869289.mJZM0fiGMF@lap> Message-ID: <2838022.ucWNFZ42RJ@lap> Hi there, Dnia czwartek, 23 stycznia 2014 00:47:48 Tom Ritter pisze: > There are a lot of things like this, but the big question is: how does the > user indicate to you which cert they want? Can't they just get both certs and accept the one that works for them? I.e. John Doe would just accept the "vanilla" SSL cert; Joe R. Hacker's browser would have these blocked, but could accept a Monkeysphere-based one. > If it was via pubca.x.com or privca.x.com - that's easy just put the > different certs in the different sites. The idea is to have the same site. > But otherwise, you have to rely on quirks. Ah, yes, quirks. ;) > TLS allows you to send different certs to different users, but this is > based off the handshake and is for algorithm agility - not cert chaining. > EG I send ECDSA signed certs if I know you can handle them, and RSA if not. Oh, this is good. Differentiating between "vanilla" certs and "advanced/really secure" Monkeysphere-based certs via ciphers is neat. Thanks for the idea! > You can also send two leaf certs, two cert chains, a cert and garbage, a > cert and a stego message - whatever. This is the closest to what you want, > but this is undefined behavior. Mhm. > Browsers may build a valid chain off the public CA, and monkeysphere off the > private* and it works perfect... Or the browser may pop an invalid cert > warning. It's undefined behavior. You'll have to test, see what happens, and > hope chrome doesn't break when it updates every week. So, sticking to the ciphersuite hack, which is elegant and bound to work. Thanks a bunch. -- Pozdr rysiek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: From 4chaos.onelove at gmail.com Thu Feb 13 03:43:13 2014 From: 4chaos.onelove at gmail.com (Henry Rivera) Date: Thu, 13 Feb 2014 06:43:13 -0500 Subject: Utopia online bazaar seized In-Reply-To: <52FC8001.7020005@owca.info> References: <52FC8001.7020005@owca.info> Message-ID: <891EEA7A-A499-4A50-8B58-09772AFC25A0@gmail.com> Since no one else has posted this yet... I see Dutch authorities got 900 btc out of this. I see no info on how the operation's security was compromised. It was a TOR site. "Police have seized Dutch online bazaar Utopia, a site similar to the infamous Silk Road for trading illegal goods, and arrested five suspects, the Dutch public prosecutor said Wednesday. Read more at: http://phys.org/news/2014-02-dutch-utopia-website-guns-drugs.html#jCp -hENRY -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 1532 bytes Desc: not available URL: From matej.kovacic at owca.info Thu Feb 13 00:19:13 2014 From: matej.kovacic at owca.info (Matej Kovacic) Date: Thu, 13 Feb 2014 09:19:13 +0100 Subject: Snowden and Compilers In-Reply-To: References: Message-ID: <52FC8001.7020005@owca.info> Hi, > It was demonstrated well before then, Arrigo Triulzi had demonstrated running > an SSH server inside a NIC several years earlier. Below is a text of interview with Triulzi, from 2009. Website where this was published has some technical problems (only slovenian version is published, but english will be recovered in a day or two). Menawhile, web.archive version is available: https://web.archive.org/web/20090929091150/http://slo-tech.com/clanki/09010/en Slovenian version (https://slo-tech.com/clanki/09010/) has a screenschoot of NIC SSH in action. ====== “All your firmware are belong to us” by Matej Kovačič :: 26. september 2009 Interview with independent security and networking consultant Arrigo Triulzi Arrigo Triulzi is an independent security and networking consultant, working out of Geneva in Switzerland. He is a mathematician by training but has been a consultant for over 20 years. His hobby is firmware research. In November 2008 he had a presentation about project Maux – his research about firmware rootkits. Since firmware rootkits and exploits are interesting area of research, we decided to make a short interview with him to present this topic to our readers. Matej Kovačič: First question – could you describe rootkits for our readers in a few words? Arrigo Triulzi: A rootkit is normally defined as a collection of tools which allow the remote control of a system. They generally consist of at least a sniffer, a password cracker and a backdoor. Matej Kovačič: What is the difference between software and hardware rootkits? Arrigo Triulzi: A software rootkit is tailored to an operating system, often a specific version of an operating system, a hardware rootkit is tailored to the hardware of a specific system and is therefore operating system independent. A reinstall of software on a system infected with a hardware rootkit has no effect on the rootkit’s operation. Matej Kovačič: Last year you had the presentation about malicious code, stored on a network card. Could you describe what is the general idea of hardware rootkits and what exactly have you done? Arrigo Triulzi: The idea behind hardware rootkits (see John Heasman's ACPI work, Jason Larson’s work on in-memory rootkits, earlier work by the Austrian TESO group and Rutkowska's recent work on AMT) is simply to have rootkits which are operating system independent and, in some cases, hardware independent. Hardware independence is given by the fact that a rootkit running in a network card works independently of where that network card is used: if it is in an IBM Power workstation, a Dell PC, a high-end switch or a MIPS-based SOHO router. As long as the NIC chip is the same then it will work. What I have done is to modify the NIC firmware in such a way that it can react to external commands and, in association with other equipment on the motherboard (the video card, specifically), provide a remote shell. This remote shell is capable of viewing the system memory from which you can extract whatever is of interest (passwords stored in clear, keyboard buffers, graphics buffers, etc.). An extension of this work is to provide a direct communications channel between two NICs thereby providing a bypass in a firewall which is totally invisible to the firewall's operating system. Matej Kovačič: How were you able to load your firmware into the card? You need some special hardware device or you can do it simply from the computer? Is there any protection, like digital signatures of new firmware? Arrigo Triulzi: Well, as all research projects it evolved from using the flash update program which came with the NIC and simply feeding it my modified firmware to using more sophisticated techniques like discovering a remote update capability. The current version simply sends the appropriate packets to vulnerable cards and updates them. Different manufacturers use different layers of protection and it is a general observation that the cheaper the NIC the worse the protection is. Quite a few high-end cards make use of digital signatures to verify that the new firmware is indeed from the manufacturer. Matej Kovačič: How hard was to develop such a code, what kind of a knowledge and equipment do you need? Arrigo Triulzi: It all started out of curiosity and took about two years of working when I had time to spare. The knowledge I built as I went along and, for the hardware, by asking my father who used to design computers. Matej Kovačič: Approximate, about how many man-hours? By your opinion, how much would need some well funded criminal organization? Arrigo Triulzi: Well, I would say that it took me approximately 500 man-hours to get to the stage of having a working “shell” (it cannot really be called a real shell as the commands are very limited). I doubt that a well-funded organization would need much more time than I needed but it should be noted that the ROI does not make the endeavour worthwhile: while the current mechanisms work (phishing, viruses, etc.) there is no point in spending time and money to go down the hardware route. Matej Kovačič: There are several producers of network cards. How many chipsets are in use? Rootkits for every branch should probably differ. How much? Would it be possible to develop generic ethernet card rootkit? Arrigo Triulzi: As I describe in my paper the marketing department is your worst enemy: there are literally thousands of variants, many of which are only ever documented in the OEM datasheets, and often little changes (deltas) in the NIC production line cause my modified firmware to fail. A perfect example: I bought two 10-pack of allegedly identical NICs (identical model numbers) and the production batches differed enough that I needed to have two separate versions. The changes were minor but it was only when I looked carefully at the main chip on the NIC that I realized that they were different revisions of the same chip. Now, can a generic NIC rootkit be developed? I don’t know, it might be possible to write a NIC rootkit which works across families in the same way that a kernel can run (at times suboptimally) on CPUs from Pentium through Core i7 but I have not really looked at it. Matej Kovačič: If you can run a custom code on a network card firmware, you have direct memory access to RAM... Arrigo Triulzi: Yes, you do, via DMA. Matej Kovačič: Which means you can easily read and write memory without CPU knowing anything about it... What are the other security impacts of this and of your research? Arrigo Triulzi: Well, the first problem is that it is invisible except for the traffic on the network side - if you want to take data out then you must pass it over the network and this means that it could be detected. On the other hand the operating system has no hope unless it has some way of comparing the current firmware with the original one. The security impacts are a simple extrapolation of the above: you can read (and write) data into any system in a way which is currently totally undetectable. Matej Kovačič: How to detect such attack? It seems software techniques are long time not enough to keep us secure... Arrigo Triulzi: The only way would be trusted computing if implemented properly and without the DRM halo which it normally carries: it would mean that the firmware on the NIC is trusted by the system and therefore any modification would be detected and prevented. There is probably no easy way to detect it in software - a simply firmware comparison could be tricked by keeping a copy of the parts which were modified on the firmware and returning those to anyone trying to download the firmware for verification. Matej Kovačič: How exactly would be possible to detect if firmare is correct? TPM chip on every device? Arrigo Triulzi: Well, if we were to implement TPM in such a way that every component of a system is verified for both security and integrity (it would be nice to know if your NIC is about to fail, independently of the security of the device). This makes the boot process complicated because you start having issues with chicken & eggs: what part of the hardware needs to be powered up and in what order? How do you execute correctly and, more importantly, securely, a WOL (wake-on-LAN) packet? If you start thinking about it you realize that it is not a trivial issue at all: if you need to process a WOL packet it means that you have to have the NIC wake up first, but then how does the TPM verify that the WOL packet has not tampered the NIC? Do you do it later in the process? But then how do you know that the NIC has not tampered with other parts of the system or, worse, is replying pretending to be other devices on the PCI bus to the TPM queries? The paranoid can head for the hills now. Matej Kovačič: What if someone installs malicious code in the factory? Arrigo Triulzi: This is obviously a nightmare – you get a pre-installed botnet with your Christmas PC purchase. It is one of the examples I always use: someone installing modified NIC firmware at Dell just before the Christmas rush, Dell ships loads of PCs and mid-January we have a gigantic botnet distributed around the planet by DHL. No chance of seeing the infection vector because it never touches the Internet until the botnet is unleashed. See it as an out-of-band infection mechanism. Matej Kovačič: How much memory does have network card? How big can be malicious firmware? Arrigo Triulzi: Very very little. This is why I had to branch out to the GPU (video card) to find memory to put my shell in. I only really use the smallest amount of RAM and firmware space on the NIC device, everything else is done via DMA on the video card. In my first paper on NIC firmware modification (presented at a closed conference) I gave the figure of approximately 5s of sniffer data being held on the device before the RAM filled up. Matej Kovačič: Have you heard of Phenoelit research of security of IOS operating system? Last year they demonstrated an interesting attack on Cisco routers – they sent one special packet through router and were able - for instance - to change firewall rules. It seems it would be possible to bypass the network filters by smuggling network card into the company, penetrate network routers from inside, get internet access to compromised ethernet card and... the sky is the limit? Arrigo Triulzi: Indeed I have read Phenoelit’s research and rather than smuggling a NIC into the company a better trick would be to take over the firewall directly: if the firewall has NICs which are vulnerable you can use something I call the “Jedi Packet Trick” to take over the external NIC, then via the PCI bus infect the internal NIC and pass packets directly between the two NICs. The name obviously comes from the Jedi Mind Trick used to bypass the Imperial Stormtroopers… Matej Kovačič: Last month we saw a malicious code could be also runned on a Mac keyboard. Joanna Rutkowska and her team had shown how vulnerable are hypervisors. Which hardware could also be exploited? Arrigo Triulzi: Well, anything with a CPU: from the service processors (IPMI, AMT, HP iLO) to SATA disks, to SCSI controllers, to video cards (these I've already done some work on), network cards, etc. Matej Kovačič: Yes, in your presentation you mentioned, you are able to connect to video cards through network card (via PCI-to-PCI transport) and run a malicious code there. This is much more powerful, because video cards have much more memory and GPU has much more computing power... Could you explain this in more detail? Arrigo Triulzi: Quite simply the NIC is not powerful enough to do much more than take packets off the wire and route them to a different location over the PCI bus. You therefore need somewhere to run more complex code and the obvious answer is (avoiding software, of course) the GPU: the current crop from both ATI and nVidia are extremely powerful and nVidia comes with a good open-source development kit. So the packets come into the NIC, they are checked to see if they are to be forwarded to the video card or are legitimate packets, they get to the video card which processes the command and sends the reply back through the same route. Matej Kovačič: We haven't seen much security research about hardware based attacks (comparative to software based attacks). Is there any security testing of a new hadrware? Arrigo Triulzi: Not really, no. At the moment hardware security rests with manufacturers. I suspect that governments will test hardware security for their more sensitive applications. Matej Kovačič: Maybe some advice what to do if you are really paranoid about security? Arrigo Triulzi: As things stand I would recommend using pen and paper... More seriously now: hardware rootkits are very sexy but hardly what is needed these days. What is the point of a sophisticated hardware rootkit when you can gain control of a user's machine by simply sending a malicious image as part of a website or a malicious attachment with an e-mail? At the moment the return on investment for hardware rootkits do not make them viable so they are simply not going to be used except where they are really needed which, in my opinion, is at the level of serious industrial espionage. So the answer is that you had better concern yourself with securing what you already use and make sure that your online behaviour is not reckless, mail programs should come with three to five layers of big red dialog boxes before they let you open an attachment of any kind... Matej Kovačič: I agree. But if you are a big company or government organization, this things can become important. And then it is only a question of trust. I mean, at the end of the day, you have to trust someone – your software, your OS, your hardware. Who do you trust? Arrigo Triulzi: As I mentioned earlier the more expensive cards do come with signed firmware. If you decide to purchase the very cheapest equipment then chances are that one of the areas the company didn’t invest in is security. If you are a government organization you often already have a source license for Windows, for example, and it is just routine for approved vendors to provide hardware specifications including the firmware update mechanism. You simply need to check that it uses signed firmware and then verify the claim. In many ways it is the usual story: “you get what you pay for”. Matej Kovačič: Thank you very much. ===== Regards, M. From odinn.cyberguerrilla at riseup.net Thu Feb 13 10:07:19 2014 From: odinn.cyberguerrilla at riseup.net (Odinn Cyberguerrilla) Date: Thu, 13 Feb 2014 10:07:19 -0800 Subject: Cryptocurrencies for Good: Revolutionizing Microdonations Message-ID: <630377d4d8dd64f55ce8330afa1d8d97.squirrel@fulvetta.riseup.net> We've launched 'Cryptocurrencies for Good: Revolutionizing Microdonations' as an indiegogo project. This currently involves myself, Filipe Farinha, and technical support from Cryptostorm. Also, there's wine. Here's our page, launched today: http://igg.me/at/microdonations-using-cryptocurrencies As the world changes, so must we! :-) From rich at openwatch.net Thu Feb 13 11:18:54 2014 From: rich at openwatch.net (Rich Jones) Date: Thu, 13 Feb 2014 11:18:54 -0800 Subject: Cryptocurrencies for Good: Revolutionizing Microdonations In-Reply-To: <630377d4d8dd64f55ce8330afa1d8d97.squirrel@fulvetta.riseup.net> References: <630377d4d8dd64f55ce8330afa1d8d97.squirrel@fulvetta.riseup.net> Message-ID: This is very ambitious! Not sure how well this will go over with the BitCoin speculation crowd, but I could see something like this being merged into the Doge mainline. It did made me think about "Cryptocurrencies for Evil".. couldn't a system like this be just as easily used to support nefarious causes as well? For instance, it is already possible to support Al-Qaeda directly via Bitcoin: http://teir4baj5mpvkg5n.onion/ *oh god please don't let me be on any more lists because of that link* R On Thu, Feb 13, 2014 at 10:07 AM, Odinn Cyberguerrilla < odinn.cyberguerrilla at riseup.net> wrote: > We've launched 'Cryptocurrencies for Good: Revolutionizing > Microdonations' as an indiegogo project. This currently involves myself, > Filipe Farinha, and technical support from Cryptostorm. > > Also, there's wine. > > Here's our page, launched today: > > http://igg.me/at/microdonations-using-cryptocurrencies > > As the world changes, so must we! > > :-) > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 1637 bytes Desc: not available URL: From rysiek at hackerspace.pl Thu Feb 13 06:26:40 2014 From: rysiek at hackerspace.pl (rysiek) Date: Thu, 13 Feb 2014 15:26:40 +0100 Subject: Utopia online bazaar seized In-Reply-To: <891EEA7A-A499-4A50-8B58-09772AFC25A0@gmail.com> References: <52FC8001.7020005@owca.info> <891EEA7A-A499-4A50-8B58-09772AFC25A0@gmail.com> Message-ID: <126577071.qqysvnvYU8@lap> Dnia czwartek, 13 lutego 2014 06:43:13 Henry Rivera pisze: > Since no one else has posted this yet... > > I see Dutch authorities got 900 btc out of this. > > I see no info on how the operation's security was compromised. It was a TOR > site. * * */2 * * grep '\.onion' /var/log/nginx/access.log Each and every large hosting provider has something along these lines in their cron somewhere (or rather, IDS rules, prolly). And damn, it has to be hosted *somewhere*, right? > "Police have seized Dutch online bazaar Utopia, a site similar to the > infamous Silk Road for trading illegal goods, and arrested five suspects, > the Dutch public prosecutor said Wednesday. > > Read more at: > http://phys.org/news/2014-02-dutch-utopia-website-guns-drugs.html#jCp -- Pozdr rysiek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: From pgut001 at cs.auckland.ac.nz Wed Feb 12 18:42:10 2014 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Thu, 13 Feb 2014 15:42:10 +1300 Subject: Snowden and Compilers In-Reply-To: <52FBCF8B.3060707@virtadpt.net> Message-ID: The Doctor writes: >Like this? > >http://www.livehacking.com/tag/network-card-backdoor/ > >Proof of concept was been proven in 2010. Practical application is probably >being done by now. Somebody is asleep behind the wheel if it is not. It was demonstrated well before then, Arrigo Triulzi had demonstrated running an SSH server inside a NIC several years earlier. Peter. From jya at pipeline.com Thu Feb 13 13:16:42 2014 From: jya at pipeline.com (John Young) Date: Thu, 13 Feb 2014 16:16:42 -0500 Subject: Snowden and Compilers In-Reply-To: <20140213201428.9F01910729@a-pb-sasl-quonix.pobox.com> References: <52FBCF8B.3060707@virtadpt.net> <20140213201428.9F01910729@a-pb-sasl-quonix.pobox.com> Message-ID: Related papers by Arrigo Triulzi @cynicalsecurity posted to Twitter today in response to this thread: Project Maux Mk.II (2008) http://t.co/h1gDtV4Vlr The Jedi Packet Trick takes over the Deathstar (2010) http://t.co/ENlITkJEoX Project Booshoo or the Emporer's Modified Mind (2011) https://t.co/33trlpJkFG ----- At 03:36 AM 2/13/2014, Bill Stewart wrote: >At 06:42 PM 2/12/2014, Peter Gutmann wrote: >> >http://www.livehacking.com/tag/network-card-backdoor/ >> > >> >Proof of concept was been proven in 2010. Practical application >> is probably >> >being done by now. Somebody is asleep behind the wheel if it is not. >> >>It was demonstrated well before then, Arrigo Triulzi had demonstrated running >>an SSH server inside a NIC several years earlier. > >Back in the mid-80s I ran a secure computer center (with a huge VAX 11/780 :-) >and the Army/DoD/NIST rules for secure computers needed to know who wrote the >channel programs that the computer was using. Channels were a >mainframe thing, >which predated the VAX; the closest equivalent we had was a KMC11 processor >that sat in the Unibus and handled interrupts and cooked-mode input >for the serial cards. > >So yes, proofs of concept have been around for a while :-) > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 1744 bytes Desc: not available URL: From cypherpunk at cpunk.us Thu Feb 13 17:20:01 2014 From: cypherpunk at cpunk.us (CypherPunk) Date: Thu, 13 Feb 2014 19:20:01 -0600 Subject: XMPP Server is Working Again! Message-ID: Hello Everyone, Just wanted to let everyone know that the XMPP server at chat.cpunk.us is again operational. I experienced problems with it and ended up having to restore it (which, unfortunately, deleted all the user accounts). Please feel free to register again using the client of your choice. Server Name: chat.cpunk.us Supports: Voice, Video, and Text chat Server Software: OpenFire Server OS: Ubuntu 12.04.4 LTS Server Location: New York Supports SSL? Yes Support Email: cypherpunk at cpunk.us Certificate: Self-signed. Fingerprint below. Certificate Fingerprint (SHA1): 327581c67147225943ff36063fb6c293e95df5d3 Certificate Fingerprint (MD5): 10e8fd94a16c911bf72dc214f4e45966 PLEASE NOTE: cpunk.us is NOT associated in any way with the Cypherpunks mailing list, its administrators, or any member of the list other than myself. As such, neither is chat.cpunk.us. This is just a public service I'm providing because I believe in privacy. Enjoy! CypherPunk From rich at openwatch.net Thu Feb 13 22:50:51 2014 From: rich at openwatch.net (Rich Jones) Date: Thu, 13 Feb 2014 22:50:51 -0800 Subject: Chaotic Times on the Dark Nets Message-ID: Rough week for the underground! Utopia has been seized by the Dutch police, BMR forums got seized by the Iranian police (anybody want to take any guesses at that one?), and now Silk Road 2.0 has been owned/possibly scammed everybody. I guess TMP will take the crown now, but for how long? I'm honestly not optimistic about the continued operation of _any_ service if Tor hidden service operators continue to operate in the manner instructed by the Tor project. There just isn't enough redundancy, servers need to be located in multiple regions simultaneously. We shall see what the future holds. R -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 699 bytes Desc: not available URL: From jya at pipeline.com Fri Feb 14 04:26:53 2014 From: jya at pipeline.com (John Young) Date: Fri, 14 Feb 2014 07:26:53 -0500 Subject: [Cryptography] Snowden Meets MacAskill, Poitras and Greenwald In-Reply-To: <6F54DE57-6804-4DDB-AB83-A65A25041FEF@lrw.com> References: <6F54DE57-6804-4DDB-AB83-A65A25041FEF@lrw.com> Message-ID: Page added. Thanks. At 07:38 PM 2/13/2014, Jerry Leichter wrote: >This one also seems to be missing a page - between "Snowden believed >that the US" and "struggled to make sense of the PRISM slides." > > -- Jerry > >On Feb 9, 2014, at 10:32 AM, John Young wrote: > > > http://cryptome.org/2014/02/snowden-meet.pdf > > > > Snowden to MacAskill, vehemently: "GCHQ is worse than NSA. It's > even more intrusive." From mjbecze at gmail.com Fri Feb 14 06:34:28 2014 From: mjbecze at gmail.com (Martin Becze) Date: Fri, 14 Feb 2014 09:34:28 -0500 Subject: Chaotic Times on the Dark Nets In-Reply-To: <52FDEE03.8000800@headstrong.de> References: <52FDE65B.1080408@headstrong.de> <52FDEE03.8000800@headstrong.de> Message-ID: Decentralized hosting/computing would be nice and solve these issues. On Fri, Feb 14, 2014 at 5:20 AM, Moritz wrote: > On 02/14/2014 10:48 AM, Moritz wrote: > > I guess all in all, with these sites, it is more about classic police > > work: follow the stream of money. > > A concrete, may-or-may not be story: > > I run a site, it funds itself with Bitcoin. I use hosting providers that > allow Bitcoin. Wow, the infrastructure pays for itself. Happyface. > > You follow the stream of money, identify the hoster. Hoster willingly > cooperates, or you spoof mails to me. I will eventually hit one of the > embedded web bugs, images, or click a link that opens in a non-Tor > browser, or open your next "PDF invoice". Oops. > > --mo > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 1179 bytes Desc: not available URL: From moritz at headstrong.de Fri Feb 14 01:48:11 2014 From: moritz at headstrong.de (Moritz) Date: Fri, 14 Feb 2014 10:48:11 +0100 Subject: Chaotic Times on the Dark Nets In-Reply-To: References: Message-ID: <52FDE65B.1080408@headstrong.de> On 02/14/2014 07:50 AM, Rich Jones wrote: > Rough week for the underground! I honestly don't understand. Everybody knows is not hard to rent servers anonymously. And I'm not talking Bitcoin. I guess all in all, with these sites, it is more about classic police work: follow the stream of money. --mo From s at ctrlc.hu Fri Feb 14 01:52:03 2014 From: s at ctrlc.hu (stef) Date: Fri, 14 Feb 2014 10:52:03 +0100 Subject: consistent pcp/pbp formats In-Reply-To: <20140206192412.GC20154@r4> References: <20140115093443.GE3900@r4> <20140115134145.GF3900@r4> <20140120133104.GL3900@r4> <20140204150729.GB62910@r4> <20140205125110.GE62910@r4> <20140206192412.GC20154@r4> Message-ID: <20140214095203.GB7128@ctrlc.hu> On Thu, Feb 06, 2014 at 08:24:12PM +0100, Thomas von Dein wrote: > So, here we go: > > # bob exports his pk > bobby at io: % pbp -x -S Bob > bob.pbp > Passphrase for decrypting master key for Bob: > > # alice exports her pk > alicia at io: % pcp -p -b -O alice.pbp > Enter passphrase to decrypt your secret key for signing the export: > public key exported in PBP format. > > # bob imports alice' pk > bobby at io: % pbp -X -i alice.pbp > Success: imported public keys for Alicia > > bobby at io: % pbp -l > valid b888 026a 38e2 cdf7 f0a6 6486 63a5 0fea Bob > invalid ed32 1935 0310 fe6f 35c6 b44d be6b 3ca8 Alicia [1] > > > # alice imports bobs pk > alicia at io: % pcp -P -I bob.pbp -b > key 0x87358A0988953A67 added to ~/.pcpvault. > > alicia at io: % pcp -l > Key ID Type Creation Time Owner > 0xB497AFF45654CD98 primary 2014-02-06T19:58:09 Alicia <> > 0x87358A0988953A67 public 2014-02-06T18:58:02 bob <> > > # bob encrypts to alice > bobby at io: % echo "HALLO ALICE, KNUTSCHI" > msg > bobby at io: % pbp -c -i msg -o encrypted -r Alicia -S Bob > Passphrase for decrypting encryption subkey for Bob: > > # alice decrypts it > alicia at io: % pcp -d -I encrypted > Enter passphrase to decrypt your secret key: > HALLO ALICE, KNUTSCHI > Decrypted 22 bytes successfully > > # other way around, alice encrypts to bob > alicia at io: % echo "ACH, SCHNUCKI" | pcp -e -O encrypted -r Bob > Enter passphrase to decrypt your secret key: > Encrypted 164 bytes for: > bob <> > > # and bob decrypts it > bobby at io: % pbp -d -i encrypted -S Bob > Passphrase for decrypting encryption subkey for Bob: > ACH, SCHNUCKI > good message from Alicia fuck yeah! ;) > [1]: currently pbp shows pcp keys as "invalid", I'm not sure why, > but it's on the todo list. ooh, thx, will check that! > Also, I didn't test if signatures are compatible yet, and there are many > more things left to solve/agree, like keyformats, sign+crypt support in > pbp, among others. sign+crypt? why? crypt also does mac automatically. no need for sign+crypt at all. -- pgp: https://www.ctrlc.hu/~stef/stef.gpg pgp fp: FD52 DABD 5224 7F9C 63C6 3C12 FC97 D29F CA05 57EF otr fp: https://www.ctrlc.hu/~stef/otr.txt From guido at witmond.nl Fri Feb 14 02:13:55 2014 From: guido at witmond.nl (Guido Witmond) Date: Fri, 14 Feb 2014 11:13:55 +0100 Subject: XMPP Server is Working Again! In-Reply-To: References: Message-ID: <52FDEC63.9060404@witmond.nl> On 02/14/14 02:20, CypherPunk wrote: > Hello Everyone, > > Just wanted to let everyone know that the XMPP server at chat.cpunk.us > is again operational. I experienced problems with it and ended up having > to restore it (which, unfortunately, deleted all the user accounts). > Please feel free to register again using the client of your choice. > > Server Name: chat.cpunk.us > Supports: Voice, Video, and Text chat > Server Software: OpenFire > Server OS: Ubuntu 12.04.4 LTS > Server Location: New York > Supports SSL? Yes > Support Email: cypherpunk at cpunk.us > > Certificate: Self-signed. Fingerprint below. > Certificate Fingerprint (SHA1): 327581c67147225943ff36063fb6c293e95df5d3 > Certificate Fingerprint (MD5): 10e8fd94a16c911bf72dc214f4e45966 Hi CypherPunk, Thanks for running this service, the world really needs more decentralised services. However, as your server is using a DNS name, have you considered publishing the certificate (or its hash) in DNSSEC-DANE records? It would give me a second avenue of verifying your certificate. This mail being the first. Regard, Guido. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From moritz at headstrong.de Fri Feb 14 02:20:51 2014 From: moritz at headstrong.de (Moritz) Date: Fri, 14 Feb 2014 11:20:51 +0100 Subject: Chaotic Times on the Dark Nets In-Reply-To: <52FDE65B.1080408@headstrong.de> References: <52FDE65B.1080408@headstrong.de> Message-ID: <52FDEE03.8000800@headstrong.de> On 02/14/2014 10:48 AM, Moritz wrote: > I guess all in all, with these sites, it is more about classic police > work: follow the stream of money. A concrete, may-or-may not be story: I run a site, it funds itself with Bitcoin. I use hosting providers that allow Bitcoin. Wow, the infrastructure pays for itself. Happyface. You follow the stream of money, identify the hoster. Hoster willingly cooperates, or you spoof mails to me. I will eventually hit one of the embedded web bugs, images, or click a link that opens in a non-Tor browser, or open your next "PDF invoice". Oops. --mo From hettinga at gmail.com Fri Feb 14 08:39:49 2014 From: hettinga at gmail.com (Robert Hettinga) Date: Fri, 14 Feb 2014 12:39:49 -0400 Subject: Chaotic Times on the Dark Nets In-Reply-To: References: <52FDE65B.1080408@headstrong.de> <52FDEE03.8000800@headstrong.de> Message-ID: <5716D7E0-8D76-4CF5-817E-B14683F0720C@gmail.com> On Feb 14, 2014, at 10:34 AM, Martin Becze wrote: > Decentralized hosting/computing would be nice and solve these issues. Need bearer cash for that. :-) Cheers, RAH -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From iam at kjro.se Fri Feb 14 12:32:54 2014 From: iam at kjro.se (Kelly John Rose) Date: Fri, 14 Feb 2014 13:32:54 -0700 Subject: Chaotic Times on the Dark Nets In-Reply-To: References: <52FDE65B.1080408@headstrong.de> <52FDEE03.8000800@headstrong.de> Message-ID: Would tahoefs work to enable that? Has anyone tried? -- Kelly John Rose Toronto, ON Phone: +1 647 638-4104 Twitter: @kjrose Skype: kjrose.pr Gtalk: iam at kjro.se MSN: msn at kjro.se Document contents are confidential between original recipients and sender. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 529 bytes Desc: not available URL: From dan at geer.org Fri Feb 14 10:37:24 2014 From: dan at geer.org (dan at geer.org) Date: Fri, 14 Feb 2014 13:37:24 -0500 Subject: Inferring the NSA's MO from a short clip of Joel Brenner on BBC In-Reply-To: Your message of "Mon, 03 Feb 2014 10:46:13 EST." Message-ID: <20140214183724.5F6C42280CC@palinka.tinho.net> Jen, I don't see anyone answering, so I will try a bit with the disclaimer, if one need be given, that Joel Brenner is a friend of mine. His book, _America the Vulnerable_ is worth reading, and his blog entry on the subject you are raising, an entry crossposted on Lawfare, is germane to this discussion. See http://joelbrenner.com/n-s-a-not-so-secret-anymore/ If I may synthesize from the material you posted, in the digital world we are growing the attack surface faster than we can grow our defensive capacity. That being the fundamental dynamic, there are, as both you and Joel imply, a set of choices that might be properly called Hobbesian. Hobbes himself argued that "the only way to secure civil society is through universal submission to the absolute authority of a sovereign." What Hobbes could not envision is a sovereign that was a machine. I'm on the record in proposing to deliver a shock to the entire system of software vendors by using the Treasury of the United States to simply corner the world market in vulnerabilities and exploits and to concommitantly release them to the public -- the moral equivalent of administering an unproven chemotherapy for an otherwise terminal cancer. That proposal originally appeared in an article that I did for CNAS (www.cnas.org/cyber) but my presumption is that there will always be ready buyers (which there are), so the question is whether the buying and selling is to be a black market or a white. In truth, I was focusing on a side effect of the USG having an unassailable presence in a white market -- that there is some chance that we could collapse the black market, not by outbidding it but by implying that we had motivated the finding of vulnerabilities to such a level that even if one searcher was able to find a vulnerability it would not be long before some other searcher found it, too. By cutting the shelf-life of an unused but known vulnerability down to near zero, we would cripple the stockpiling of weapons. All of which, to repeat, comes with my ironclad requirement that vulns found be made public. Otherwise, and as one would certainly imagine, buying a lot of them at high prices only makes more get found such that in a black-only market those vulns will presumaby be both sold and re-sold to self-compartmentalized buyers. ["We" learned only this past week that the FBI is now buying for offensive purposes (www.securityweek.com/fbi-looking-buy-malware-security-vendors).] I am also on the record that Stuxnet was a Godsend insofar as it proved by demonstration that mutual assured destruction is possible, though one must quickly acknowledge that, unlike a missile with the Kremlin's name on it, cyberweapons with understood-in-advance collateral damage do not grow on trees. (Website on which it originally appeared has disappeared; a mirror is at geer.tinho.net/geer.dsbox.18xi10.txt) In October, 2012, I spoke with a recently retired gentleman who had been at the top of NSA's threat evaluation wing. I asked him then what he would be worrying about if he were still on the job. He said "Today I'd be worrying about the maker community and especially the drone crowd. Tomorrow I'd worry about do-it-yourself bio." These are by no means crazy answers. All of which comes back to your Home Invasion 2.0 work (I broke discipline and turned on Javascript just to get it). There is an enormous attack surface growing there, just as you say. Electric meters that report back everything are quintessential privacy destroying even if they are being mandated for "green" reasons. And so forth -- I'll restrain myself from enumerating all the things of that sort, though a cpunks dictionary of such would be an useful thing jointly to build. Which brings us back to the NSA. Their job description is to never miss a needle in any haystack. Haystacks are bigger than ever, and those who control the needles are ever more powerful -- both being side effects of the growth in power that is buried in cyberspace. If you are obliged to miss nothing while the cardinality of the things you might miss is growing at an accelerating rate, your only choice is to capture everything. Only when you have total surveillance is it possible to say that the absence of evidence is the evidence of absence. What "we" need to do is tell our leaders that we do not want their protections, that we will bloody well take care of ourselves even if down that path lies the occasional loss of a major city. One is again reminded of Dostoyevsky's Grand Inquisitor, is one not? --dan From iam at kjro.se Fri Feb 14 12:54:23 2014 From: iam at kjro.se (Kelly John Rose) Date: Fri, 14 Feb 2014 13:54:23 -0700 Subject: Chaotic Times on the Dark Nets In-Reply-To: References: <52FDE65B.1080408@headstrong.de> <52FDEE03.8000800@headstrong.de> Message-ID: Would tahoefs work to enable that? Has anyone tried? -- Kelly John Rose Toronto, ON Phone: +1 647 638-4104 Twitter: @kjrose Skype: kjrose.pr Gtalk: iam at kjro.se MSN: msn at kjro.se Document contents are confidential between original recipients and sender. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 529 bytes Desc: not available URL: From carimachet at gmail.com Fri Feb 14 07:05:52 2014 From: carimachet at gmail.com (Cari Machet) Date: Fri, 14 Feb 2014 15:05:52 +0000 Subject: Chaotic Times on the Dark Nets In-Reply-To: References: <52FDE65B.1080408@headstrong.de> <52FDEE03.8000800@headstrong.de> Message-ID: decentralized everything.... with rugged systems of laws around data protection solution yes to a degree but nothing is a guarantee... they swim around laws they no likey we need all kinds of solutions in every sector to shift out of this mass capital eating everything societal mindset On Fri, Feb 14, 2014 at 2:34 PM, Martin Becze wrote: > Decentralized hosting/computing would be nice and solve these issues. > > > On Fri, Feb 14, 2014 at 5:20 AM, Moritz wrote: > >> On 02/14/2014 10:48 AM, Moritz wrote: >> > I guess all in all, with these sites, it is more about classic police >> > work: follow the stream of money. >> >> A concrete, may-or-may not be story: >> >> I run a site, it funds itself with Bitcoin. I use hosting providers that >> allow Bitcoin. Wow, the infrastructure pays for itself. Happyface. >> >> You follow the stream of money, identify the hoster. Hoster willingly >> cooperates, or you spoof mails to me. I will eventually hit one of the >> embedded web bugs, images, or click a link that opens in a non-Tor >> browser, or open your next "PDF invoice". Oops. >> >> --mo >> > > -- Cari Machet NYC 646-436-7795 carimachet at gmail.com AIM carismachet Syria +963-099 277 3243 Amman +962 077 636 9407 Berlin +49 152 11779219 Reykjavik +354 894 8650 Twitter: @carimachet 7035 690E 5E47 41D4 B0E5 B3D1 AF90 49D6 BE09 2187 Ruh-roh, this is now necessary: This email is intended only for the addressee(s) and may contain confidential information. If you are not the intended recipient, you are hereby notified that any use of this information, dissemination, distribution, or copying of this email without permission is strictly prohibited. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 2749 bytes Desc: not available URL: From cathalgarvey at cathalgarvey.me Fri Feb 14 13:14:58 2014 From: cathalgarvey at cathalgarvey.me (Cathal Garvey) Date: Fri, 14 Feb 2014 21:14:58 +0000 Subject: Chaotic Times on the Dark Nets In-Reply-To: References: <52FDE65B.1080408@headstrong.de> <52FDEE03.8000800@headstrong.de> Message-ID: <52FE8752.3070006@cathalgarvey.me> Yes, apparently it's in use over i2p using a bunch of plugins but I've never bothered setting it up to explore. They call it the "deepnet", I think. On 14/02/14 20:54, Kelly John Rose wrote: > Would tahoefs work to enable that? Has anyone tried? > > -- Please help support my crowdfunding campaign, IndieBB: Currently at 23.1% of funding goal, with 27 days left: http://igg.me/at/yourfirstgmo/x/4252296 T: @onetruecathal, @IndieBBDNA P: +3538763663185 W: http://indiebiotech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x988B9099.asc Type: application/pgp-keys Size: 6176 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From jamesdbell9 at yahoo.com Fri Feb 14 23:04:43 2014 From: jamesdbell9 at yahoo.com (jim bell) Date: Fri, 14 Feb 2014 23:04:43 -0800 (PST) Subject: Utopia online bazaar seized In-Reply-To: <891EEA7A-A499-4A50-8B58-09772AFC25A0@gmail.com> References: <52FC8001.7020005@owca.info> <891EEA7A-A499-4A50-8B58-09772AFC25A0@gmail.com> Message-ID: <1392447883.72558.YahooMailNeo@web126203.mail.ne1.yahoo.com> From: Henry Rivera <4chaos.onelove at gmail.com> To: "cypherpunks at cpunks.org"   >I see Dutch authorities got 900 btc out of this.  >I see no info on how the operation's security was compromised. It was a TOR site.  >"Police have seized Dutch online bazaar Utopia, a site similar to the infamous Silk Road for trading illegal goods, and arrested five suspects, the> >Dutch public prosecutor said Wednesday. >Read more at: http://phys.org/news/2014-02-dutch-utopia-website-guns-drugs.html#jCp >hENRY At some point, hopefully quite soon, people will see the futility of running a "Silk-Road-type" site, without equipping it with some form of proactive security, perhaps 'AP' or Sanjuro's 'Assassination Market'.   As stated by the character "Dr. Strangelove", in the movie of the same name,    "Deterrence is the art of producing in the mind of the enemy... the FEAR to attack."             Jim Bell (from:   http://www.imdb.com/character/ch0032594/quotes   )   [discussing the Doomsday machine]  President Merkin Muffley: How is it possible for this thing to be triggered automatically and at the same time impossible to untrigger?  Dr. Strangelove: Mr. President, it is not only possible, it is essential. That is the whole idea of this machine, you know. Deterrence is the art of producing in the mind of the enemy... the FEAR to attack. And so, because of the automated and irrevocable decision-making process which rules out human meddling, the Doomsday machine is terrifying and simple to understand... and completely credible and convincing.  -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 5152 bytes Desc: not available URL: From rich at openwatch.net Sat Feb 15 16:46:21 2014 From: rich at openwatch.net (Rich Jones) Date: Sat, 15 Feb 2014 16:46:21 -0800 Subject: Chaotic Times on the Dark Nets In-Reply-To: <52FE8752.3070006@cathalgarvey.me> References: <52FDE65B.1080408@headstrong.de> <52FDEE03.8000800@headstrong.de> <52FE8752.3070006@cathalgarvey.me> Message-ID: That's the kind of thinking I like! Something like this? [ alpha.onion ] \ [ beta.onion ] ----- [ [ tahoe1] [ tahoe2 ] .. [ tahoeN ] ] [ charlie.onion ] / Not sure if the entry points should also host Tahoe instances or if they should just be gateways. Super redundant, though! I guess the Tahoe <-> Tahoe connections would also have to be Torified as well though, otherwise if one got compromised then the rest would be exposed as well. R On Fri, Feb 14, 2014 at 1:14 PM, Cathal Garvey wrote: > Yes, apparently it's in use over i2p using a bunch of plugins but I've > never bothered setting it up to explore. They call it the "deepnet", I > think. > > On 14/02/14 20:54, Kelly John Rose wrote: > > Would tahoefs work to enable that? Has anyone tried? > > > > > > -- > Please help support my crowdfunding campaign, IndieBB: Currently at > 23.1% of funding goal, with 27 days left: > http://igg.me/at/yourfirstgmo/x/4252296 > T: @onetruecathal, @IndieBBDNA > P: +3538763663185 > W: http://indiebiotech.com > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 1942 bytes Desc: not available URL: From dan at geer.org Sat Feb 15 18:48:19 2014 From: dan at geer.org (dan at geer.org) Date: Sat, 15 Feb 2014 21:48:19 -0500 Subject: Snowden and Compilers In-Reply-To: Your message of "Tue, 11 Feb 2014 17:51:33 PST." Message-ID: <20140216024819.71B212280D1@palinka.tinho.net> | > GCC would be a lot harder and people would be looking for it. | | GCC yes, but what about Visual Studio? The LLVM which ships with XCode? | Javac? | | Those are much jucier targets than say, Debian's GCC. If I worked at the | NSA, I'd make backdooring Visual Studio my 20% project. | | If anybody with Snowden cache access who is reading this could do me a | quick favor and grep for 'compiler,' and then publish the output, I'd | really appreciate it. History says that Microsoft's problems with BSOD were dominated by third party device drivers -- supposedly 85% of all XP BSODs. And they are all are blobs. --dan From dan at geer.org Sat Feb 15 19:03:55 2014 From: dan at geer.org (dan at geer.org) Date: Sat, 15 Feb 2014 22:03:55 -0500 Subject: Snowden and Compilers In-Reply-To: Your message of "Wed, 12 Feb 2014 14:52:34 EST." <20140212195234.GA13759@antiproton.jfet.org> Message-ID: <20140216030355.E23EC2280D1@palinka.tinho.net> > Way before 2010. Couple buddies of mine built a backdoor into a network > card circa 2003. Ditto a SCSI card, loading via the BIOS at boot and > injecting itself in several stages via the bootloader into the kernel. So, to get down to brass tacks: If I can get to the chip mask pre lithography, how many gates do I need? A thousand for a kill switch and three thousand for a connection? --dan From l at odewijk.nl Sun Feb 16 05:44:58 2014 From: l at odewijk.nl (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?=) Date: Sun, 16 Feb 2014 14:44:58 +0100 Subject: Snowden and Compilers In-Reply-To: <20140216030355.E23EC2280D1@palinka.tinho.net> References: <20140212195234.GA13759@antiproton.jfet.org> <20140216030355.E23EC2280D1@palinka.tinho.net> Message-ID: 2014-02-16 4:03 GMT+01:00 : > So, to get down to brass tacks: If I can get to the chip mask pre > lithography, how many gates do I need? A thousand for a kill switch > and three thousand for a connection? > You can also manipulate other parts of the machine. With features present in vPro all that's needed is a "buffer overflow" hidden "bug" that allows remote control. The "bug" might even be hidden in non-spec gates or code flashed into it later. Bottom line: no defense when you use vPro capable Intel chipsets. This is a massive problem for me as someone who'd like to produce a secure system. If the NSA can remote enable vPro anytime they like, what am I going to do at any other level? There's plenty of tricks you can pull to make it seem they didn't use vPro, as vPro usage is pretty much undetectable. Think manipulation of random number generation making it seem they have some unknown random number generator attack, when in fact they just manipulated it. So large is our current closed source trouble. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 1609 bytes Desc: not available URL: From bill.stewart at pobox.com Sun Feb 16 19:12:17 2014 From: bill.stewart at pobox.com (Bill Stewart) Date: Sun, 16 Feb 2014 19:12:17 -0800 Subject: Chaotic Times on the Dark Nets In-Reply-To: <5716D7E0-8D76-4CF5-817E-B14683F0720C@gmail.com> References: <52FDE65B.1080408@headstrong.de> <52FDEE03.8000800@headstrong.de> <5716D7E0-8D76-4CF5-817E-B14683F0720C@gmail.com> Message-ID: <20140217031233.85B4FFF69@a-pb-sasl-quonix.pobox.com> At 08:39 AM 2/14/2014, Robert Hettinga wrote: >On Feb 14, 2014, at 10:34 AM, Martin Becze wrote: > > Decentralized hosting/computing would be nice and solve these issues. >Need bearer cash for that. :-) Not really - Bitcoin's sort of close enough to bearer cash for paying for hosting, but the scenario we've been looking at was - Hosting accepts bitcoins (or bearer cache or whatever.) - Narcs harass hosting provider in lieu of actual operator - Hosting provider rolls over, lets narcs bug the system and/or hosting provider's billing system - Bugged system hands the operator a bugged PDF along with the bill, or some similar trap Even a hosting provider who accepts digital bearer cash and gets paid in advance is going to do billing. I'm a bit skeptical about how you do distributed hosting adequately here, though perhaps Tahoe with enough users would work. Obfuscating the location of the hosting is easier, but somewhat-distributed hosting is going to just mean that there are a bunch of hosting providers, each of which accepts some kind of bearer payment and has some level of willingness to narc on users. Maybe 90% of the providers won't narc on their users, but that means you need to be safe against the other 10%. From hettinga at gmail.com Mon Feb 17 10:01:13 2014 From: hettinga at gmail.com (Robert Hettinga) Date: Mon, 17 Feb 2014 14:01:13 -0400 Subject: Get offa my lawn. (was Re: [Cryptography] BitCoin bug reported) In-Reply-To: <530176B7.7060806@cypherpunks.to> References: <1392439997.28632.36.camel@excessive.dsl.static.sonic.net> <530075C2.1000605@iang.org> <20140216131837.GE31133@thunk.org> <53013EAC.70508@iang.org> <530176B7.7060806@cypherpunks.to> Message-ID: <92747E0D-32A0-4167-A770-D089F277DB87@gmail.com> On Feb 16, 2014, at 10:40 PM, Lucky Green wrote: > I say, let them and all of Bitcoin burn to dust. Dang kids. Get offa my lawn. It’s been interesting, I’ll say that much. I have people on their honeymoon here in .ai asking to see me, buy me and Mrs. RAH $30 hamburgers at Viceroy, etc. Or “prove”, “stylometrically", on various Bitcoin fora, that I'm Satoshi. Heh. I’ll never get tired of braggin’ about *that* one. :-) I expect others here know where the stylistic clues came from, but I think Grigg has the right approach to that question. Leave well enough alone. Being, even now, generally optimistic about the future, if not my own in particular, I can’t help thinking there’s a pony in there somewhere. I *do* find it annoying that the only time people wanna talk to me about this stuff is at the top of a bubble. I expect that it may be a hint from the Almighty I should pay attention to. At the moment, PayPal, which we all looked down the nose at back then, is still, um, printing money, and a cypherpunk gave me some BTC a little while ago, a kind of eating-the-dog food exercise for old time’s sake. Or something. The price has since fallen 40%, but it’s bouncing back, and will probably be fine. “You have to be *this* tall to take this ride”, as another friend said about Bitcoin prices last week. Meanwhile I can’t think of anything I want to spend it on anyway. Even in its current form, Bitcoin makes rather short work of those speed bumps Mr. May used to tell us about, which *may* be the real point to the exercise. Having to file several kinds of forms to get paid for a small consulting job as US citizen outside the US was enough to make me foreswear getting paid for much of anything anymore, anything small at least, and BTC solves several problems there quite handily, push ever came to shove. Besides, my passport is stamped “Employment Prohibited”, which, apparently, I’m evidently honoring even in the breach. So, I think BTC, or something like it, would make a nice numeraire, temporary or otherwise, having gnawed at the edges of *that* problem when most of the Bitcoinners were, as Marc notes, in short-pants. Yes, even in its current volatile state. And contrary to the opinions of people who know better than I do about these things. It wasn't quite what Dr. Fama got the Nobel for, but New Monetary Economics might be as good once as it ever was, and Bitcoin might be the camel’s nose under that particular tent, and given that it is the ultimate fiat currency that’s quite an assertion. As someone whose stated goal, back in the day, was to securitize *everything*, debt, equity, cash, services, title to assets in storage, transit, or just sitting there with a house on it, cats, dogs, mass hysteria -- and all derivatives thereof -- using bearer-transaction financial cryptography protocols on a ubiquitous geodesic public internetwork, Bitcoin *is* a bit, oh, please let me say it, self-referent as a solution. I saw it blow by here on this list, said, “meh”, shortly had the magic smoke go out of most of my internet presence by a power-spike in a hurricane, and never got around to paying attention to either Bitcoin, or the internet, very much at all until various people frog-marched my attention back into focus recently with me muttering variously about being too old for this shit anymore... So, Bitcoin, if it survives, makes a *nice* hack, by solving, what Barnes, and ultimately everyone else, called the “loading problem”. And, so far at least, it solves the “and then you go to jail” part of the book-entry transaction error-handler, something Barnes was also noted for saying. That, too, only if Bitcoin survives. "...any [network] architecture that can survive a nuclear attack can survive withdrawal of government subsidy...” Godwin said on Cyberia, long ago. I’ve jokingly called it his Second Law. I suppose the Strong Form of that hypothesis, speaking of Dr. Fama, is surviving not mere withdrawal of the implicit subsidy of monopolistic contract enforcement, and all transfer-priced assets and “externalities” appertaining thereto, but also active attack from the ostensible contract enforcer itself. I hear of others, well, gnawing around the edges, actually, of securitizing other stuff with variants of the Bitcoin protocol, but, like predicting the end of the world, expanding the blockchain to other assets "has not been found agreeable to experience.” So far as I can see. Meanwhile, Chris Odom, aka, “Fellow Traveller”, aka, “Lovedrop” (yes, *that* “Lovedrop”), is banging away on something called Open Transactions, which inserts an actual transaction protocol, among other much more interesting things, into the works to glue Bitcoin and other stuff onto, for starters, Wagner Blinding, using, for starters, Ben Laurie’s lucre code. I haven’t seen a code-stoke like the one I see Chris with, well, since the old days. Which is nice. Very nice. Big grins all around, down here in the elbow of the Caribbean. Apparently, like me, he noticed that he was delivering instantly-usable product now, and getting paid later, too much later usually. I discovered cypherpunks in late spring of 1994 looking for a solution to something Barnes (again) called the “latency” problem. Chriss bumped into the gold-silver-crypto list, I think, about 10 years later. Mr. Odom has been been kind enough to involve me in testing OT a bit, and, ultimately, I’ve more-or-less bailed on iterative break-it-and-fix-it. Mostly because I don’t have the patience for testing — much less writing — code, if I ever really did. But here’s the rub, I also I have no *idea* what I, personally, would do with Open Transactions these days even if I could get it running in production. I have lots of ideas in *general*, you understand, but they’re mostly of the “let’s you and him fight” variety. Many more people than *I* would have to be involved, they, and I, would risk much more than money, and, ultimately, I’m not sure any of it would work. It’s a drag to think that most of what I’m interested in doing requires the dissolution, or at least dissipation, of The World’s Only Remaining Superpower to happen. As someone who still, barely, calls himself mostly an anarcho-capitalist but still a patriot, that’s about the only thing worse than only being interesting to other people during the top of a bubble. Yup. A Mass of Contradictions, as usual. "Let’s you and him fight" is only two or three steps removed from Mr. Briceno’s original observation, I figure. Hell, even “set here next to the rockin' chair, sonny, and I’ll tell ya a story”, is, ultimately, not much more help than “get off my lawn”, when you get right down to it... Cheers, RAH -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hettinga at gmail.com Mon Feb 17 10:56:07 2014 From: hettinga at gmail.com (Robert Hettinga) Date: Mon, 17 Feb 2014 14:56:07 -0400 Subject: Fwd: [Cryptography] Get offa my lawn. (was Re: BitCoin bug reported) References: <92747E0D-32A0-4167-A770-D089F277DB87@gmail.com> Message-ID: <2C454B95-CCE1-43BE-B50C-4556B8ADE398@gmail.com> Begin forwarded message: > From: Robert Hettinga > Subject: [Cryptography] Get offa my lawn. (was Re: BitCoin bug reported) > Date: February 17, 2014 at 2:01:13 PM AST > To: Cryptography List > Cc: cpunks , Robert Hettinga > > > On Feb 16, 2014, at 10:40 PM, Lucky Green wrote: > >> I say, let them and all of Bitcoin burn to dust. > > Dang kids. Get offa my lawn. > > > It’s been interesting, I’ll say that much. I have people on their honeymoon here in .ai asking to see me, buy me and Mrs. RAH $30 hamburgers at Viceroy, etc. > > Or “prove”, “stylometrically", on various Bitcoin fora, that I'm Satoshi. Heh. I’ll never get tired of braggin’ about *that* one. :-) I expect others here know where the stylistic clues came from, but I think Grigg has the right approach to that question. Leave well enough alone. > > > Being, even now, generally optimistic about the future, if not my own in particular, I can’t help thinking there’s a pony in there somewhere. I *do* find it annoying that the only time people wanna talk to me about this stuff is at the top of a bubble. I expect that it may be a hint from the Almighty I should pay attention to. > > > At the moment, PayPal, which we all looked down the nose at back then, is still, um, printing money, and a cypherpunk gave me some BTC a little while ago, a kind of eating-the-dog food exercise for old time’s sake. Or something. The price has since fallen 40%, but it’s bouncing back, and will probably be fine. “You have to be *this* tall to take this ride”, as another friend said about Bitcoin prices last week. Meanwhile I can’t think of anything I want to spend it on anyway. > > Even in its current form, Bitcoin makes rather short work of those speed bumps Mr. May used to tell us about, which *may* be the real point to the exercise. > > Having to file several kinds of forms to get paid for a small consulting job as US citizen outside the US was enough to make me foreswear getting paid for much of anything anymore, anything small at least, and BTC solves several problems there quite handily, push ever came to shove. Besides, my passport is stamped “Employment Prohibited”, which, apparently, I’m evidently honoring even in the breach. > > > So, I think BTC, or something like it, would make a nice numeraire, temporary or otherwise, having gnawed at the edges of *that* problem when most of the Bitcoinners were, as Marc notes, in short-pants. Yes, even in its current volatile state. And contrary to the opinions of people who know better than I do about these things. > > > It wasn't quite what Dr. Fama got the Nobel for, but New Monetary Economics might be as good once as it ever was, and Bitcoin might be the camel’s nose under that particular tent, and given that it is the ultimate fiat currency that’s quite an assertion. > > As someone whose stated goal, back in the day, was to securitize *everything*, debt, equity, cash, services, title to assets in storage, transit, or just sitting there with a house on it, cats, dogs, mass hysteria -- and all derivatives thereof -- using bearer-transaction financial cryptography protocols on a ubiquitous geodesic public internetwork, Bitcoin *is* a bit, oh, please let me say it, self-referent as a solution. I saw it blow by here on this list, said, “meh”, shortly had the magic smoke go out of most of my internet presence by a power-spike in a hurricane, and never got around to paying attention to either Bitcoin, or the internet, very much at all until various people frog-marched my attention back into focus recently with me muttering variously about being too old for this shit anymore... > > > So, Bitcoin, if it survives, makes a *nice* hack, by solving, what Barnes, and ultimately everyone else, called the “loading problem”. And, so far at least, it solves the “and then you go to jail” part of the book-entry transaction error-handler, something Barnes was also noted for saying. That, too, only if Bitcoin survives. > > "...any [network] architecture that can survive a nuclear attack can survive withdrawal of government subsidy...” Godwin said on Cyberia, long ago. I’ve jokingly called it his Second Law. I suppose the Strong Form of that hypothesis, speaking of Dr. Fama, is surviving not mere withdrawal of the implicit subsidy of monopolistic contract enforcement, and all transfer-priced assets and “externalities” appertaining thereto, but also active attack from the ostensible contract enforcer itself. > > > I hear of others, well, gnawing around the edges, actually, of securitizing other stuff with variants of the Bitcoin protocol, but, like predicting the end of the world, expanding the blockchain to other assets "has not been found agreeable to experience.” So far as I can see. > > Meanwhile, Chris Odom, aka, “Fellow Traveller”, aka, “Lovedrop” (yes, *that* “Lovedrop”), is banging away on something called Open Transactions, which inserts an actual transaction protocol, among other much more interesting things, into the works to glue Bitcoin and other stuff onto, for starters, Wagner Blinding, using, for starters, Ben Laurie’s lucre code. I haven’t seen a code-stoke like the one I see Chris with, well, since the old days. Which is nice. Very nice. Big grins all around, down here in the elbow of the Caribbean. Apparently, like me, he noticed that he was delivering instantly-usable product now, and getting paid later, too much later usually. I discovered cypherpunks in late spring of 1994 looking for a solution to something Barnes (again) called the “latency” problem. Chriss bumped into the gold-silver-crypto list, I think, about 10 years later. > > Mr. Odom has been been kind enough to involve me in testing OT a bit, and, ultimately, I’ve more-or-less bailed on iterative break-it-and-fix-it. Mostly because I don’t have the patience for testing — much less writing — code, if I ever really did. > > But here’s the rub, I also I have no *idea* what I, personally, would do with Open Transactions these days even if I could get it running in production. > > I have lots of ideas in *general*, you understand, but they’re mostly of the “let’s you and him fight” variety. > > Many more people than *I* would have to be involved, they, and I, would risk much more than money, and, ultimately, I’m not sure any of it would work. It’s a drag to think that most of what I’m interested in doing requires the dissolution, or at least dissipation, of The World’s Only Remaining Superpower to happen. As someone who still, barely, calls himself mostly an anarcho-capitalist but still a patriot, that’s about the only thing worse than only being interesting to other people during the top of a bubble. Yup. A Mass of Contradictions, as usual. > > > "Let’s you and him fight" is only two or three steps removed from Mr. Briceno’s original observation, I figure. > > Hell, even “set here next to the rockin' chair, sonny, and I’ll tell ya a story”, is, ultimately, not much more help than “get off my lawn”, when you get right down to it... > > Cheers, > RAH > > > > _______________________________________________ > The cryptography mailing list > cryptography at metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dan at geer.org Tue Feb 18 11:16:54 2014 From: dan at geer.org (dan at geer.org) Date: Tue, 18 Feb 2014 14:16:54 -0500 Subject: Cryptocurrencies for Good Message-ID: <20140218191654.DFC702280DE@palinka.tinho.net> http://www.bbc.co.uk/news/magazine-26169411 Why every household should have its own currency --dan From hettinga at gmail.com Tue Feb 18 11:36:02 2014 From: hettinga at gmail.com (Robert Hettinga) Date: Tue, 18 Feb 2014 15:36:02 -0400 Subject: Cryptocurrencies for Good In-Reply-To: <20140218191654.DFC702280DE@palinka.tinho.net> References: <20140218191654.DFC702280DE@palinka.tinho.net> Message-ID: <49EB2163-1B37-4223-8C86-B00AEEE80C48@gmail.com> On Feb 18, 2014, at 3:16 PM, dan at geer.org wrote: > Why every household should have its own currency http://www.wired.com/wired/archive/4.08/buttonwood.html Heh. Cheers, RAH -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dan at geer.org Tue Feb 18 13:45:08 2014 From: dan at geer.org (dan at geer.org) Date: Tue, 18 Feb 2014 16:45:08 -0500 Subject: bitcoin Message-ID: <20140218214508.C952C2280E4@palinka.tinho.net> Yesterday's letter to alumni from MIT President Reif ________________________________________________________________ Dear MIT Alumni, This evening, I sent the following message to the campus MIT community. Because I know that you care very much about the welfare of our students, I thought you might be interested to see it, too. Sincerely, L. Rafael Reif __________________________________________________________________ To the members of the MIT community: I am writing to address a problem that a group of MIT students currently face but that concerns all of us, because it highlights issues central to sustaining the creative culture of MIT. The students in question are the creators of Tidbit, a proof-of-concept code for a novel Bitcoin-harvesting strategy. After Tidbit won the "most innovative" award in a recent hackathon, the State Attorney General of New Jersey demanded that the students turn over a sweeping set of documents, code and information--a surprising and difficult turn of events for the Tidbit team. I am grateful to all those who have written to me to express their concern about this situation, and I want to make it clear that the students who created Tidbit have the full and enthusiastic support of MIT. Chancellor Cindy Barnhart and Provost Marty Schmidt met with the students yesterday. They and General Counsel Greg Morgan also spoke with the Electronic Frontier Foundation (EFF), which is providing to the students, pro bono, the independent legal representation that they need. We will remain in close coordination with the students and the EFF to offer assistance in the legal proceedings. Beyond this specific case, I believe we should provide our student inventors and entrepreneurs with a resource for independent legal advice, singularly devoted to their interests and rights. I have asked the Provost, Chancellor and General Counsel to develop and submit to me a specific proposal for creating such a resource, which will add an essential new strength to MIT's innovation ecosystem. When the MIT community works together, we spot problems, analyze them and solve them. Let's solve this one together. Sincerely, L. Rafael Reif From l at odewijk.nl Tue Feb 18 16:11:53 2014 From: l at odewijk.nl (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?=) Date: Wed, 19 Feb 2014 01:11:53 +0100 Subject: bitcoin In-Reply-To: <20140218214508.C952C2280E4@palinka.tinho.net> References: <20140218214508.C952C2280E4@palinka.tinho.net> Message-ID: I hope that by novel he meant deceit and wasteful. Pure waste to be mining like that. If they had at least used a scrypt coin, that'd be a start. Information is too scarce to see if they managed GPU mining somehow. Although that'd produce it's own set of problems (see also what happened after blizzard had the starcraft menu not-vsynced). I don't see why the law would have to be involved though. What motivation is given for their research? Very hard to understand. Maybe it can be phrased as "stealing computer power"? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 623 bytes Desc: not available URL: From cryptomars at cryptoparty.fr Tue Feb 18 16:57:39 2014 From: cryptomars at cryptoparty.fr (Cryptoparty Marseille) Date: Wed, 19 Feb 2014 01:57:39 +0100 Subject: bitcoin In-Reply-To: References: <20140218214508.C952C2280E4@palinka.tinho.net> Message-ID: <53040183.5090902@cryptoparty.fr> On 19/02/2014 01:11, Lodewijk andré de la porte wrote: > I hope that by novel he meant deceit and wasteful. Pure waste to be > mining like that. If they had at least used a scrypt coin, that'd be a > start. > > Information is too scarce to see if they managed GPU mining somehow. > Although that'd produce it's own set of problems (see also what > happened after blizzard had the starcraft menu not-vsynced). > > I don't see why the law would have to be involved though. What > motivation is given for their research? Very hard to understand. Maybe > it can be phrased as "stealing computer power"? The motivation could be "make it possible for website authors to make a living without Google Adwords & other stupid ads" and that rocks, IMHO. Everything is wasteful you know. Buying things is mostly a waste of ressources. But at least let me decide what kind of waste I want to produce! Or just go the Zerzan way but then start by throwing away your computer and blowing up the nearest electricity poles. @cryptomars -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From cryptomars at cryptoparty.fr Tue Feb 18 17:00:28 2014 From: cryptomars at cryptoparty.fr (Cryptoparty Marseille) Date: Wed, 19 Feb 2014 02:00:28 +0100 Subject: bitcoin In-Reply-To: References: <20140218214508.C952C2280E4@palinka.tinho.net> Message-ID: <5304022C.4000603@cryptoparty.fr> On 19/02/2014 01:11, Lodewijk andré de la porte wrote: > What motivation is given for their research? By "their" you meant tidbit devs' motivation or New Jersey internet sheriffs' motivation? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From stephan.neuhaus at tik.ee.ethz.ch Tue Feb 18 23:06:35 2014 From: stephan.neuhaus at tik.ee.ethz.ch (Stephan Neuhaus) Date: Wed, 19 Feb 2014 08:06:35 +0100 Subject: bitcoin In-Reply-To: References: <20140218214508.C952C2280E4@palinka.tinho.net> Message-ID: <530457FB.6090709@tik.ee.ethz.ch> On 2014-02-19, 01:11, Lodewijk andré de la porte wrote: > What motivation is given for their research? I wasn't aware that motivation beyond "let's find out if we can make this shit work" (or "let's find out how this shit works" if you're doing pure research) is ever needed. Fun, Stephan From adg at crypto.lo.gy Wed Feb 19 01:05:13 2014 From: adg at crypto.lo.gy (Alfonso De Gregorio) Date: Wed, 19 Feb 2014 09:05:13 +0000 Subject: bitcoin In-Reply-To: <530457FB.6090709@tik.ee.ethz.ch> References: <20140218214508.C952C2280E4@palinka.tinho.net> <530457FB.6090709@tik.ee.ethz.ch> Message-ID: On Wed, Feb 19, 2014 at 7:06 AM, Stephan Neuhaus wrote: > On 2014-02-19, 01:11, Lodewijk andré de la porte wrote: >> What motivation is given for their research? > > I wasn't aware that motivation beyond "let's find out if we can make > this shit work" (or "let's find out how this shit works" if you're doing > pure research) is ever needed. > > Fun, > > Stephan Exactly. Or "If we knew what we were doing, it wouldn't be called research, would it?" -- (attributed to) Albert Einstein. From jamesdbell9 at yahoo.com Wed Feb 19 10:51:26 2014 From: jamesdbell9 at yahoo.com (jim bell) Date: Wed, 19 Feb 2014 10:51:26 -0800 (PST) Subject: bitcoin In-Reply-To: References: <20140218214508.C952C2280E4@palinka.tinho.net> <530457FB.6090709@tik.ee.ethz.ch> Message-ID: <1392835886.23848.YahooMailNeo@web126203.mail.ne1.yahoo.com> From: Alfonso De Gregorio On Wed, Feb 19, 2014 at 7:06 AM, Stephan Neuhaus wrote: > On 2014-02-19, 01:11, Lodewijk andré de la porte wrote: >> What motivation is given for their research? >> I wasn't aware that motivation beyond "let's find out if we can make >> this shit work" (or "let's find out how this shit works" if you're doing >> pure research) is ever needed. >> Fun, >> Stephan >Exactly. Or "If we knew what we were doing, it wouldn't be called >research, would it?" -- (attributed to) Albert Einstein. Here's what Tom Lehrer had to say about "Research".  (From the song, "Nicolai Ivanovich Lobachevsky", circa 1964) "Be that as it may, some of you may have had occasion to run into mathematicians and to wonder therefore how they got that way, and here, in partial explanation perhaps, is the story of the great Russian mathematician Nicolai Ivanovich Lobachevsky.  Who made me the genius I am today, The mathematician that others all quote, Who's the professor that made me that way? The greatest that ever got chalk on his coat. One man deserves the credit, One man deserves the blame, And Nicolai Ivanovich Lobachevsky is his name. Hi! Nicolai Ivanovich Lobach- I am never forget the day I first meet the great Lobachevsky. In one word he told me secret of success in mathematics: Plagiarize! Plagiarize, Let no one else's work evade your eyes, Remember why the good Lord made your eyes, So don't shade your eyes, But plagiarize, plagiarize, plagiarize - Only be sure always to call it please 'research'. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 7779 bytes Desc: not available URL: From pranesh at cis-india.org Wed Feb 19 07:59:54 2014 From: pranesh at cis-india.org (Pranesh Prakash) Date: Wed, 19 Feb 2014 10:59:54 -0500 Subject: XMPP Server is Working Again! In-Reply-To: References: Message-ID: <5304D4FA.5030807@cis-india.org> CypherPunk [2014-02-13 20:20:01]: > Hello Everyone, > > Just wanted to let everyone know that the XMPP server at chat.cpunk.us > is again operational. I experienced problems with it and ended up having > to restore it (which, unfortunately, deleted all the user accounts). > Please feel free to register again using the client of your choice. > > Server Name: chat.cpunk.us > Supports: Voice, Video, and Text chat > Server Software: OpenFire > Server OS: Ubuntu 12.04.4 LTS > Server Location: New York > Supports SSL? Yes > Support Email: cypherpunk at cpunk.us > > Certificate: Self-signed. Fingerprint below. > Certificate Fingerprint (SHA1): 327581c67147225943ff36063fb6c293e95df5d3 > Certificate Fingerprint (MD5): 10e8fd94a16c911bf72dc214f4e45966 On the server-side: https://xmpp.net/result.php?id=18229 Even ignoring the self-signed cert, it only gets a C, since TLS is not supported (only SSLv3 is supported) On the client-side: https://xmpp.net/result.php?id=18231 Please upgrade your Java instance, and then disable weak ciphers: http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#DisabledAlgorithms http://blog.eyallupu.com/2012/11/how-to-overriding-java-security.html Thanks. -- Pranesh Prakash Policy Director, Centre for Internet and Society T: +91 80 40926283 | W: http://cis-india.org ------------------- Access to Knowledge Fellow, Information Society Project, Yale Law School M: +1 520 314 7147 | W: http://yaleisp.org PGP ID: 0x1D5C5F07 | Twitter: https://twitter.com/pranesh_prakash -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 884 bytes Desc: OpenPGP digital signature URL: From matej.kovacic at owca.info Thu Feb 20 04:29:33 2014 From: matej.kovacic at owca.info (Matej Kovacic) Date: Thu, 20 Feb 2014 13:29:33 +0100 Subject: SSLv2 Message-ID: <5305F52D.9070509@owca.info> Hi, does anyone know which tool could be used for cracking SSLv2? Regards, Matej From eric at konklone.com Thu Feb 20 14:23:26 2014 From: eric at konklone.com (Eric Mill) Date: Thu, 20 Feb 2014 17:23:26 -0500 Subject: SSLv2 In-Reply-To: <5305F52D.9070509@owca.info> References: <5305F52D.9070509@owca.info> Message-ID: Github's code search may help: https://github.com/search?q=sslv2&ref=cmdform https://github.com/search?q=sslv2+crack&ref=searchresults&type=Code On Thu, Feb 20, 2014 at 7:29 AM, Matej Kovacic wrote: > Hi, > > does anyone know which tool could be used for cracking SSLv2? > > Regards, > > Matej > -- konklone.com | @konklone -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 1068 bytes Desc: not available URL: From cypher at cpunk.us Mon Feb 24 15:56:24 2014 From: cypher at cpunk.us (Cypher) Date: Mon, 24 Feb 2014 17:56:24 -0600 Subject: Test #1 Message-ID: <530BDC28.50704@cpunk.us> This is a test to validate if I am properly receiving list email. I've not seen anything in a few days. Cypher From rich at openwatch.net Mon Feb 24 18:49:27 2014 From: rich at openwatch.net (Rich Jones) Date: Mon, 24 Feb 2014 18:49:27 -0800 Subject: Gox Message-ID: Alleged leaked doc from inside Mt. Gox: http://www.scribd.com/doc/209050732/MtGox-Situation-Crisis-Strategy-Draft Nasty lookin', especially that assets and liabilities page! Although I don't understand how the theft could affect their cold storage. Soooooo.. who got burned? R -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 455 bytes Desc: not available URL: From apx.808 at gmail.com Mon Feb 24 16:24:44 2014 From: apx.808 at gmail.com (APX 808) Date: Mon, 24 Feb 2014 21:24:44 -0300 Subject: Test #1 In-Reply-To: <530BDC28.50704@cpunk.us> References: <530BDC28.50704@cpunk.us> Message-ID: Yup, working fine but really silent, weird considering this weekend gotoFail Cheerz http://apx808.blogspot.com On Mon, Feb 24, 2014 at 8:56 PM, Cypher wrote: > This is a test to validate if I am properly receiving list email. I've > not seen anything in a few days. > > Cypher > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 774 bytes Desc: not available URL: From juan.g71 at gmail.com Mon Feb 24 18:25:13 2014 From: juan.g71 at gmail.com (Juan Garofalo) Date: Mon, 24 Feb 2014 23:25:13 -0300 Subject: Test #1 In-Reply-To: <530BDC28.50704@cpunk.us> References: <530BDC28.50704@cpunk.us> Message-ID: --On Monday, February 24, 2014 5:56 PM -0600 Cypher wrote: > This is a test to validate if I am properly receiving list email. I've > not seen anything in a few days. I heard that somebody at the nsa forgot to pay for their antivirus subscription, which in turn led to some servers not working properly. Maybe one of those servers is the one hosting this list. > > Cypher > From decoy at iki.fi Mon Feb 24 17:28:57 2014 From: decoy at iki.fi (Sampo Syreeni) Date: Tue, 25 Feb 2014 03:28:57 +0200 (EET) Subject: Test #1 In-Reply-To: <530BDC28.50704@cpunk.us> References: <530BDC28.50704@cpunk.us> Message-ID: On 2014-02-24, Cypher wrote: > This is a test to validate if I am properly receiving list email. I've > not seen anything in a few days. Please die horribly. And your kids. The dog too. -- Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front +358-40-3255353, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From l at odewijk.nl Mon Feb 24 19:35:10 2014 From: l at odewijk.nl (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?=) Date: Tue, 25 Feb 2014 04:35:10 +0100 Subject: Gox In-Reply-To: References: Message-ID: MTGOX just started serving this: The requested page was not found on this server The cold storage has been wiped out due to a leak in the hotwallet what? Sorry but you do check your total balance every so often. I mean you do. "Injections in coin are most useful (enough to run the exchange) but some cash is also needed to not run a fractional reserve" This is actually really decent news. Running a fractional reserve would be very tolerable. It's interesting they mention turning off trade for a month, that's quite a lot. And it might just have started right now. 744,408 were stolen but they have a liability of 624,408 BTC Those numbers seem in the right order (if everything is kinda effed). "Coins for equity, coin donations, and cash injections to buy coins at the cheapMtGox price are some options among many." I think I could do with some equity. But I wonder if it'd be a good deal, given their distinct lack of Bitcoin (according to this document). "To avoid a bank run from customers, the daily amount of bitcoin and cashwithdrawals will be limited." Seems nobody got burned. Just for a while. Anyway. The question of how this happened is not really answered. "Poor Bitcoin accounting" is an understatement. Your hot wallet leaking is also not a very realistic thing, unless it was just a steady steal. How can someone steal all the money and not be detected (by anyone)? Can we somehow just revert the theft transactions? I'd at least like to know what happened to the coins. Who has them? Who goes to jail for it? This is a pretty strange way for all this to turn out if you ask me. I wonder who didn't get burned. 2014-02-25 3:49 GMT+01:00 Rich Jones : > > Alleged leaked doc from inside Mt. Gox: http://www.scribd.com/doc/209050732/MtGox-Situation-Crisis-Strategy-Draft > > Nasty lookin', especially that assets and liabilities page! Although I don't understand how the theft could affect their cold storage. > > Soooooo.. who got burned? > > R -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 2767 bytes Desc: not available URL: From decoy at iki.fi Mon Feb 24 19:55:33 2014 From: decoy at iki.fi (Sampo Syreeni) Date: Tue, 25 Feb 2014 05:55:33 +0200 (EET) Subject: [ot] Test #1 In-Reply-To: <1393296346.4708.87387445.3BAFD30B@webmail.messagingengine.com> References: <530BDC28.50704@cpunk.us> <1393296346.4708.87387445.3BAFD30B@webmail.messagingengine.com> Message-ID: On 2014-02-25, Alfie John wrote: > So instead of complaining like Sampo did, "don't feed the trolls" as > it could all be part of some JTRIG/HB Gary/Palantir campaign. Just > mark-as-read and move on. Like you just did? What I don't like is crud seeping through my spam filters. I mostly have it nailed, but test emails still make it. Absent GAI, how could they not? So, what should you do when someone clogs your inbox and probably that of thousands of others beside you, with a test email? The kind *everybody* knows shouldn't be sent to a list? Well, complain of course. Horribly. With the slightest tang of ill and cantankerous humour to soften it out just that little bit. Where were you when they invented netiquette? -- Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front +358-40-3255353, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From iam at kjro.se Tue Feb 25 06:19:51 2014 From: iam at kjro.se (Kelly John Rose) Date: Tue, 25 Feb 2014 07:19:51 -0700 Subject: Gox In-Reply-To: <530C842B.50702@cathalgarvey.me> References: <530C842B.50702@cathalgarvey.me> Message-ID: On Tuesday, February 25, 2014, Cathal Garvey wrote: > > The cold storage has been wiped out due to a leak in the hotwallet > > Sort of implies that "cold wallet" meant "bot-controlled wallet that > could automatically refill 'hot-wallet'." > > In other words, a second-layer hot-wallet. > > Never assume malice for that which is equally explainable with stupidity. > > > I guess this is one painful way to learn why banks and other financial institutions have very bureaucratic but very well established techniques for handling money and don't work with systems that were tosses together over a few weeks. Almost everything that seems to have happened is an example of either inexperience with proper bookkeeping or a complete disregard for established techniques in banking software. -- Kelly John Rose Toronto, ON Phone: +1 647 638-4104 Twitter: @kjrose Skype: kjrose.pr Gtalk: iam at kjro.se MSN: msn at kjro.se Document contents are confidential between original recipients and sender. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 1562 bytes Desc: not available URL: From drwho at virtadpt.net Tue Feb 25 10:22:20 2014 From: drwho at virtadpt.net (The Doctor) Date: Tue, 25 Feb 2014 10:22:20 -0800 Subject: Gox In-Reply-To: References: Message-ID: <530CDF5C.7070206@virtadpt.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/24/2014 06:49 PM, Rich Jones wrote: > Nasty lookin', especially that assets and liabilities page! > Although I don't understand how the theft could affect their cold > storage. Maybe their cold wallets weren't so cold. > Soooooo.. who got burned? Why would somebody trust a centralized entity that interfaces with a decentralized system that deals with something people perceive as valuable? "Hey! I'd rather work with a central point of failure!" I don't get it. - -- The Doctor [412/724/301/703] [ZS] PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "A little technobabble is good for the soul." --Jack Harkness, _Torchwood_ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMM31wACgkQO9j/K4B7F8GHlwCfckXXGZFXQBlVCfGUlJBvC85k OzIAn0fUpo30cJxg3UylTm4XigFWoY0g =UUoN -----END PGP SIGNATURE----- From cathalgarvey at cathalgarvey.me Tue Feb 25 03:52:01 2014 From: cathalgarvey at cathalgarvey.me (Cathal Garvey) Date: Tue, 25 Feb 2014 11:52:01 +0000 Subject: [ot] Test #1 In-Reply-To: <1393302611.18762.87416189.3DD91530@webmail.messagingengine.com> References: <530BDC28.50704@cpunk.us> <1393296346.4708.87387445.3BAFD30B@webmail.messagingengine.com> <1393302611.18762.87416189.3DD91530@webmail.messagingengine.com> Message-ID: <530C83E1.8080906@cathalgarvey.me> Well, this list is particularly susceptible to bullshit and flaming, and there's plenty that could be done to fix it but nothing is. Remailers could be required to have a hashcash header above a value that'd take about a minute to mint, so anonymity comes with a cost. Legit users will happily pay, asshats just looking to flame people will get bored and more on. Users that spam noise more than content are easily blocked by users individually, but persistent nonsense is easy blocked at the list level by moderation; except that the mods here are radical-free-speech guys who equate moderation of their own personal lists to state-level censorship. :P My point being, I guess, that often "activists" play into the hands of "authoritarianism" by aligning themselves against even the most basic methods of maintaining social cohesion. So, Occupy insisted on "consensus", which made it trivial to undermine by simply planting guys in the crowd who'd force "compromises" on important issues that watered them down to nothing. Lots of "info-activists" do similarly, aiming for some global awakening where we all sing together and agree on everything, obviating the need for social norms of any description. ..and the result is that it's trivial to discredit them and their work, or run interference, or make their channels so noisy that non-die-hards will just leave. Hopefully to form their own, somewhat more moderated, channels. On 25/02/14 04:30, Alfie John wrote: > On Tue, Feb 25, 2014, at 02:55 PM, Sampo Syreeni wrote: >> So, what should you do when someone clogs your inbox and probably that >> of thousands of others beside you, with a test email? The kind >> *everybody* knows shouldn't be sent to a list? Well, complain of course. >> Horribly. With the slightest tang of ill and cantankerous humour to >> soften it out just that little bit. >> >> Where were you when they invented netiquette? > > Any other time and it might have seemed in bad taste, but given that The > Intercept article I linked to was published only hours ago, I thought I > was being highly relevant. > > Alfie > -- Please help support my crowdfunding campaign, IndieBB: Currently at 27.4% of funding goal, with 17 days left: http://igg.me/at/yourfirstgmo/x/4252296 T: @onetruecathal, @IndieBBDNA P: +3538763663185 W: http://indiebiotech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x988B9099.asc Type: application/pgp-keys Size: 6176 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From cathalgarvey at cathalgarvey.me Tue Feb 25 03:53:15 2014 From: cathalgarvey at cathalgarvey.me (Cathal Garvey) Date: Tue, 25 Feb 2014 11:53:15 +0000 Subject: Gox In-Reply-To: References: Message-ID: <530C842B.50702@cathalgarvey.me> > The cold storage has been wiped out due to a leak in the hotwallet Sort of implies that "cold wallet" meant "bot-controlled wallet that could automatically refill 'hot-wallet'." In other words, a second-layer hot-wallet. Never assume malice for that which is equally explainable with stupidity. On 25/02/14 03:35, Lodewijk andré de la porte wrote: > MTGOX just started serving this: > The requested page was not found on this server > > > The cold storage has been wiped out due to a leak in the hotwallet > > what? > > > Sorry but you do check your total balance every so often. > > I mean you do. > > > "Injections in coin are most useful (enough to run the exchange) but some > cash is also needed to not run a fractional reserve" > > This is actually really decent news. Running a fractional reserve would be > very tolerable. It's interesting they mention turning off trade for a > month, that's quite a lot. And it might just have started right now. > > > 744,408 were stolen > but they have a liability of 624,408 BTC > > Those numbers seem in the right order (if everything is kinda effed). > > > "Coins for equity, coin donations, and cash injections to buy coins at the > cheapMtGox price are some options among many." > > I think I could do with some equity. But I wonder if it'd be a good deal, > given their distinct lack of Bitcoin (according to this document). > > > "To avoid a bank run from customers, the daily amount of bitcoin and > cashwithdrawals will be limited." > > Seems nobody got burned. Just for a while. > > > Anyway. The question of how this happened is not really answered. "Poor > Bitcoin accounting" is an understatement. Your hot wallet leaking is also > not a very realistic thing, unless it was just a steady steal. > > How can someone steal all the money and not be detected (by anyone)? > > Can we somehow just revert the theft transactions? I'd at least like to > know what happened to the coins. Who has them? Who goes to jail for it? > > > > This is a pretty strange way for all this to turn out if you ask me. I > wonder who didn't get burned. > > > 2014-02-25 3:49 GMT+01:00 Rich Jones : >> >> Alleged leaked doc from inside Mt. Gox: > http://www.scribd.com/doc/209050732/MtGox-Situation-Crisis-Strategy-Draft >> >> Nasty lookin', especially that assets and liabilities page! Although I > don't understand how the theft could affect their cold storage. >> >> Soooooo.. who got burned? >> >> R > -- Please help support my crowdfunding campaign, IndieBB: Currently at 27.4% of funding goal, with 17 days left: http://igg.me/at/yourfirstgmo/x/4252296 T: @onetruecathal, @IndieBBDNA P: +3538763663185 W: http://indiebiotech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x988B9099.asc Type: application/pgp-keys Size: 6176 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From alfiej at fastmail.fm Mon Feb 24 18:45:46 2014 From: alfiej at fastmail.fm (Alfie John) Date: Tue, 25 Feb 2014 13:45:46 +1100 Subject: Test #1 In-Reply-To: References: <530BDC28.50704@cpunk.us> Message-ID: <1393296346.4708.87387445.3BAFD30B@webmail.messagingengine.com> On Tue, Feb 25, 2014, at 12:28 PM, Sampo Syreeni wrote: > On 2014-02-24, Cypher wrote: > > > This is a test to validate if I am properly receiving list email. > > I've not seen anything in a few days. > > Please die horribly. And your kids. The dog too. Sometimes I think about unsubscribing from cpunks because of comments like these and other long-winded nonsense threads. But after reading the latest piece from The Intercept (https://firstlook.org/theintercept/2014/02/24/jtrig-manipulation/) I've got a feeling that some of the trolls on here are deliberate, hopefully driving us to unsubscribe: "One of the many pressing stories that remains to be told from the Snowden archive is how western intelligence agencies are attempting to manipulate and control online discourse with extreme tactics of deception and reputation-destruction." "Among the core self-identified purposes of JTRIG are two tactics: (1) to inject all sorts of false material onto the internet in order to destroy the reputation of its targets; and (2) to use social sciences and other techniques to manipulate online discourse and activism to generate outcomes considers desirable." Mass-unsubscribes because of some of the previous hate-threads sounds like one of those "desirable outcomes". So instead of complaining like Sampo did, "don't feed the trolls" as it could all be part of some JTRIG/HB Gary/Palantir campaign. Just mark-as-read and move on. Alfie -- Alfie John alfiej at fastmail.fm From drwho at virtadpt.net Tue Feb 25 13:50:29 2014 From: drwho at virtadpt.net (The Doctor) Date: Tue, 25 Feb 2014 13:50:29 -0800 Subject: Gox In-Reply-To: <50620A39FC6AB1EABF8DA9FA@F74D39FA044AA309EAEA14B9> References: <530CDF5C.7070206@virtadpt.net> <50620A39FC6AB1EABF8DA9FA@F74D39FA044AA309EAEA14B9> Message-ID: <530D1025.7000908@virtadpt.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/25/2014 12:09 PM, Juan Garofalo wrote: > I wonder if I'm getting this right : every single bitcoin > transaction since the bronze age is public, yet 700,000 coins > vanished and no one noticed? Yep. Seems legit. :P - -- The Doctor [412/724/301/703] [ZS] PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ There is no pumpkin here. That would be foolish. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMNECUACgkQO9j/K4B7F8EPiQCbBTZ9dofYf022bQYESpbJr0kJ 0oUAnjyHWnocfoUNbPplAOzVZ96z82MU =6uML -----END PGP SIGNATURE----- From iam at kjro.se Tue Feb 25 13:40:09 2014 From: iam at kjro.se (Kelly John Rose) Date: Tue, 25 Feb 2014 14:40:09 -0700 Subject: Gox In-Reply-To: References: <530CDF5C.7070206@virtadpt.net> Message-ID: On Tue, Feb 25, 2014 at 1:22 PM, Lodewijk andré de la porte wrote: > Their current website announcement is a straight offense too. > I find it somewhat ironic that they are shutting things down to avoid a run on the bank. They can't go to fractional reserves without essentially upsetting the ideology of many of their users and they cannot let their users take money out because they didn't implement the most basic accounting procedures for these things. Sadly, this is the precise reason banks are generally heavily regulated. Without that regulation, corners get cut and millions of dollars get stolen with no recompense. -- Kelly John Rose Toronto, ON Phone: +1 647 638-4104 Twitter: @kjrose Skype: kjrose.pr Gtalk: iam at kjro.se MSN: msn at kjro.se Document contents are confidential between original recipients and sender. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 1526 bytes Desc: not available URL: From fyl at a42.com Tue Feb 25 13:02:14 2014 From: fyl at a42.com (fyl) Date: Tue, 25 Feb 2014 15:02:14 -0600 Subject: Gox In-Reply-To: References: <530CDF5C.7070206@virtadpt.net> Message-ID: <530D04D6.7000706@a42.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/25/2014 02:22 PM, Lodewijk andré de la porte wrote: > 2014-02-25 19:22 GMT+01:00 The Doctor : > >> >> Why would somebody trust a centralized entity that interfaces >> with a decentralized system that deals with something people >> perceive as valuable? "Hey! I'd rather work with a central >> point of failure!" >> >> I don't get it. >> > > > I'd rather trust people that'd hang if they fail to secure a system > than my PC which is guaranteed to be replaced if it fails within 2 > years, insured against fire, etc. (And is guaranteed to fail) > > I did place coin elsewhere, luckily. But my trust in Mtgox was > quite large. Mostly because of their combination of high fees and > high volume. When I joined it was "If gox goes bust, everyone goes > bust". Now it's not totally clear. > > I hope others step in and buy mtgox. It'd net them the old > customerbase. It'd make everyone feel much safer on other > exchanges, even though they might not be. It's a lot of coin > though. Can't believe they never checked their safe. > > Their current website announcement is a straight offense too. > Wouldn't suprise me if some of them go to jail for Criminal > Neglegence. > What I didn't understand until a few minutes ago is that MtGox wasn't putting their transactions on the blockchain. Thus, the built-in validation model that comes with bitcoin was being "worked around". -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMNBM0ACgkQR0Qz1AeYNarW1wCfQiymj5KvFKu07Avd5/PvDWIY VjUAn2+xGSHfB5nCPPa6k5VDDgpBu86y =QRsp -----END PGP SIGNATURE----- From iam at kjro.se Tue Feb 25 14:07:01 2014 From: iam at kjro.se (Kelly John Rose) Date: Tue, 25 Feb 2014 15:07:01 -0700 Subject: Gox In-Reply-To: <530D0884.9000900@cathalgarvey.me> References: <530CDF5C.7070206@virtadpt.net> <530D04D6.7000706@a42.com> <530D0884.9000900@cathalgarvey.me> Message-ID: On Tue, Feb 25, 2014 at 2:17 PM, Cathal Garvey wrote: > > What I didn't understand until a few minutes ago is that MtGox wasn't > > putting their transactions on the blockchain. Thus, the built-in > > validation model that comes with bitcoin was being "worked around". > > Fucking hell, was that public knowledge all along? Why the hell did > anyone trust those cowboys with a cent!? > This is a good question, was this public knowledge? I'm guessing it wasn't. -- Kelly John Rose Toronto, ON Phone: +1 647 638-4104 Twitter: @kjrose Skype: kjrose.pr Gtalk: iam at kjro.se MSN: msn at kjro.se Document contents are confidential between original recipients and sender. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 1430 bytes Desc: not available URL: From alfiej at fastmail.fm Mon Feb 24 20:30:11 2014 From: alfiej at fastmail.fm (Alfie John) Date: Tue, 25 Feb 2014 15:30:11 +1100 Subject: [ot] Test #1 In-Reply-To: References: <530BDC28.50704@cpunk.us> <1393296346.4708.87387445.3BAFD30B@webmail.messagingengine.com> Message-ID: <1393302611.18762.87416189.3DD91530@webmail.messagingengine.com> On Tue, Feb 25, 2014, at 02:55 PM, Sampo Syreeni wrote: > So, what should you do when someone clogs your inbox and probably that > of thousands of others beside you, with a test email? The kind > *everybody* knows shouldn't be sent to a list? Well, complain of course. > Horribly. With the slightest tang of ill and cantankerous humour to > soften it out just that little bit. > > Where were you when they invented netiquette? Any other time and it might have seemed in bad taste, but given that The Intercept article I linked to was published only hours ago, I thought I was being highly relevant. Alfie -- Alfie John alfiej at fastmail.fm From iam at kjro.se Tue Feb 25 14:44:17 2014 From: iam at kjro.se (Kelly John Rose) Date: Tue, 25 Feb 2014 15:44:17 -0700 Subject: Gox In-Reply-To: References: <530CDF5C.7070206@virtadpt.net> Message-ID: On Tue, Feb 25, 2014 at 3:01 PM, Juan Garofalo wrote: > > > --On Tuesday, February 25, 2014 2:40 PM -0700 Kelly John Rose > > wrote: > > > On Tue, Feb 25, 2014 at 1:22 PM, Lodewijk andré de la porte > > wrote: > > > >> Their current website announcement is a straight offense too. > >> > > > > I find it somewhat ironic that they are shutting things down to avoid a > > run on the bank. They can't go to fractional reserves without essentially > > upsetting the ideology > > What? > > > > of many of their users and they cannot let their > > users take money out because they didn't implement the most basic > > accounting procedures for these things. > > > > Sadly, this is the precise reason banks are generally heavily regulated. > > > > The problem with the exchange is that they stole the coins, full > stop. > That's got nothing to do with regulation. It's plain thievery. > > ...Unless by regulation you mean the fundamental belief that theft > is > wrong...a belief that so called regulators or any other government > supporting retards don't share anyway. > > > > They were given the coins by people who trusted them and their code to not be easily manipulated. Their code was crap and didn't do the tracking properly. They didn't steal the coins, they screwed up the code by not ensuring that it was to the level of quality needed for such a high amount of finance moving through it. This is not theft, it's incompetence. This is closer to your bank leaving it's vault open or, in the case of Target, accidentally having all of the credit card numbers stolen. The problem here is that it is cheaper in the short term to create crappy code security-wise and push it live than it is to create code that is actually properly implemented for a banking environment to handle both the large amounts of money and the quite serious number of attacks that will take place once the amount of money available is established. In a competitive environment, the folks who take short cuts will save money in the short term, and thus will be more likely to pick up users than a more expensive equivalent that actually did the security correctly. Regulations in this circumstance only have the effect of ensuring a certain level of quality and security for the end consumer by levelling the playing field to a certain standard. -- Kelly John Rose Toronto, ON Phone: +1 647 638-4104 Twitter: @kjrose Skype: kjrose.pr Gtalk: iam at kjro.se MSN: msn at kjro.se Document contents are confidential between original recipients and sender. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 3524 bytes Desc: not available URL: From 4chaos.onelove at gmail.com Tue Feb 25 14:08:55 2014 From: 4chaos.onelove at gmail.com (Henry Rivera) Date: Tue, 25 Feb 2014 17:08:55 -0500 Subject: Gox In-Reply-To: References: Message-ID: Here are some articles related to this. The AP has picked up the story by now too. http://phys.org/news/2014-02-cyber-thieves-blamed-bitcoin-heist.html http://phys.org/news/2014-02-japan-mtgox-bitcoin-foundation-board.html http://phys.org/news/2014-02-website-bitcoin-exchange-mt-gox.html On Mon, Feb 24, 2014 at 9:49 PM, Rich Jones wrote: > Alleged leaked doc from inside Mt. Gox: > http://www.scribd.com/doc/209050732/MtGox-Situation-Crisis-Strategy-Draft > > Nasty lookin', especially that assets and liabilities page! Although I > don't understand how the theft could affect their cold storage. > > Soooooo.. who got burned? > > R > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 1528 bytes Desc: not available URL: From juan.g71 at gmail.com Tue Feb 25 12:09:00 2014 From: juan.g71 at gmail.com (Juan Garofalo) Date: Tue, 25 Feb 2014 17:09:00 -0300 Subject: Gox In-Reply-To: <530CDF5C.7070206@virtadpt.net> References: <530CDF5C.7070206@virtadpt.net> Message-ID: <50620A39FC6AB1EABF8DA9FA@F74D39FA044AA309EAEA14B9> I wonder if I'm getting this right : every single bitcoin transaction since the bronze age is public, yet 700,000 coins vanished and no one noticed? From juan.g71 at gmail.com Tue Feb 25 14:01:39 2014 From: juan.g71 at gmail.com (Juan Garofalo) Date: Tue, 25 Feb 2014 19:01:39 -0300 Subject: Gox In-Reply-To: References: <530CDF5C.7070206@virtadpt.net> Message-ID: --On Tuesday, February 25, 2014 2:40 PM -0700 Kelly John Rose wrote: > On Tue, Feb 25, 2014 at 1:22 PM, Lodewijk andré de la porte > wrote: > >> Their current website announcement is a straight offense too. >> > > I find it somewhat ironic that they are shutting things down to avoid a > run on the bank. They can't go to fractional reserves without essentially > upsetting the ideology What? > of many of their users and they cannot let their > users take money out because they didn't implement the most basic > accounting procedures for these things. > > Sadly, this is the precise reason banks are generally heavily regulated. The problem with the exchange is that they stole the coins, full stop. That's got nothing to do with regulation. It's plain thievery. ...Unless by regulation you mean the fundamental belief that theft is wrong...a belief that so called regulators or any other government supporting retards don't share anyway. > Without that regulation, corners get cut and millions of dollars get > stolen with no recompense. > > -- > Kelly John Rose > Toronto, ON > Phone: +1 647 638-4104 > Twitter: @kjrose > Skype: kjrose.pr > Gtalk: iam at kjro.se > MSN: msn at kjro.se > > Document contents are confidential between original recipients and sender. > From juan.g71 at gmail.com Tue Feb 25 14:10:31 2014 From: juan.g71 at gmail.com (Juan Garofalo) Date: Tue, 25 Feb 2014 19:10:31 -0300 Subject: Gox In-Reply-To: <530D1025.7000908@virtadpt.net> References: <530CDF5C.7070206@virtadpt.net> <50620A39FC6AB1EABF8DA9FA@F74D39FA044AA309EAEA14B9> <530D1025.7000908@virtadpt.net> Message-ID: <07ED2BBE58CC58323C5518CA@F74D39FA044AA309EAEA14B9> --On Tuesday, February 25, 2014 1:50 PM -0800 The Doctor wrote: > On 02/25/2014 12:09 PM, Juan Garofalo wrote: > >> I wonder if I'm getting this right : every single bitcoin >> transaction since the bronze age is public, yet 700,000 coins >> vanished and no one noticed? > > Yep. > > Seems legit. :P 100% fully certified legitimate. Call now! > > - -- > The Doctor [412/724/301/703] [ZS] > > PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 > WWW: https://drwho.virtadpt.net/ > > There is no pumpkin here. That would be foolish. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlMNECUACgkQO9j/K4B7F8EPiQCbBTZ9dofYf022bQYESpbJr0kJ > 0oUAnjyHWnocfoUNbPplAOzVZ96z82MU > =6uML > -----END PGP SIGNATURE----- > From juan.g71 at gmail.com Tue Feb 25 15:34:08 2014 From: juan.g71 at gmail.com (Juan Garofalo) Date: Tue, 25 Feb 2014 20:34:08 -0300 Subject: Gox In-Reply-To: References: <530CDF5C.7070206@virtadpt.net> Message-ID: --On Tuesday, February 25, 2014 3:44 PM -0700 Kelly John Rose wrote: > They were given the coins by people who trusted them and their code to not > be easily manipulated. Their code was crap and didn't do the tracking > properly. They didn't steal the coins, they screwed up the code by not > ensuring that it was to the level of quality needed for such a high amount > of finance moving through it. This is not theft, it's incompetence. Well, that's their story, which I don't find too plausible. Regardless, even if karpeles and friends didn't steal the coins themselves, other people did, thanks to mtgox's incompetence. The problem here is not a 'bank run' in the ordinary sense, it's just theft. > This > is closer to your bank leaving it's vault open or, in the case of Target, > accidentally having all of the credit card numbers stolen. If the bank left the vault's door open, then there's something fundamentally wrong with the bank, or there's some other funny business going on. Banks don't need 'regulators' telling them to keep their vaults closed... > > The problem here is that it is cheaper in the short term to create crappy > code security-wise and push it live than it is to create code that is > actually properly implemented for a banking environment to handle both the > large amounts of money and the quite serious number of attacks that will > take place once the amount of money available is established. > > In a competitive environment, the folks who take short cuts will save > money in the short term, and thus will be more likely to pick up users > than a more expensive equivalent that actually did the security correctly. And in the long term they will be out of business. Although that's not the whole picture. In this case, a different problem is that people are using a *centralized* exchange as a bank to keep their supposedly *decentralized* e-money. And that seems to be a trend. Seems to me that a lot of computer illiterate people store their btc in online centralized wallets that have access to the private keys? > > Regulations in this circumstance only have the effect of ensuring a > certain level of quality and security for the end consumer by levelling > the playing field to a certain standard. How could I have missed that? Government regulation is something created by honest politicians taking into account the best interests of their subjects =) > > -- > Kelly John Rose > Toronto, ON > Phone: +1 647 638-4104 > Twitter: @kjrose > Skype: kjrose.pr > Gtalk: iam at kjro.se > MSN: msn at kjro.se > > Document contents are confidential between original recipients and sender. > From cathalgarvey at cathalgarvey.me Tue Feb 25 13:17:56 2014 From: cathalgarvey at cathalgarvey.me (Cathal Garvey) Date: Tue, 25 Feb 2014 21:17:56 +0000 Subject: Gox In-Reply-To: <530D04D6.7000706@a42.com> References: <530CDF5C.7070206@virtadpt.net> <530D04D6.7000706@a42.com> Message-ID: <530D0884.9000900@cathalgarvey.me> > What I didn't understand until a few minutes ago is that MtGox wasn't > putting their transactions on the blockchain. Thus, the built-in > validation model that comes with bitcoin was being "worked around". Fucking hell, was that public knowledge all along? Why the hell did anyone trust those cowboys with a cent!? On 25/02/14 21:02, fyl wrote: > On 02/25/2014 02:22 PM, Lodewijk andré de la porte wrote: >> 2014-02-25 19:22 GMT+01:00 The Doctor : > >>> >>> Why would somebody trust a centralized entity that interfaces >>> with a decentralized system that deals with something people >>> perceive as valuable? "Hey! I'd rather work with a central >>> point of failure!" >>> >>> I don't get it. >>> > > >> I'd rather trust people that'd hang if they fail to secure a system >> than my PC which is guaranteed to be replaced if it fails within 2 >> years, insured against fire, etc. (And is guaranteed to fail) > >> I did place coin elsewhere, luckily. But my trust in Mtgox was >> quite large. Mostly because of their combination of high fees and >> high volume. When I joined it was "If gox goes bust, everyone goes >> bust". Now it's not totally clear. > >> I hope others step in and buy mtgox. It'd net them the old >> customerbase. It'd make everyone feel much safer on other >> exchanges, even though they might not be. It's a lot of coin >> though. Can't believe they never checked their safe. > >> Their current website announcement is a straight offense too. >> Wouldn't suprise me if some of them go to jail for Criminal >> Neglegence. > > > What I didn't understand until a few minutes ago is that MtGox wasn't > putting their transactions on the blockchain. Thus, the built-in > validation model that comes with bitcoin was being "worked around". > -- Please help support my crowdfunding campaign, IndieBB: Currently at 28.4% of funding goal, with 16 days left: http://igg.me/at/yourfirstgmo/x/4252296 T: @onetruecathal, @IndieBBDNA P: +3538763663185 W: http://indiebiotech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x988B9099.asc Type: application/pgp-keys Size: 6176 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From l at odewijk.nl Tue Feb 25 12:22:55 2014 From: l at odewijk.nl (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?=) Date: Tue, 25 Feb 2014 21:22:55 +0100 Subject: Gox In-Reply-To: <530CDF5C.7070206@virtadpt.net> References: <530CDF5C.7070206@virtadpt.net> Message-ID: 2014-02-25 19:22 GMT+01:00 The Doctor : > > Why would somebody trust a centralized entity that interfaces with a > decentralized system that deals with something people perceive as > valuable? "Hey! I'd rather work with a central point of failure!" > > I don't get it. > I'd rather trust people that'd hang if they fail to secure a system than my PC which is guaranteed to be replaced if it fails within 2 years, insured against fire, etc. (And is guaranteed to fail) I did place coin elsewhere, luckily. But my trust in Mtgox was quite large. Mostly because of their combination of high fees and high volume. When I joined it was "If gox goes bust, everyone goes bust". Now it's not totally clear. I hope others step in and buy mtgox. It'd net them the old customerbase. It'd make everyone feel much safer on other exchanges, even though they might not be. It's a lot of coin though. Can't believe they never checked their safe. Their current website announcement is a straight offense too. Wouldn't suprise me if some of them go to jail for Criminal Neglegence. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 1585 bytes Desc: not available URL: From l at odewijk.nl Tue Feb 25 13:19:11 2014 From: l at odewijk.nl (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?=) Date: Tue, 25 Feb 2014 22:19:11 +0100 Subject: Gox In-Reply-To: <530D04D6.7000706@a42.com> References: <530CDF5C.7070206@virtadpt.net> <530D04D6.7000706@a42.com> Message-ID: 2014-02-25 22:02 GMT+01:00 fyl : > > What I didn't understand until a few minutes ago is that MtGox wasn't > putting their transactions on the blockchain. Thus, the built-in > validation model that comes with bitcoin was being "worked around". Could you be a bit more specific about transaction? A Bitcoin transaction /has/ to go into the blockchain. An MtGox internal transaction normally wouldn't. A trade definitely wouldn't, as it bridges fiat and crypto. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 881 bytes Desc: not available URL: From tedks at riseup.net Tue Feb 25 19:44:23 2014 From: tedks at riseup.net (Ted Smith) Date: Tue, 25 Feb 2014 22:44:23 -0500 Subject: Telegram vs. Unhandled Expression In-Reply-To: <10324222.IxXungcVdZ@lap> References: <2004853.kmbRfK3vsB@lap> <1714654.Be1CP781r2@lap> <10324222.IxXungcVdZ@lap> Message-ID: <1393386263.15482.35.camel@anglachel> On Wed, 2014-02-26 at 02:54 +0100, rysiek wrote: > Dnia środa, 26 lutego 2014 02:42:49 Lodewijk andré de la porte pisze: > > 2014-02-26 1:44 GMT+01:00 rysiek : > > > Well, what kind of philantropist would start a UNIX alternative, right? ;) > > > > That's at least a kind that winds all his costs off on his university. A > > very understandable kind. > > I have no idea how and where to the Telegram crew "winds" their costs. Nor do > I care, as long as the communication is secured even from their own potential > meddling. > > So the question is: is it? A contest isn't the way to show it: http://thoughtcrime.org/blog/telegram-crypto-challenge/ -- Sent from Ubuntu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From rysiek at hackerspace.pl Tue Feb 25 14:08:33 2014 From: rysiek at hackerspace.pl (rysiek) Date: Tue, 25 Feb 2014 23:08:33 +0100 Subject: Telegram vs. Unhandled Expression Message-ID: <2004853.kmbRfK3vsB@lap> OHAI, This is very interesting, and I'd love cpunks opinion on it: http://unhandledexpression.com/2013/12/17/telegram-stand-back-we-know-maths/ Please note: http://unhandledexpression.com/2013/12/17/telegram-stand-back-we-know-maths/#comment-29424 "Telegram backer, Pavel Durov, will give $200,000 in BTC to the first person to break the Telegram encrypted protocol. Starting today, each day Paul (+79112317383) will be sending a message containing a secret email address to Nick (+79218944725). In order to prove that Telegram crypto was indeed deciphered and claim your prize, send an email to the secret email address from Paul’s message." inb4 "this does not tackle server MITM problem" no, no it doesn't; still, an interesting bet. -- Pozdr rysiek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: From l at odewijk.nl Tue Feb 25 16:29:33 2014 From: l at odewijk.nl (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?=) Date: Wed, 26 Feb 2014 01:29:33 +0100 Subject: Gox In-Reply-To: References: <530CDF5C.7070206@virtadpt.net> Message-ID: 2014-02-26 0:34 GMT+01:00 Juan Garofalo : > > This is closer to your bank leaving it's vault open or, in the case of > Target, > > accidentally having all of the credit card numbers stolen. > > If the bank left the vault's door open, then there's something > fundamentally wrong with the bank, or there's some other funny business > going on. > if the leaked document is correct: The fundamental problem here was that the guys in charge, especially the CEO, somehow managed to extract money from the vault (cold storage) and put it in the counter *without actually ever checking the vault **for years*. Never checking if the money in the vault fits the money you owe people is a very extreme way to put your head in the sand. This is obviously negligent, to a point that it would fall in the category of *criminal negligence* anywhere sane. The reason I had faith in mtgox is knowing they use cold storage, so if somehow the vault was draining they'd always have a wide margin to figure out what the hell was up. Somehow they kept *all their coins* semi-live. Meaning they could *all *get stolen. It's *ridiculous* and I couldn't imagine such a wealthy and industry leading company to not once have thought "maybe we should fix this". It is, at best, an example that doing a bad job is better than doing no job at all, and that in the end the bad job will fuck everyone over. Makes me feel I should go ahead and start my own exchange, 'cause I'd just do so much better a job than is being done right now. Except the army. Organization wise the army always deeply impressed me. Perhaps it's because it's the one big-organization that humanity has had thousands upon thousands of years of time for perfecting it, and those that didn't died? Banks don't need 'regulators' telling them to keep their vaults > closed... > Never underestimate human stupidity. > > > > The problem here is that it is cheaper in the short term to create crappy > > code security-wise and push it live than it is to create code that is > > actually properly implemented for a banking environment to handle both > the > > large amounts of money and the quite serious number of attacks that will > > take place once the amount of money available is established. > > > > In a competitive environment, the folks who take short cuts will save > > money in the short term, and thus will be more likely to pick up users > > than a more expensive equivalent that actually did the security > correctly. > > And in the long term they will be out of business. > Or not. If it were up to most regulators, definitely not. Mtgox was never in a highly competitive environment. If it were it wouldn't have been on top so steadily with so little improvements in service rendered. > Although that's not the whole picture. In this case, a different > problem > is that people are using a *centralized* exchange as a bank to keep their > supposedly *decentralized* e-money. This is offtopic to be honest. Whoever needed a money that was totally centralized, and why does he/she think Bitcoin is it? It's much much much more decentralized than any other currency. The fact that it's not useless now is what sets it apart from things like the LibertyDollar, so I'd say it's working just fine. Can't stand this sort of underinformed bullshitting. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 4555 bytes Desc: not available URL: From l at odewijk.nl Tue Feb 25 16:33:55 2014 From: l at odewijk.nl (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?=) Date: Wed, 26 Feb 2014 01:33:55 +0100 Subject: Telegram vs. Unhandled Expression In-Reply-To: <2004853.kmbRfK3vsB@lap> References: <2004853.kmbRfK3vsB@lap> Message-ID: They're not asking you to break Telegram, they're asking you to break the crypto. Breaking Telegram's servers is probably the easier way in. Either way, there Telegram guys have no profit model at all. I prefer the evil I know. What kind of philanthropist would start a whatsapp alternative? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 423 bytes Desc: not available URL: From rysiek at hackerspace.pl Tue Feb 25 16:44:59 2014 From: rysiek at hackerspace.pl (rysiek) Date: Wed, 26 Feb 2014 01:44:59 +0100 Subject: Telegram vs. Unhandled Expression In-Reply-To: References: <2004853.kmbRfK3vsB@lap> Message-ID: <1714654.Be1CP781r2@lap> Dnia środa, 26 lutego 2014 01:33:55 Lodewijk andré de la porte pisze: > They're not asking you to break Telegram, they're asking you to break the > crypto. Breaking Telegram's servers is probably the easier way in. Well, if you break-in and get the message contents from the servers, as far as I understand you do win the challenge, so... > Either way, there Telegram guys have no profit model at all. I prefer the > evil I know. What kind of philanthropist would start a whatsapp alternative? Well, what kind of philantropist would start a UNIX alternative, right? ;) -- Pozdr rysiek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: From rysiek at hackerspace.pl Tue Feb 25 17:54:46 2014 From: rysiek at hackerspace.pl (rysiek) Date: Wed, 26 Feb 2014 02:54:46 +0100 Subject: Telegram vs. Unhandled Expression In-Reply-To: References: <2004853.kmbRfK3vsB@lap> <1714654.Be1CP781r2@lap> Message-ID: <10324222.IxXungcVdZ@lap> Dnia środa, 26 lutego 2014 02:42:49 Lodewijk andré de la porte pisze: > 2014-02-26 1:44 GMT+01:00 rysiek : > > Well, what kind of philantropist would start a UNIX alternative, right? ;) > > That's at least a kind that winds all his costs off on his university. A > very understandable kind. I have no idea how and where to the Telegram crew "winds" their costs. Nor do I care, as long as the communication is secured even from their own potential meddling. So the question is: is it? -- Pozdr rysiek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: From grarpamp at gmail.com Tue Feb 25 23:57:04 2014 From: grarpamp at gmail.com (grarpamp) Date: Wed, 26 Feb 2014 02:57:04 -0500 Subject: Gox In-Reply-To: <530CDF5C.7070206@virtadpt.net> References: <530CDF5C.7070206@virtadpt.net> Message-ID: On Tue, Feb 25, 2014 at 1:22 PM, The Doctor wrote: > Why would somebody trust a centralized entity that interfaces with a > decentralized system that deals with something people perceive as > valuable? "Hey! I'd rather work with a central point of failure!" Probably because they don't currently have a choice. ie: afaik, there's no good decentral/p2p fiat-BTC exchange. Localbitcoins might be close in a way... distributed transaction locations in person... but it has a long way to go as far as volume and price sanity in any given area. And there seems to be some rollup of your transaction stats to the site, possibly including your price and volume, which a great many would not care to share. Until the commute to your local btc trader is tolerable, and under your desired level of regulation (or not), the big exchanges will remain the only real way to move nontrivial amounts in/out. That's not a problem for most players, they just want a place to play that looks stable long enough to push their transaction of interest through, or make enough money trading to offset the risk of trading there. On that note, Gox is dead. Any comeback will be a private legal matter between them and their customers/investors. If and after that 170M or so is ever paid off, by that time other fully legitimized and well regulated exchanges will have completely blown past and marginalized Gox (and others tbd) into just an early memory. Look to the US to come onboard with some *very* serious exchanges within the next year. Wall street already sees coins as tradeable, and banks love taking fees, holding stuff for you and pimping it out the backend. It really just comes down to how good Bitcoin (or any given virtual currency) is as a protocol... chain size, TPS, 51%, etc. VC's are pure greenfield and everyone wants a piece, including Govts (even if only by taxation). Gox isn't going to stop that, neither is any other non protocol meltdown or anon horsemen skirting the exchanges... the potential profits are just too big for entites to pass up. Claim your stake today. From matej.kovacic at owca.info Wed Feb 26 00:38:27 2014 From: matej.kovacic at owca.info (Matej Kovacic) Date: Wed, 26 Feb 2014 09:38:27 +0100 Subject: Telegram vs. Unhandled Expression In-Reply-To: <10324222.IxXungcVdZ@lap> References: <2004853.kmbRfK3vsB@lap> <1714654.Be1CP781r2@lap> <10324222.IxXungcVdZ@lap> Message-ID: <530DA803.60806@owca.info> Hi, > I have no idea how and where to the Telegram crew "winds" their costs. Nor do > I care, as long as the communication is secured even from their own potential > meddling. > > So the question is: is it? Founders of Telegram are also founders of VK, VKontakte, russian alternative to Facebook. The question here is, how close ties has VK with FSB, and how close ties have their founders with FSB? I have no idea, but below are some articles about this issue: http://www.ewdn.com/2013/04/12/vkontakte-ru-accused-of-collaborating-with-secret-service/ https://www.techdirt.com/articles/20130426/03510222844/has-russias-vkontakte-social-network-betrayed-its-users-is-it-under-attack-defending-them.shtml This is also very interesting: http://www.spiegel.de/international/business/kremlin-targets-russian-facebook-clone-vkontakte-a-897487.html Unfortunately, I do not know a situation in Russia at all, I am just thinking what *could* be a problem. Regards, M. From rysiek at hackerspace.pl Wed Feb 26 02:23:35 2014 From: rysiek at hackerspace.pl (rysiek) Date: Wed, 26 Feb 2014 11:23:35 +0100 Subject: Telegram vs. Unhandled Expression In-Reply-To: <530DA803.60806@owca.info> References: <2004853.kmbRfK3vsB@lap> <10324222.IxXungcVdZ@lap> <530DA803.60806@owca.info> Message-ID: <3884256.aCDnHafsT4@lap> Dnia środa, 26 lutego 2014 09:38:27 Matej Kovacic pisze: > Hi, > > > I have no idea how and where to the Telegram crew "winds" their costs. Nor > > do I care, as long as the communication is secured even from their own > > potential meddling. > > > > So the question is: is it? > > Founders of Telegram are also founders of VK, VKontakte, russian > alternative to Facebook. Ah, I had no idea! That is indeed a crucial element of that puzzle. > The question here is, how close ties has VK with FSB, and how close ties > have their founders with FSB? That is true. On the other hand, if the end-to-end crypto is safe and resilient even against their own MITM attack, this is less of an issue (just as the fact that TOR development is financed by the US Government is less of an issue due to how effective and safe TOR is). -- Pozdr rysiek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: From rysiek at hackerspace.pl Wed Feb 26 02:24:43 2014 From: rysiek at hackerspace.pl (rysiek) Date: Wed, 26 Feb 2014 11:24:43 +0100 Subject: Telegram vs. Unhandled Expression In-Reply-To: <1393386263.15482.35.camel@anglachel> References: <2004853.kmbRfK3vsB@lap> <10324222.IxXungcVdZ@lap> <1393386263.15482.35.camel@anglachel> Message-ID: <4440503.EhJK8b4aEr@lap> Dnia wtorek, 25 lutego 2014 22:44:23 Ted Smith pisze: > On Wed, 2014-02-26 at 02:54 +0100, rysiek wrote: > > Dnia środa, 26 lutego 2014 02:42:49 Lodewijk andré de la porte pisze: > > > 2014-02-26 1:44 GMT+01:00 rysiek : > > > > Well, what kind of philantropist would start a UNIX alternative, > > > > right? ;) > > > > > > That's at least a kind that winds all his costs off on his university. A > > > very understandable kind. > > > > I have no idea how and where to the Telegram crew "winds" their costs. Nor > > do I care, as long as the communication is secured even from their own > > potential meddling. > > > > So the question is: is it? > > A contest isn't the way to show it: > http://thoughtcrime.org/blog/telegram-crypto-challenge/ That is true. -- Pozdr rysiek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: From grarpamp at gmail.com Wed Feb 26 11:41:17 2014 From: grarpamp at gmail.com (grarpamp) Date: Wed, 26 Feb 2014 14:41:17 -0500 Subject: Tor @ FinCrypt2014 Message-ID: > Tor Weekly News — February 26th, 2014 > Tor @ Financial Cryptography and Data Security 2014 > Mar 03-07 Barbados http://fc14.ifca.ai/ The above is regarding botnets (mevade) using Tor and related network load and availability... a necessary foundation for finance. The FC14 program has an anonymity session, related to bitcoin, whose papers at this time don't appear to relate directly to applied anon FC via anon networks, but are closer to that topic... bitiodine, IP addresses, mixcoin... if that is what you were expecting. From pgut001 at cs.auckland.ac.nz Tue Feb 25 18:47:39 2014 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Wed, 26 Feb 2014 15:47:39 +1300 Subject: Gox In-Reply-To: Message-ID: Lodewijk andré de la porte writes: >Their current website announcement is a straight offense too. Wouldn't >suprise me if some of them go to jail for Criminal Neglegence. What would they be prosecuted for, not storing the tulip bulbs under dry enough conditions? It's not as if they violated any banking regulations. Peter. From gfoster at entersection.org Wed Feb 26 19:41:49 2014 From: gfoster at entersection.org (Gregory Foster) Date: Wed, 26 Feb 2014 21:41:49 -0600 Subject: CIA Project CHAOS/MHCHAOS Message-ID: <530EB3FD.2050903@entersection.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Document Exploitation (Feb 26) - "Confirmed: The CIA Destroyed Its Noam Chomsky File and Thousands More on Other U.S. Citizens": http://www.docexblog.com/2014/02/confirmed-cia-destroyed-its-noam.html > The file [scheduled for destruction] contains 7840 of a total of > 8,328 folders on individual U.S. persons (citizens, resident > aliens) and 2,196 volumes consisting of official and "soft" subject > files and so-called sensitive files (i.e., > organizations/activities), individual documents, and the index > related to these collections which were established under project > CHAOS during the period 1967-1974. The files were opened to > maintain information bearing on possible foreign Communist > exploitation of dissention in the United States, primarily > concerning the Vietnam War. Subjects of the folders were U.S. > citizens and organizations involved in dissident activities in the > United States. Now about that alleged CIA/FBI line between foreign and domestic surveillance... Also interesting as a historical precedent for why the NSA should be required to retain records in its databases which otherwise would be (allegedly) automatically purged on schedule: they are evidence of crimes helpful for active lawsuits. https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCgQqQIwAA&url=http%3A%2F%2Fonline.wsj.com%2Fnews%2Farticles%2FSB10001424052702303636404579393413176249186&ei=mbIOU6Yk47TIAeeKgZgE&usg=AFQjCNHaguzysNbmiy1NTSIOLj8WiPhrmA&bvm=bv.61965928,d.aWc HT the invaluable @saftergood, gf - -- Gregory Foster || gfoster at entersection.org @gregoryfoster <> http://entersection.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJTDrP6AAoJEMaAACmjGtgj2IsP/1P4Xc/ZBmm7TImxGrsVxjJQ Nu0HU+YltOAS68NbDfCKo/yQhYnDkvbjjuEO6WiTmEtf9C6sr1f0Xitr2n7PZEft BC397hkp02i8xZGeny5dn3JENe/8DNromdGfO+v5/oQ3ZNURNX+S8aIWxAVHL2ws ebxuR5CrlWFFhbg9H9YAMDe0DtXc54vWoEXC36rEpvKLpTWC5LZl8QuikbtuIC9m xW8LhwQMKUDT/mZFQ+W0W6KAFWlWHMEWRC2mEL2aKucbf2rfND7FX/pgYyeRjUeF iLrI8orHqJKDtddeFNO0agTz21v2+4D88hFk/4FjRdrUAFNHcAy7XrF9zwDP/Kzm jqcWFIFjEbPTDxRR4tXlA5aMnkqose+N77LRXk4YKACgfmK+cPaYkVaPCgJ4D7uO pOZSRnduRkdI6VPdvVww8AvHYGhkbwDUBGc7CQN1WMiBtyLSHsnji7stxDsIMVze ervt8ZkjGWJWT/BgFsJYUE/MH8TCMd0m3y2jmQG9nVwyYURCz8fn+AiOMgv2rynB +aSA6SqCQiXKpAT6GGbRvijUmmVY9Bx3jUzqh72jGp3ANRq53E+ySS4z6TPXe3e5 P6QvCvNegnTEhdgy4zc5Q9buwdShQEZRVC/7YetmodloT3czjBX3me/nTGvpFxwy jAoQVJ2hSDA1L5jCBLyI =L5rJ -----END PGP SIGNATURE----- From mixmaster at remailer.privacy.at Thu Feb 27 05:08:24 2014 From: mixmaster at remailer.privacy.at (Anonymous Remailer (austria)) Date: Thu, 27 Feb 2014 14:08:24 +0100 (CET) Subject: Red Pike cipher Message-ID: <92e6e17e1f1db50b11c13c4a4ca9c25c@remailer.privacy.at> /* Red Pike cipher source code */ #include typedef uint32_t word; #define CONST 0x9E3779B9 #define ROUNDS 16 #define ROTL(X, R) (((X) << ((R) & 31)) | ((X) >> (32 - ((R) & 31)))) #define ROTR(X, R) (((X) >> ((R) & 31)) | ((X) << (32 - ((R) & 31)))) void encrypt(word * x, const word * k) { unsigned int i; word rk0 = k[0]; word rk1 = k[1]; for (i = 0; i < ROUNDS; i++) { rk0 += CONST; rk1 -= CONST; x[0] ^= rk0; x[0] += x[1]; x[0] = ROTL(x[0], x[1]); x[1] = ROTR(x[1], x[0]); x[1] -= x[0]; x[1] ^= rk1; } rk0 = x[0]; x[0] = x[1]; x[1] = rk0; } void decrypt(word * x, const word * k) { word dk[2] = { k[1] - CONST * (ROUNDS + 1), k[0] + CONST * (ROUNDS + 1) }; encrypt(x, dk); } From griffin at cryptolab.net Thu Feb 27 14:12:46 2014 From: griffin at cryptolab.net (Griffin Boyce) Date: Thu, 27 Feb 2014 17:12:46 -0500 Subject: Whonix Anonymous Operating System Version 8 Released! In-Reply-To: <530FB6DF.9060806@riseup.net> References: <530FB6DF.9060806@riseup.net> Message-ID: <530FB85E.6000805@cryptolab.net> -------- Original Message -------- Subject: [tor-talk] Whonix Anonymous Operating System Version 8 Released! Date: Thu, 27 Feb 2014 22:06:23 +0000 From: Patrick Schleizer Reply-To: tor-talk at lists.torproject.org To: tor-talk at lists.torproject.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Whonix is an operating system focused on anonymity, privacy and security. It's based on the Tor anonymity network, Debian GNU/Linux and security by isolation. DNS leaks are impossible, and not even malware with root privileges can find out the user's real IP. Whonix consists of two parts: One solely runs Tor and acts as a gateway, which we call Whonix-Gateway. The other, which we call Whonix-Workstation, is on a completely isolated network. Only connections through Tor are possible. Download Whonix for VirtualBox ############################## https://www.whonix.org/wiki/Download Download Whonxi for KVM / Qemu ############################## Experimental. See below. Users of Whonix 7 and below ########################### There is no upgrade path from Whonix 7 to Whonix 8, sorry. You have to manually download new Whonix images. Call for Help ############# - - If you know shell scripting (/bin/bash) and linux sysadmin, please join us! There are plenty of ways to make Whonix safer. - - We are also looking for a download mirros. - - For https://www.whonix.org we need some help with css, html, mediawiki, wordpress, webdesign. Download Whonix for KVM / Qemu ############################## Entirely untested! This is only useful if you have a developers mindset! This is the first time .qcow2 images are available (as .tar.gz, qcow2 image must be unpacked): http://sourceforge.net/projects/whonix/files/current/8/ We have unfinished(!) instructions for KVM: https://www.whonix.org/wiki/KVM There are still a few blockers before using Whonix with KVM can be considered sane: https://www.whonix.org/wiki/Dev/KVM Please help out solving them. Whonix also needs a maintainer to support using Whonix with KVM. If you want to upgrade existing Whonix version using Whonix's APT repository ################################################################ Sorry, upgrading from existing Whonix version (0.5.6, 7, etc.) to Whonix 8 is not be possible. Updating from the previous testers-only version 7.7.8.6 or 7.7.9.8 should be possible when you have Whonix's (stable) APT repository enabled. See: https://www.whonix.org/wiki/Whonix-APT-Repository (Whonix 7.7.9.8 is the same version as Whonix 8, just a different version number.) If you want to upgrade existing Whonix version from source code ############################################################### Sorry, upgrading from existing Whonix version (0.5.6, 7, etc.) to Whonix 8 is not be possible. Updating from the previous testers-only version 7.7.8.6 or 7.7.9.8 should be possible, see: https://www.whonix.org/wiki/Dev/BuildDocumentation_8_deb (Whonix 7.7.9.8 is the same version as Whonix 8, just a different version number.) If you want to build images from source code ############################################ See https://www.whonix.org/wiki/Dev/BuildDocumentation. Physical Isolation users ######################## See https://www.whonix.org/wiki/Physical_Isolation. Changelog between Whonix 7 and Whonix 8 ####################################### * Whonix is now based on Debian stable instead of Debian testing. * In new installations, automatic updates of Whonix's debian packages are disabled by default. During first start, users can decide if they want to enable Whonix's APT repository or want to leave it disabled. * Fixed Whonix's Tor Browser download and start script for TBB 3.5. * Fixed physical isolation build script. * Verifiable Builds. Whonix now has a feature which allows the community to check that Whonix .ova releases are verifiably created from project's own source code. Also made ade Whonix's APT repository verifiable (even deterministic!). Please see https://www.whonix.org/wiki/Verifiable_Builds for details. * Made Whonix build script configurable (can now build terminal-only Whonix-Gateway's and/or Whonix-Workstations; 64 bit builds and more) * Improved Whonix News's security. All Whonix News Files are now inside one tarball, which is signed. This stops leaking how many users are using a particular version. * whonixcheck's Whonix News download now checks if Whonix News are still valid (currently up to 4 weeks) and therefore detects indefinite freeze and replay attacks. * whonix_repository tool now has a graphical user interface; added more command line switches. * Set default locale to en_US.UTF-8. * Simplified custom user installation of TorChat, thanks to dummytor. (Protecting from Tor over Tor.) * Removed apper and synaptic from default installation, because they are too confusing / have too many bugs, do not always work in all cases for all users, #104, can still be manually installed if wanted, see also https://www.whonix.org/wiki/Dev/Automatic_Updates * whonixcheck: more configuration options, any function can now be disabled, this is useful for users who wish to disable control port filter proxy, they can disable the check_tor_bootstrap function * whonixcheck: added protection against possibly malicious strings from check.torproject.org (in case of a bug, compromise of check.tpo server or CA compromise), IP strings are now max 50 characters long. User will be warned in case the limit is exceeded. * Whonix-Workstation: no longer installing Tor Browser by default, this simplified implementing verifiable builds (#113), installing iceweasel by default, which can be used to download Tor Browser, added local iceweasel browser homepage saying that iceweasel should not be used for anything other than downloading Tor Browser, unless one knows what one is doing. * Removed galternatives from whonix-workstation-default-applications because galternatives has been (temporarily) removed from Debian testing * Building Whonix from frozen repository, from snapshot.debian.org to make the build script more resistant from upstream changes and also to make Whonix verifiable. * The Whonix Team can now use separate keys for Whonix's APT Repository and Whonix News. * Added technical documentation about keys in Whonix whonix_shared/usr/share/whonix/keys/readme. * new man page: man/whonix_shared/sdwdate.8.ronn * Deactivated Maximizing Windows by dragging them to the top of the screen to prevent users from accidentally maximizing their browser window when they are using resolutions higher than 1024x768. See https://www.whonix.org/wiki/Higher_Screen_Resolution ; https://github.com/Whonix/Whonix/issues/110 and https://trac.torproject.org/projects/tor/ticket/7255 for more information. #108 * added udisks to whonix-shared-packages-recommended for mounting removable drives * KDE settings changes, set to oxygen as suggested by scarp in "[Whonix-devel] Plastique kwin style & Widget Style" * whonixcheck: increased timeout for the tor bootstrap.py utility from 5 to 10 seconds to make it compatible with slow systems as per bug reporthttps://www.whonix.org/wiki/Special:AWCforum/st/id248/whonixcheck%3A_tor_bootstrap_statu....html * whonixcheck: Whonix News File is now deterministic * whonixcheck: Whonix News added timeout for gpg and tar * added secure-delete, because it contains sfill, which can be used to zero out free space, which is required for disk shrinking * Deactivated running update-command-not-found during build, since not deterministic (verifiable). Manually running is of course still possible. * whonix_shared/etc/apt/sources.list.d/torproject.list: removed the "deb http://deb.torproject.org/torproject.org tor-0.2.4.x-jessie main" repository, since that repository has been removed by The Tor Project (Tor is now in their Debian testing repository, which is already added) * fixed a bug reported by scarp, whonix_shared/usr/share/whonix/postinst.d/70_disable_kdm_autostart: was not disabling other display managers other than kdm. Now using the more generic /usr/lib/whonix/display-manager-dpkg-post-invoke. * msgcollector: fix race condition not always closing progress bar when it reached 100% * Whonix-Gateway: Workaround for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732578 https://www.whonix.org/wiki/Download#Connection_Issues_-_Tor_stops_working_after_an_Upgrade_and_needs_a_Workaround https://www.whonix.org/wiki/Special:AWCforum/st/id287/new_tor_and_debian_updates_today....html Set in /etc/default/tor: USE_AA_EXEC="no" Can be commented out when that bug gets fixed. * optionally (opt-in) building qcow2 images, first rudimentary implementation, build target (VirtualBox or qcow2 or both) should probably be configurable in whonix_build script (#122) * Whonix News Blog Download / Whonix News: Whonix News Blogs (Whonix Feature Blog and Whonix Important Blog) are now deployed over the same mechanism as Whonix News. * Whonix-Workstation: better implementation of dummytor using config-package-dev (might break compatibility with Whonix 7) * removed adrelanos' old key; removed whonix_shared/usr/share/whonix/postinst.d/70_legacy (breaks compatiblity with Whonix 7) * Re-implemented uwt and dummytor using config-package-dev instead of custom dpkg-diversions. Breaks compatibly with Whonix 7. * Removed rawdog and pandoc since no longer required. * moved misc scripts (Scripts for managing Whonix's offical repository and Whonix News; debug scripts; developer documentation and deprecated code) to https://github.com/Whonix/whonix-developer-meta-files * whonixcheck: do not show output of gpg for Whonix News verification * whonixcheck: do not start whonixcheck, if whonixsetup hasn't finished yet * whonixcheck: new --verbose / --debug options * whonixcheck: Check that /proc/sys/net/ipv4/ip_forward and /proc/sys/net/ipv6/ip_forward aren't set to 1 to prevent users from shooting their own feet. * whonixcheck: Whonix News can now optionally be signed with two keys, as long as either one is still valid, will be accepted * whonixcheck: whonix_shared/etc/init.d/whonixcheckd: on stop, give whonixcheck time to gracefully shut down so it can close any still eventually open progress bars * whonixcheck: fix, exit cleanly (close progress bar) when killed by other instance of whonixcheck * whonixsetup: start whonixcheck at the end of whonixsetup on Whonix-Workstation * torbrowser: hide output of gpg import; ask "Start Tor Browser yes/no" after upgrading" * torbrowser: added timeout to gpg to prevent endless data attacks * torbrowser/whonixcheck: alternative method detecting locally installed Tor Browser version. When $tbb_folder/Docs/version does not exist, i.e. when the user manually downloaded Tor Browser, try to detect version number from ~/tor-browser_en-US/Docs/sources/versions.; comment * desktop: higher resolution icons for whonix_repository, whonixcheck, contribute and donate, whonix gateway firewall, tb recommend, important blog and torbrowser * ram adjusted desktop starter: fixed lightdm (/usr/sbin/...) auto detection * qcow2 images: added metadata preallocation * qcow2 images: added "-o cluster_size=2M" to "qemu-img" for better performance * build script: fix "sudo: unable to resolve host debian" * build script: added --no-options to gpg to avoid conflict with user's gpg config files * build script: added benchmarking * build script: whonix_build_both: support extra parameter * build script: got rid of grml_config by using grml-debootstrap's new environment variables feature * build script: skip backup-img-after-grml-debootstrap and backup-img-after-meta-package-install build steps by default, can be re-enabled by builder * build script: allow running build-steps.d/2400_convert-img-to-qcow2 without root * build script: improved error handling, when error is detected, wait until builder presses enter before cleanup and exit to make it simpler to read error messages when building in cli * build script: fixed update-locale bug build script: Avoiding "perl: warning: Setting locale failed." as suggested on https://wiki.ubuntu.com/DebootstrapChroot and https://lists.debian.org/debian-amd64/2005/08/msg00249.html by setting export LANG="C" * verifiable builds: new build step build-steps.d/2350_cleanup; Get rid of /dev folder inside the vm image. This is only required for verifiable builds. Otherwise this could be skipped. For example, "sudo sha512sum /dev/xconsole" or "sudo sha512sum /dev/initctl" would run forever. The /dev folder gets recreated by the kernel upon first boot. * Improved messages. * Lots of smaller fixes. * Code refactoring. * For more details, see the git log. -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJTD7beXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2RTk3OUIyOEE2RjM3QzQzQkUzMEFGQTFD QjhENTBCQjc3QkIzQzQ4AAoJEMuNULt3uzxIU9oP/22e7sqG07qwTywxpfA0UVX/ QLtJ5i4KBJIoJUk7VWgt63r6dFlFkWIWD5EGn/CC4OywS/9DPNHA+lgrzJQdSZe2 NduB2cSihcewkxI2Mjb1X+VFcw3okzAokDrZ9EMblWHKjhlunBeoQmfGj9oCKc4p LCebZChFF0vAebk71hBMVcafgQEciHKx4KJKUsJQ+Dmhcbfa3Elba5QM5wKw6Whh DlqRUJ0UM+x/SQ/3dwIE5vMWdf1tj11q6P7BeJN7XUWf68FX0f1Zy/r8JtWwEt8q 5ZN9JXcGO/SAZdzFUvrhMCj93l/uBzTeC595mqLOkP8d700ofg1dVOnDdy1eiwh9 /uGJ+H7983te90WnkHnu8NTBfqwfi/ZmNNR+LBnNVxBUywXQaaUWCTgdHCx59CI9 hs9Wl5wxNLmeRbBvRCCbjNSir+1wbtKCeSb8NTBrsWOqyN/tIioN4vnoA33ls5tq HYxFNdMkaLAsSb6pO/b9oIs2EeXUL8t/E1mc9Jr3H7nkm5FbE+9sClugod+PPXL8 RiGU0o/XiVU/aaT+7iVAaTF7z8wlXFTTsQ1V6/FgsRAAVy9dKJQriPTY+bPcJhLZ 1z+VaTRcxXA+rCSM9VeBBYg1lzFevJP7ExH5y6cFgE8DBLPUtXG5cCISGZFS0A0x NzmZy2053AFzuPNAu5WC =JQiF -----END PGP SIGNATURE----- -- tor-talk mailing list - tor-talk at lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 17298 bytes Desc: not available URL: From hozer at hozed.org Thu Feb 27 15:40:32 2014 From: hozer at hozed.org (Troy Benjegerdes) Date: Thu, 27 Feb 2014 17:40:32 -0600 Subject: Gox In-Reply-To: References: <530CDF5C.7070206@virtadpt.net> Message-ID: <20140227234032.GL3180@nl.grid.coop> On Wed, Feb 26, 2014 at 02:57:04AM -0500, grarpamp wrote: > On Tue, Feb 25, 2014 at 1:22 PM, The Doctor wrote: > > Why would somebody trust a centralized entity that interfaces with a > > decentralized system that deals with something people perceive as > > valuable? "Hey! I'd rather work with a central point of failure!" > > Probably because they don't currently have a choice. ie: afaik, there's > no good decentral/p2p fiat-BTC exchange. Localbitcoins might be > close in a way... distributed transaction locations in person... but it > has a long way to go as far as volume and price sanity in any given > area. And there seems to be some rollup of your transaction stats > to the site, possibly including your price and volume, which a great > many would not care to share. Until the commute to your local btc > trader is tolerable, and under your desired level of regulation (or not), > the big exchanges will remain the only real way to move nontrivial > amounts in/out. That's not a problem for most players, they just > want a place to play that looks stable long enough to push their > transaction of interest through, or make enough money trading to > offset the risk of trading there. I've said it elsewhere.. The legally accepted way to launder money is hide it in high-frequency trades. Why would you want to trade on a centralized and reporting-to-the-regulators exchange? Well, its the perfect (and only) place to gain a sufficiently large anonymity set, and then when the exchange goes bust and large amounts are 'stolen' the entire corrupt Bitcoin 1% cartel now has plausible deniability that they were ever involved in Silk Road, or that fiat money bankers engineered the crash and subsequent 'ressurection' and additional 10x price jump you'll see in 6 to 9 months. See, it WAS those evil anonymous and distributed hackers that did it, really, not us central disaster capitalism planners. At least us farmers who remember the energy crisis, the farm crisis, the following mortgage crisis, and now the Bitcoin crisis sorta see a pattern here. My long-term bets are on more disaster capitalism when the great lakes freeze and the artic melts, and that the real money is in political theatre. ---------------------------------------------------------------------------- Troy Benjegerdes 'da hozer' hozer at hozed.org 7 elements earth::water::air::fire::mind::spirit::soul grid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash From cathalgarvey at cathalgarvey.me Thu Feb 27 14:50:30 2014 From: cathalgarvey at cathalgarvey.me (Cathal Garvey) Date: Thu, 27 Feb 2014 22:50:30 +0000 Subject: Red Pike cipher In-Reply-To: <92e6e17e1f1db50b11c13c4a4ca9c25c@remailer.privacy.at> References: <92e6e17e1f1db50b11c13c4a4ca9c25c@remailer.privacy.at> Message-ID: <530FC136.10707@cathalgarvey.me> So, if I understand this right; x and k are pairs of 32-bit numbers, as Red Pike is a 64-bit block system and 32 is the maximum int size on most platforms. k is key material, x is a pointer to the data. No state is preserved when encrypting x with k, so to encrypt lots of data, you must string it into a series of "x" and apply the cipher to each block. Am I mistaken? Is this any better than AES-ECB, then, if no cipher state is preserved between encrypted blocks? On 27/02/14 13:08, Anonymous Remailer (austria) wrote: > /* Red Pike cipher source code */ > > #include > > typedef uint32_t word; > > #define CONST 0x9E3779B9 > #define ROUNDS 16 > > #define ROTL(X, R) (((X) << ((R) & 31)) | ((X) >> (32 - ((R) & 31)))) > #define ROTR(X, R) (((X) >> ((R) & 31)) | ((X) << (32 - ((R) & 31)))) > > void encrypt(word * x, const word * k) > { > unsigned int i; > word rk0 = k[0]; > word rk1 = k[1]; > > for (i = 0; i < ROUNDS; i++) > { > rk0 += CONST; > rk1 -= CONST; > > x[0] ^= rk0; > x[0] += x[1]; > x[0] = ROTL(x[0], x[1]); > > x[1] = ROTR(x[1], x[0]); > x[1] -= x[0]; > x[1] ^= rk1; > } > > rk0 = x[0]; x[0] = x[1]; x[1] = rk0; > } > > void decrypt(word * x, const word * k) > { > word dk[2] = > { > k[1] - CONST * (ROUNDS + 1), > k[0] + CONST * (ROUNDS + 1) > }; > > encrypt(x, dk); > } > -- Please help support my crowdfunding campaign, IndieBB: Currently at 43.2% of funding goal, with 14 days left: http://igg.me/at/yourfirstgmo/x/4252296 T: @onetruecathal, @IndieBBDNA P: +3538763663185 W: http://indiebiotech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x988B9099.asc Type: application/pgp-keys Size: 6176 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From hozer at hozed.org Thu Feb 27 21:12:58 2014 From: hozer at hozed.org (Troy Benjegerdes) Date: Thu, 27 Feb 2014 23:12:58 -0600 Subject: Gox In-Reply-To: References: <530CDF5C.7070206@virtadpt.net> Message-ID: <20140228051258.GN3180@nl.grid.coop> > > > code security-wise and push it live than it is to create code that is > > > actually properly implemented for a banking environment to handle both > > the > > > large amounts of money and the quite serious number of attacks that will > > > take place once the amount of money available is established. > > > > > > In a competitive environment, the folks who take short cuts will save > > > money in the short term, and thus will be more likely to pick up users > > > than a more expensive equivalent that actually did the security > > correctly. > > > > And in the long term they will be out of business. > > > > Or not. If it were up to most regulators, definitely not. > > Mtgox was never in a highly competitive environment. If it were it wouldn't > have been on top so steadily with so little improvements in service > rendered. The service rendered was trade volume. It seemed to do that quite well. > > > Although that's not the whole picture. In this case, a different > > problem > > is that people are using a *centralized* exchange as a bank to keep their > > supposedly *decentralized* e-money. > > > This is offtopic to be honest. Whoever needed a money that was totally > centralized, and why does he/she think Bitcoin is it? It's much much much > more decentralized than any other currency. The fact that it's not useless > now is what sets it apart from things like the LibertyDollar, so I'd say > it's working just fine. Can't stand this sort of underinformed bullshitting. I'd argue that centralized systems provide, on averge, a larger anonymity set and privacy in the majority of cases than decentralized ones. In particular exchanges that everyone believes are 'incompetent' are a wonderful place to get a lot of cheap plausible deniability by making everyone else that uses it pay for it when the house of cards falls down. -- ---------------------------------------------------------------------------- Troy Benjegerdes 'da hozer' hozer at hozed.org 7 elements earth::water::air::fire::mind::spirit::soul grid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash From rysiek at hackerspace.pl Thu Feb 27 15:00:05 2014 From: rysiek at hackerspace.pl (rysiek) Date: Fri, 28 Feb 2014 00:00:05 +0100 Subject: [ot] Test #1 In-Reply-To: References: <530BDC28.50704@cpunk.us> <1393296346.4708.87387445.3BAFD30B@webmail.messagingengine.com> Message-ID: <1959902.eIimdIxmyx@lap> Dnia wtorek, 25 lutego 2014 05:55:33 Sampo Syreeni pisze: > On 2014-02-25, Alfie John wrote: > > So instead of complaining like Sampo did, "don't feed the trolls" as > > it could all be part of some JTRIG/HB Gary/Palantir campaign. Just > > mark-as-read and move on. > > Like you just did? > > What I don't like is crud seeping through my spam filters. I mostly have > it nailed, but test emails still make it. Absent GAI, how could they > not? > > So, what should you do when someone clogs your inbox and probably that > of thousands of others beside you, with a test email? The kind > *everybody* knows shouldn't be sent to a list? Well, complain of course. > Horribly. With the slightest tang of ill and cantankerous humour to > soften it out just that little bit. > > Where were you when they invented netiquette? I am asking the same question myself when I see a thread like that. I mean, 1 test e-mail, already 2 e-mails from the same person complaining about the test e-mail. You, Sir, brought twice as much noise and crud to this list as the original poster. If you need to communicate your disdain for test e-mails (which I find annoying but understandable), why not doing that privately and off-list? Do we all really need to hear your complaining? -- Pozdr rysiek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: From adg at crypto.lo.gy Thu Feb 27 17:04:40 2014 From: adg at crypto.lo.gy (Alfonso De Gregorio) Date: Fri, 28 Feb 2014 01:04:40 +0000 Subject: Red Pike cipher In-Reply-To: <92e6e17e1f1db50b11c13c4a4ca9c25c@remailer.privacy.at> References: <92e6e17e1f1db50b11c13c4a4ca9c25c@remailer.privacy.at> Message-ID: Le limited information available on the Red Pike cipher are quite consistent with the code below: an ARX block cipher, no look-up tables, virtually no key schedule, and requiring only few lines of code [1]. With a 64 bit key size the Alleged Red Pike (ARP) is insecure by modern standards. But it was possibly insecure also in the 1990s. ARP suffers from a large number of semi-weak keys. Actually, each key is a semi-weak key. A pair of ARP keys (K1, K2) is said to be semi-weak if E_K1(E_K2(M)) = M (i.e., encryption with K1 operates as does decryption with K2). With ARP Feistel structure and its key schedule,there are 2^63 such pairs, reducing the size of the key space to 2^63. The relationship between each semi-weak pairs is: K2_L = K1_R - 2^32/phi * 17 K2_R = K1_L + 2^32/phi * 17 where phi is the golden ratio. Being semi-weak keys a large fraction of the ARP key space, implementations cannot apply the standard countermeasures against this undesirable property. Picking a semi-weak key is inevitable. The question remains: Is the Alleged Red Pike the cipher designed by the GCHQ? [1] Anderson, Ross; Kuhn, Markus, "Low Cost Attacks on Tamper Resistant Devices", in M. Lomas et al. (ed.), Security Protocols, 5th International Workshop, Paris, France, April 7{9, 1997, Proceedings, Springer LNCS 1361, pp 125-136, ISBN 3-540-64040-1, http://www.cl.cam.ac.uk/~rja14/Papers/tamper2.pdf On Thu, Feb 27, 2014 at 1:08 PM, Anonymous Remailer (austria) wrote: > > /* Red Pike cipher source code */ > > #include > > typedef uint32_t word; > > #define CONST 0x9E3779B9 > #define ROUNDS 16 > > #define ROTL(X, R) (((X) << ((R) & 31)) | ((X) >> (32 - ((R) & 31)))) > #define ROTR(X, R) (((X) >> ((R) & 31)) | ((X) << (32 - ((R) & 31)))) > > void encrypt(word * x, const word * k) > { > unsigned int i; > word rk0 = k[0]; > word rk1 = k[1]; > > for (i = 0; i < ROUNDS; i++) > { > rk0 += CONST; > rk1 -= CONST; > > x[0] ^= rk0; > x[0] += x[1]; > x[0] = ROTL(x[0], x[1]); > > x[1] = ROTR(x[1], x[0]); > x[1] -= x[0]; > x[1] ^= rk1; > } > > rk0 = x[0]; x[0] = x[1]; x[1] = rk0; > } > > void decrypt(word * x, const word * k) > { > word dk[2] = > { > k[1] - CONST * (ROUNDS + 1), > k[0] + CONST * (ROUNDS + 1) > }; > > encrypt(x, dk); > } > From juan.g71 at gmail.com Thu Feb 27 22:16:14 2014 From: juan.g71 at gmail.com (Juan Garofalo) Date: Fri, 28 Feb 2014 03:16:14 -0300 Subject: Gox In-Reply-To: <20140228051258.GN3180@nl.grid.coop> References: <530CDF5C.7070206@virtadpt.net> <20140228051258.GN3180@nl.grid.coop> Message-ID: <51CE7974DCD4C1276C7C56BE@F74D39FA044AA309EAEA14B9> --On Thursday, February 27, 2014 11:12 PM -0600 Troy Benjegerdes wrote: > > I'd argue that centralized systems provide, on averge, a larger anonymity > set and privacy in the majority of cases than decentralized ones. In > particular exchanges that everyone believes are 'incompetent' are a > wonderful place to get a lot of cheap plausible deniability by making > everyone else that uses it pay for it when the house of cards falls down. In the case of something like mtgox, how did it provide privacy? Or plausible deniality? Users have to send IDs, bank account details, everything is logged, etc etc. What am I missing? > > > > -- > ------------------------------------------------------------------------- > --- Troy Benjegerdes 'da hozer' > hozer at hozed.org 7 elements > earth::water::air::fire::mind::spirit::soul grid.coop > > Never pick a fight with someone who buys ink by the barrel, > nor try buy a hacker who makes money by the megahash > > From cathalgarvey at cathalgarvey.me Fri Feb 28 01:51:34 2014 From: cathalgarvey at cathalgarvey.me (Cathal Garvey) Date: Fri, 28 Feb 2014 09:51:34 +0000 Subject: Red Pike cipher In-Reply-To: References: <92e6e17e1f1db50b11c13c4a4ca9c25c@remailer.privacy.at> Message-ID: <53105C26.8060601@cathalgarvey.me> Was it not in vogue during Crypto Wars 1.0 to promulgate ciphers with a keystrength that was feasible for big-crypto to smash but not the peasantry? If I'm reading you correctly, this cipher has less than 64 bits of security, more than DES at time of release. But, were attacks on this type of cipher known at the time it was written, which could be used to lower the effective strength for those "in the know"? Of course now I'd expect that a look around would find plenty of attacks on this cipher family. I'm just curious as to whether GCHQ were spreading a secret cipher algorithm to which they probably already had a set of good attacks at the time. On 28/02/14 01:04, Alfonso De Gregorio wrote: > Le limited information available on the Red Pike cipher are quite > consistent with the code below: an ARX block cipher, no look-up > tables, virtually no key schedule, and requiring only few lines of > code [1]. > > With a 64 bit key size the Alleged Red Pike (ARP) is insecure by > modern standards. But it was possibly insecure also in the 1990s. > > ARP suffers from a large number of semi-weak keys. Actually, each key > is a semi-weak key. A pair of ARP keys (K1, K2) is said to be > semi-weak if E_K1(E_K2(M)) = M (i.e., encryption with K1 operates as > does decryption with K2). With ARP Feistel structure and its key > schedule,there are 2^63 such pairs, reducing the size of the key space > to 2^63. > > The relationship between each semi-weak pairs is: > > K2_L = K1_R - 2^32/phi * 17 > K2_R = K1_L + 2^32/phi * 17 > > where phi is the golden ratio. > > Being semi-weak keys a large fraction of the ARP key space, > implementations cannot apply the standard countermeasures against this > undesirable property. Picking a semi-weak key is inevitable. > > > The question remains: Is the Alleged Red Pike the cipher designed by the GCHQ? > > > [1] Anderson, Ross; Kuhn, Markus, "Low Cost Attacks on Tamper > Resistant Devices", in M. Lomas et al. (ed.), Security Protocols, 5th > International Workshop, Paris, France, April 7{9, 1997, Proceedings, > Springer LNCS 1361, pp 125-136, ISBN 3-540-64040-1, > http://www.cl.cam.ac.uk/~rja14/Papers/tamper2.pdf > > > On Thu, Feb 27, 2014 at 1:08 PM, Anonymous Remailer (austria) > wrote: >> >> /* Red Pike cipher source code */ >> >> #include >> >> typedef uint32_t word; >> >> #define CONST 0x9E3779B9 >> #define ROUNDS 16 >> >> #define ROTL(X, R) (((X) << ((R) & 31)) | ((X) >> (32 - ((R) & 31)))) >> #define ROTR(X, R) (((X) >> ((R) & 31)) | ((X) << (32 - ((R) & 31)))) >> >> void encrypt(word * x, const word * k) >> { >> unsigned int i; >> word rk0 = k[0]; >> word rk1 = k[1]; >> >> for (i = 0; i < ROUNDS; i++) >> { >> rk0 += CONST; >> rk1 -= CONST; >> >> x[0] ^= rk0; >> x[0] += x[1]; >> x[0] = ROTL(x[0], x[1]); >> >> x[1] = ROTR(x[1], x[0]); >> x[1] -= x[0]; >> x[1] ^= rk1; >> } >> >> rk0 = x[0]; x[0] = x[1]; x[1] = rk0; >> } >> >> void decrypt(word * x, const word * k) >> { >> word dk[2] = >> { >> k[1] - CONST * (ROUNDS + 1), >> k[0] + CONST * (ROUNDS + 1) >> }; >> >> encrypt(x, dk); >> } >> -- Please help support my crowdfunding campaign, IndieBB: Currently at 43.5% of funding goal, with 14 days left: http://igg.me/at/yourfirstgmo/x/4252296 T: @onetruecathal, @IndieBBDNA P: +3538763663185 W: http://indiebiotech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x988B9099.asc Type: application/pgp-keys Size: 6176 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From shelley at misanthropia.info Fri Feb 28 10:20:23 2014 From: shelley at misanthropia.info (shelley at misanthropia.info) Date: Fri, 28 Feb 2014 10:20:23 -0800 Subject: TEST TEST TEST MOTHERFUCKER!!! In-Reply-To: <0dff3c49fef54ae0a453e3f43c2528e5@remailer.privacy.at> Message-ID: <20140228182027.4D068680139@frontend2.nyi.mail.srv.osa> *waves* Always good to see your Tentacle poking the list... (yeah, I just top posted.  Bite me.)   On Feb 28, 2014 10:15 AM, Anonymous Remailer (austria) <mixmaster at remailer.privacy.at> wrote: test... got an objection to test? improve your fucking spam filters you fucking idiots -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 614 bytes Desc: not available URL: From pgut001 at cs.auckland.ac.nz Thu Feb 27 16:57:39 2014 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Fri, 28 Feb 2014 13:57:39 +1300 Subject: Red Pike cipher In-Reply-To: <530FC136.10707@cathalgarvey.me> Message-ID: Cathal Garvey writes: >Is this any better than AES-ECB, then The interest isn't in any comparison with AES, it's that Red Pike is a classified GCHQ-designed cipher from the crypto wars. The code matches the description by Ross Anderson and Markus Kuhn, but if it's non-genuine then it could just have been implemented to make sure that it matches the description. It looks like a tweaked TEA-like cipher. If it is genuine and it's from GCHQ, maybe it's EnglishBreakfastTEA. Peter. From griffin at cryptolab.net Fri Feb 28 12:04:32 2014 From: griffin at cryptolab.net (Griffin Boyce) Date: Fri, 28 Feb 2014 15:04:32 -0500 Subject: TEST TEST TEST MOTHERFUCKER!!! In-Reply-To: <0dff3c49fef54ae0a453e3f43c2528e5@remailer.privacy.at> References: <0dff3c49fef54ae0a453e3f43c2528e5@remailer.privacy.at> Message-ID: <5310EBD0.6090807@cryptolab.net> Anonymous Remailer (micropenis) wrote: > test... got an objection to test? improve your fucking spam filters you fucking idiots You rang? From me at staticsafe.ca Fri Feb 28 14:51:21 2014 From: me at staticsafe.ca (staticsafe) Date: Fri, 28 Feb 2014 17:51:21 -0500 Subject: TEST TEST TEST MOTHERFUCKER!!! In-Reply-To: <0dff3c49fef54ae0a453e3f43c2528e5@remailer.privacy.at> References: <0dff3c49fef54ae0a453e3f43c2528e5@remailer.privacy.at> Message-ID: <531112E9.4090800@staticsafe.ca> On 2/28/2014 12:19, Anonymous Remailer (austria) wrote: > test... got an objection to test? improve your fucking spam filters you fucking idiots > if address :is "from" "mixmaster at remailer.privacy.at" { discard; stop; } Here, have a Sieve rule. -- staticsafe From mixmaster at remailer.privacy.at Fri Feb 28 09:19:52 2014 From: mixmaster at remailer.privacy.at (Anonymous Remailer (austria)) Date: Fri, 28 Feb 2014 18:19:52 +0100 (CET) Subject: TEST TEST TEST MOTHERFUCKER!!! Message-ID: <0dff3c49fef54ae0a453e3f43c2528e5@remailer.privacy.at> test... got an objection to test? improve your fucking spam filters you fucking idiots From rysiek at hackerspace.pl Fri Feb 28 11:27:07 2014 From: rysiek at hackerspace.pl (rysiek) Date: Fri, 28 Feb 2014 20:27:07 +0100 Subject: TEST TEST TEST MOTHERFUCKER!!! In-Reply-To: <20140228182027.4D068680139@frontend2.nyi.mail.srv.osa> References: <20140228182027.4D068680139@frontend2.nyi.mail.srv.osa> Message-ID: <4617302.Boaqu9s0SD@lap> Dnia piątek, 28 lutego 2014 10:20:23 shelley at misanthropia.info pisze: > *waves* Always good to see your Tentacle poking the list... > > (yeah, I just top posted.  Bite me.) /me bites. OM NOM NOM. -- Pozdr rysiek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: From mixmaster at remailer.privacy.at Fri Feb 28 14:45:14 2014 From: mixmaster at remailer.privacy.at (Anonymous Remailer (austria)) Date: Fri, 28 Feb 2014 23:45:14 +0100 (CET) Subject: time to set up the test amplifier script again :) Message-ID: <182bd34add28f56c4f53315366ee249d@remailer.privacy.at> damn bunch of fucking luddites.. whine piss and moan about test test test?? I will set up and run my "test amplifier" procmail script from the 1990's just for fucking with the whiners heads! fucking software wimps the "MEDUSA" tentacle #99 ps been way too fucking quiet around here fuckwads are all at the RSA conference selling us out! From rysiek at hackerspace.pl Fri Feb 28 17:18:16 2014 From: rysiek at hackerspace.pl (rysiek) Date: Sat, 01 Mar 2014 02:18:16 +0100 Subject: TEST TEST TEST MOTHERFUCKER!!! In-Reply-To: <531112E9.4090800@staticsafe.ca> References: <0dff3c49fef54ae0a453e3f43c2528e5@remailer.privacy.at> <531112E9.4090800@staticsafe.ca> Message-ID: <1946386.fVQiIAf3od@lap> Dnia piątek, 28 lutego 2014 17:51:21 staticsafe pisze: > On 2/28/2014 12:19, Anonymous Remailer (austria) wrote: > > test... got an objection to test? improve your fucking spam filters you > > fucking idiots > if address :is "from" "mixmaster at remailer.privacy.at" { > discard; > stop; > } > > Here, have a Sieve rule. I sieve what you did there. -- Pozdr rysiek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: From l at odewijk.nl Fri Feb 28 18:45:58 2014 From: l at odewijk.nl (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?=) Date: Sat, 1 Mar 2014 03:45:58 +0100 Subject: time to set up the test amplifier script again :) In-Reply-To: <182bd34add28f56c4f53315366ee249d@remailer.privacy.at> References: <182bd34add28f56c4f53315366ee249d@remailer.privacy.at> Message-ID: why whine about whiners? Why does nobody make sense nowadays... 2014-02-28 23:45 GMT+01:00 Anonymous Remailer (austria) < mixmaster at remailer.privacy.at>: > > damn bunch of fucking luddites.. whine piss and moan about test test > test?? I will set up and run my > "test amplifier" procmail script from the 1990's just for fucking with the > whiners heads! > > fucking software wimps > > the "MEDUSA" tentacle #99 > ps been way too fucking quiet around here fuckwads are all at the RSA > conference selling us out! > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 913 bytes Desc: not available URL: