July 2018 - cypherpunks-legacy

[Netsukuku] Netsukuku port to Vala. Work in progress, help wanted.
by Luca Dionisi 06 Jul '18

06 Jul '18

I have encountered many problems [and did not succeed yet] in making Python Stackless work correctly in ARM or MIPS architectures. Even admitting that it is possible, the python interpreter itself is quite memory consuming. This makes many/most embedded devices out of luck for netsukuku. The main points in favor of using Stackless instead of C, at least for me, have been: - fast prototyping - co-routine support (that is, tasklets in stackless terminology) Recently I have made some research on alternatives. The first requirement of course was support of co-routines. The most portable framework for this support is GNU Pth. [0] The second requirement was a good-enough high-level language that could allow the developer to focus on functional details. And possibly have a near one-to-one mapping of the features of python interpreter that we mostly used in our program. I think Vala does. [1] And it has many good points over other languages. It has modern features while producing old style C API/ABI compatible machine code. Long story short, I started to organize the basis for a port of current python implementation of netsukuku to Vala. The first task was producing a binding (vapi file) for the Pth library. I made one that does the job for what we need - could be improved, though. Right now there is a working implementation of tasklets ("microfunc" in our python code) scheduling, switching, inter-communication (Channels in our python code) and events (for free in Vala as signals). I promise to post updates soon when I can make some tests on my little mipsel-based router. [2] Soooo, to get to the point. This work is not going to be quick and simple. Any help with the development is welcome, especially right now or soon. I could organize the work and assign little tasks to anyone that has some expertise on vala. I am a vala newbie myself. Knowledge of python is not a requirement, because reading the old code is quite straightforward and one can ask when in doubt. Knowledge of current workings of netsukuku is not a requirement either. Sure, it could help. But I would assign very specific tasks and coordinate the rest, so that also "new entry" developers can help a lot. Have a look at the initial code [3] and please get involved! --Luca [0] http://www.gnu.org/software/pth/ [1] http://live.gnome.org/Vala [2] http://www.omnima.co.uk/store/catalog/Embedded-controller-p-16140.html and a review here: http://www.kelvinsthunderstorm.com/omnima-embedded-controller-and-openwrt/ [3] http://dev.hinezumi.org/browser/netsukuku/sandbox/lukisi/branches/multiplei… _______________________________________________ Netsukuku mailing list Netsukuku(a)lists.dyne.org http://lists.dyne.org/mailman/listinfo/netsukuku ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Lucrative update
by Patrick 06 Jul '18

06 Jul '18

Lucrative release 4 is out. I know many people are used to seeing releases numbered like "0.000001", "0.000002", "2.0.3.0.14.657" etc. but release numbering systems are essentially arbitrary in nature so don't get excited as Lucrative goes toward version 50+. This release is a fairly minor one, but included some changes such as the client name that I wanted to get out as soon as possible. There is also a new development weblog at http://lucrative.thirdhost.com/weblog/. I went through an install with someone over IRC last night and made a blog entry summarizing the install notes. I recommend reading the notes before attempting an install. I am glad to help with an install, drop me a note at patrick(a)lfcgate.com if you have trouble. Some documentation on the various entities in the Lucrative system is now available on the website, http://lucrative.thirdhost.com/documentation.php but more is needed and coming. If Lucrative is interesting to you, please consider helping in any way you can: Feedback Installation reports Suggestions Comments Criticism Feature requests Source code patches Donations Are all very much welcomed. And criticism is more useful to me than praise. My sincere thanks to everyone who has participated so far by installing, testing, providing feedback, spreading the word, and donating. And finally I just received word from SourceForge that the project registration for Lucrative has been approved. Regards, Patrick -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com> mQGiBD5ECKcRBADUvjXHwLtxIyS4AyjBs/dFtN6rdeP18Fhzh1hD5fJwkFevqY9Z I1ASROTh6eXYF7pU5sEvbcPshHyTB41ZtTqZvQvpwWN0fUzOuutuI0mtC5UPp9Rz j47SdWLdEXNHjwnHDCYSyqtqZu8GujGRQybR0eP3NIh/NwbSDUKdgz7IjwCg//Jo UtjP3zUFobm/0UYA+CJ5krED/091x9Js0gwNwvjbzM8DqO+r8qNz0kXI13FkrPRk QNd37lxt6m2m8HZD1WYM2wKwtMzHSwJcWzaDZ/tNc+ppYjzpw0EQCh9FqjGs8Vau guF6PA1M8lJTCcLKaL4e7ynic+PAw5Xa/tdOYgFCG+eLMU5RLvzRCYoOLIjgMJLJ yG98BACAMlDmFVYgC/UKvzZmHfZ5CtCKd8sPfCXrYLu5NeFRE0LR6D6zjzmhi1xX okfreR5o3T/y78VBM98js+m2/+7Z0AElqydeW/RnV1zqwDGjDr9z2MgARf3yLAbs n3BU8Fz61RwvHy6cRkT+2dR2f69QQUSpkupvLwZIGX/iwm4uKLQdUGF0cmljayA8 cGF0cmlja0BsZmNnYXRlLmNvbT6JAE4EEBECAA4FAj5ECKcECwMCAQIZAQAKCRBb mvb9yuOVfaA2AKDAu5tDj9F2KI8cJMrKKkQRAcUyxACg6/bei7lUJH+E5igJqGRx SjKrRA65BA0EPkQIpxAQAPkYoH5aBmF6Q5CV3AVsh4bsYezNRR8O2OCjecbJ3HoL rOQ/40aUtjBKU9d8AhZIgLUV5SmZqZ8HdNP/46HFliBOmGW42A3uEF2rthccUdhQ yiJXQym+lehWKzh4XAvb+ExN1eOqRsz7zhfoKp0UYeOEqU/Rg4Soebbvj6dDRgjG zB13VyQ4SuLE8OiOE2eXTpITYfbb6yUOF/32mPfIfHmwch04dfv2wXPEgxEmK0Ng w+Po1gr9oSgmC66prrNlD6IAUwGgfNaroxIe+g8qzh90hE/K8xfzpEDp19J3tkIt AjbBJstoXp18mAkKjX4t7eRdefXUkk+bGI78KqdLfDL2Qle3CH8IF3KiutapQvMF 6PlTETlPtvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSGSfgMg71l6RfUodNQ +PVZX9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarT W56NoKVyOtQa8L9GAFgr5fSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY72 88kjwEPwpVsYjY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy 1obEAxnIByl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XrPdYX AAICD/wKwtF7Y4NKBe8PQ6jDbjWziiTv9Ac/EnRTJDQEoqgLa2LyE+6Ahw/VPGvp mfxkD2MKxC9E7kYVmasn6sHnSpvAv3e7O1Bqbo/qLzzCcJQ5VCurZ+elRM1GZ4Oc fM19FPKutb0/JFEv0nrqS4BGkF7WFBbu5dKYl/GIO7Co1mAerFIb719dOwMPVEIz OT08u8uB9jyR8gEElf+CVuNfOUkrUGg4HS4SbmTTrCSz3/8n5PkquSuAyjCB/dwM ZsZwA0/TTR8sDYlmlf9xPj5PGpGnV9OUwfig6eE0eWtRFeasmz0uiX+yp45ABtNh 6EXP/PFaBgXi9omXXjeeFYfpDvmfA6izvTIQfXTV6V9ZWrBfXarM+GQ+6guXWVbd 9fXvmCr982LkzuKQrK1OpRXBMUapXL+tOy/LYzz91InqKKhgPNGa12fvotZ4LzlM iqoM+Hpz5L9B5We1Ph0lD6RBVXDCqd+P8extnY/7AaDy7tC0UghaAaUuEZXJQPIc oQ3QGbpjM0nGe/VZN5EZhljau0NNENFaU56cOpvOhcO04gLGNNc2NS+rIpTMsaHh o1CG90c5zZZJuUbyx0mIHriNQXDgEwunSZPQorKK9KSppyyjeuOyi5F/mBBPXeyT weLhLqLvAr9se/+Z3aQvMADJi8zUZtGggLTw+N9R5XSwtSh2R4kARgQYEQIABgUC PkQIpwAKCRBbmvb9yuOVfWayAKC+mBhHdn1XZ5uH0RocAyJ32hx2kgCePyhB+IqM TjWLDLarQxcPYhbkFi4= =nx1M -----END PGP PUBLIC KEY BLOCK----- --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0

None
by Alice Kehoe 06 Jul '18

06 Jul '18

dave(a)farber.net Subject: NSA eavesdropping program ruled unconstitutional [Dave: for IP, if you wish --AK] full text from: http://www.cnn.com/2006/POLITICS/08/17/ domesticspying.lawsuit.ap/index.html NSA eavesdropping program ruled unconstitutionalJudge orders immediate halt to program DETROIT, Michigan (AP) -- A federal judge ruled Thursday that the government's warrantless wiretapping program is unconstitutional and ordered an immediate halt to it. U.S. District Judge Anna Diggs Taylor in Detroit became the first judge to strike down the National Security Agency's program, which she says violates the rights to free speech and privacy. The American Civil Liberties Union filed the lawsuit on behalf of journalists, scholars and lawyers who say the program has made it difficult for them to do their jobs. They believe many of their overseas contacts are likely targets of the program, which involves secretly taping conversations between people in the U.S. and people in other countries. The government argued that the program is well within the president's authority, but said proving that would require revealing state secrets. The ACLU said the state-secrets argument was irrelevant because the Bush administration already had publicly revealed enough information about the program for Taylor to rule. ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

[IP] NSA eavesdropping program ruled unconstitutional
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

news.com: Tool mines personal data from across Net
by Bob Rosenberg 06 Jul '18

06 Jul '18

Dave Perhaps for IP. Bob Tool mines personal data from across Net By Joris Evers http://news.com.com/Tool+mines+personal+data+from+across+Net/ 2100-1029_3-6177625.html Story last modified Thu Apr 19 12:51:40 PDT 2007 VANCOUVER, B.C.--Who needs to dive through dumpsters or steal snail mail when so many details on people are available simply by searching the Web? South African security researcher Roelof Temmingh, known for his work on security tools such as Wikto, is taking the search for personal information a step farther. Temmingh--who spoke at the CanSecWest security conference here Wednesday--has crafted a tool dubbed "Evolution" that associates data found in multiple search engines and social-networking Web sites such as MySpace.com and LinkedIn. It also uses other sites' tools to find information behind Internet Protocol addresses, Domain Name System entries, domain registration and more. As a result, a search for a person will associate the individual with results found across the Net. The idea is that data found in one place can bring up results elsewhere. For example, an e-mail address may bring up a domain name, which in the next search may bring up a physical address. The searches could also connect work e-mail addresses with home phone numbers and expose details such as which NASA employees use social- networking sites and find people at the National Security Agency who use Google's Gmail, said Temmingh. Evolution, currently in its early stages, does all that automatically, he said. Temmingh created the tool not just to demonstrate his skills, but also to highlight just how much personal data the Net holds, and how vulnerable it is. The results can help somebody doing research into an individual, but they can also help a potential fraudster, Temmingh said. A search can expose information helpful for social-engineering attacks. Also, it can expose secondary targets as it will bring up information on individuals' alliances with people or organizations. Another possible use is "virtual identity theft," Temmingh said. You can assume a person's identity by registering free e-mail addresses in their name, setting up MySpace and LinkedIn profiles as them and getting the identity out so it gets indexed by search engines, he said. Copyright )1995-2007 CNET Networks, Inc. All rights reserved. ------------------------------------------- Archives: http://v2.listbox.com/member/archive/247/=now RSS Feed: http://v2.listbox.com/member/archive/rss/247/ Powered by Listbox: http://www.listbox.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[IP] Tool mines personal data from across Net
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

Secrecy News -- 07/18/12
by Steven Aftergood 06 Jul '18

06 Jul '18

Format Note: If you cannot easily read the text below, or you prefer to receive Secrecy News in another format, please reply to this email to let us know. SECRECY NEWS from the FAS Project on Government Secrecy Volume 2012, Issue No. 70 July 18, 2012 Secrecy News Blog: http://www.fas.org/blog/secrecy/ ** THE HISTORY OF THE SOVIET BIOLOGICAL WEAPONS PROGRAM ** PUBLISHING SCIENTIFIC PAPERS WITH POTENTIAL SECURITY RISKS ** FY2013 DEFENSE AUTHORIZATION, AND MORE FROM CRS THE HISTORY OF THE SOVIET BIOLOGICAL WEAPONS PROGRAM In 1972, the United States, the Soviet Union and other nations signed the Biological and Toxin Weapons Convention that was supposed to ban biological weapons. At that very time, however, the Soviet Union was embarking on a massive expansion of its offensive biological weapons program, which began in the 1920s and continued under the Russian Federation at least into the 1990s. The astonishing story of the Soviet biological weapons enterprise is told in an encyclopedic new work entitled "The Soviet Biological Weapons Program: A History" by Milton Leitenberg and Raymond A. Zilinskas (Harvard University Press, 2012). http://www.hup.harvard.edu/catalog.php?isbn=9780674047709 The Soviet biological weapons (BW) program was by far the largest and most sophisticated such program ever undertaken by any nation. It was also intensely secretive, and was masked by layers of classification, deception and misdirection. "The program's most important facilities remain inaccessible to outsiders to this day," Leitenberg and Zilinskas write, "and it has been made a crime for anyone in present-day Russia to divulge information about the former offensive BW program." Needless to say, official archives are closed and Russian government officials are uncommunicative on the subject, or deny the existence of the program altogether. Over a period of a decade or so, Leitenberg and Zilinskas were able to interview about a dozen former Soviet scientists who were involved in the Soviet BW program, along with dozens of other sources. Their revelations inform the authors' analysis and serve to advance public knowledge of the subject far beyond previous reports. Even relatively well-known incidents like the 1979 Sverdlovsk anthrax epidemic are cast in a new light. Many other aspects of the program will be entirely unfamiliar to most readers. Much of the book is devoted to a description of the vast infrastructure of Soviet BW research and production, including descriptions of the various institutes, their history, their workforce and the nature of their research, as far as it could be discerned. Along the way, many fascinating and sometimes horrific topics are addressed. For example: ** In an effort to enhance the weapons-related properties of BW agents, Soviet scientists spent years working to create a viral "chimera," which is an organism that contains genetic material from two or more other organisms. ** Other scientists worked to eliminate the "epitopes" on the surface of existing BW agents in order to make them unrecognizable to regular diagnostic techniques. By using such a modified agent, "the Soviets would have made it considerably more difficult for the attacked population to identify the causative pathogen of the resulting disease outbreak and begin timely treatment." ** A project codenamed Hunter (Okhotnik) sought to develop hybrids of bacteria and viruses such that use of an antibiotic to kill the bacteria would trigger release of the virus. "Unlike other national BW programs, which without exception used only classical or traditional applied microbiology techniques to weaponize agents, the post-1972 Soviet program had a futuristic aspect. By employing genetic manipulation and other molecular biology techniques, its scientists were able to breach barriers separating species...." ** The Soviet BW program appears to have taken advantage of the declassification in the 1970s of a large number of documents from the United States BW program. Thus, the design of the Soviet Gshch-304 BW bomblet was found to closely resemble that of the declassified US E-130R2 bomblet. In 2001, the US Government moved to reclassify many documents on the US BW program, but "nothing could be done about recalling reports that had been distributed relatively freely for more than 35 years." ** The quality of US intelligence about the Soviet BW program left much to be desired. "Intelligence about Soviet BW-related activities is relatively thin for the pre-1972 period; meager and often of dubious value during 1970-1979; and a little less meager and of better quality during 1980-1990." After 1990, little has been declassified. "There is an unknown number of still-classified reports concerning the Soviet BW program produced by the CIA and perhaps by other agencies that we do not have," the authors write. The state of declassification is such that "we have been able to collect far more information" about the history of Soviet BW activities from interviews with former Soviet scientists and others than from declassified official records. ** In what the authors term "a horrendous mistake by the United States," the US government undertook a covert deception and disinformation program aimed at the Soviet Union in the late 1960s which implied falsely that the US had a clandestine biological weapons program. This unfortunate campaign may have reinforced an existing Soviet belief that the US had never terminated its own offensive BW program, a belief that lent impetus, if not legitimacy, to the Soviet BW program. ** Today, the situation with respect to BW in the former Soviet Union is "ambiguous and unsatisfactory," Leitenberg and Zilinskas write. "There remains the possibility that Russia maintains portions of an offensive BW program in violation of the BWC." Alternatively, "since we do not actually know what is and has been taking place within the three [Ministry of Defense BW] facilities since 1992, perhaps the situation is better than might be feared." In 23 chapters, the authors painstakingly examine many facets of the history, structure and operation of the Soviet BW program. They scrupulously cite prior scholarship on the subject, while sorting out verifiable fact, plausible inference, dubious speculation, and error or fabrication. (Thus, "No SS-18 ICBM bomblet delivery system was ever completed, none was ever tested, and obviously none could ever have been employed.") But even after 900 pages of often dense text, "there are large gaps in our understanding of the Soviet BW program" and "readers are cautioned that much remains to be discovered." "We have not been able to resolve definitively some of the most important questions," they observe. Unanswered questions involve basic issues such as the motivation and purpose of the program. Why did the Soviet Union pursue the development and acquisition of biological weapons? Who was to be targeted by Soviet biological weapons b the US? China? Europe? b and under what conceivable circumstances? And what happens now? Following a brief period during the Yeltsin years during which Russian officials acknowledged this activity, "Russia's current official position is that no offensive BW program had existed in the Soviet Union." * * * The History of the Soviet Biological Weapons Program was reviewed by author David E. Hoffman in Foreign Policy last month. http://hoffman.foreignpolicy.com/posts/2012/06/17/why_did_they_do_it In 2010 the US Government signed an agreement with the former Soviet Republic of Armenia to cooperate in the control or destruction of dangerous pathogens, and in other efforts to prevent proliferation of biological weapons. The agreement, one of several such documents, was published earlier this year. http://www.fas.org/irp/threat/cbw/armenia-2010.pdf PUBLISHING SCIENTIFIC PAPERS WITH POTENTIAL SECURITY RISKS The recent controversy over publication of scientific papers concerning the transmissibility of bird flu virus was reviewed in a new report by the Congressional Research Service. The report cautiously elucidates the relevant policy implications and considers the responses available to Congress. "Because of the complexity of dual-use issues, analysis of a topic according to one set of policy priorities may lead to unforeseen complications due to its intersection with other policy priorities," the report says. "For example, maximizing security may lead to detriments in public health and scientific advancement, while maximizing scientific advancement may lead to security risks." See "Publishing Scientific Papers with Potential Security Risks: Issues for Congress," July 12, 2012: http://www.fas.org/sgp/crs/secrecy/R42606.pdf FY2013 DEFENSE AUTHORIZATION, AND MORE FROM CRS Some other new and updated reports from the Congressional Research Service that have not been made readily available to the public include the following. Defense: FY2013 Authorization and Appropriations, July 13, 2012: http://www.fas.org/sgp/crs/natsec/R42607.pdf The Unified Command Plan and Combatant Commands: Background and Issues for Congress, July 17, 2011: http://www.fas.org/sgp/crs/natsec/R42077.pdf LIBOR: Frequently Asked Questions, July 16, 2012: http://www.fas.org/sgp/crs/misc/R42608.pdf The 2001 and 2003 Bush Tax Cuts and Deficit Reduction, July 16, 2012: http://www.fas.org/sgp/crs/misc/R42020.pdf Guatemala: Political, Security, and Socio-Economic Conditions and U.S. Relations, June 26, 2012: http://www.fas.org/sgp/crs/row/R42580.pdf _______________________________________________ Secrecy News is written by Steven Aftergood and published by the Federation of American Scientists. The Secrecy News Blog is at: http://www.fas.org/blog/secrecy/ To SUBSCRIBE to Secrecy News, go to: http://www.fas.org/sgp/news/secrecy/subscribe.html To UNSUBSCRIBE, go to http://www.fas.org/sgp/news/secrecy/unsubscribe.html OR email your request to saftergood(a)fas.org Secrecy News is archived at: http://www.fas.org/sgp/news/secrecy/index.html Support the FAS Project on Government Secrecy with a donation: http://www.fas.org/member/donate_today.html _______________________ Steven Aftergood Project on Government Secrecy Federation of American Scientists web: www.fas.org/sgp/index.html email: saftergood(a)fas.org voice: (202) 454-4691 twitter: @saftergood ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [cryptography] Bitcoin-mining Botnets observed in the wild? (was: Re: Bitcoin in endgame
by Adam Back 06 Jul '18

06 Jul '18

Strikes me 12TH/sec is not actually very much computation? http://bitcoinwatch.com/ also gives network hashrate at 12.4 TH/sec. But a single normally clocked (925Mhz) AMD 7970 based graphics card which has 2048 cores is claimed to provide 555MH/sec. https://en.bitcoin.it/wiki/Mining_hardware_comparison#ARM (ignore the aggresively overclocked 7970s... the one that counts has 925 in the clock speed column!) But that means the entire bitcoin network compute is only equivalent to 23 AMD 7970 GPUs? That seems wrong by orders of magnitude, there are youtube videos of private individuals with mining rigs in that range in their garage. (Somewhat amusing scale of raw compute being thrown via SHA256 hashcash at the bitcoin core at this thing- still its arguably not wasted CPU because as human endeavours go other forms of currencies have their costs too. So a p2p currency if it played out might save a lot. Personally I lost a bundle on major currency devaluation GBP, EUR, USD look at them against the CHF to see how much you'all lost due to whatever human / political inefficiencies you attribute currency devaluation on that scale to. A stable mechanism for value storage would be a rather useful instrument.) Adam On Fri, May 11, 2012 at 01:20:48PM -0600, Zooko Wilcox-O'Hearn wrote: > Folks: > > Here's a copy of a post I just made to my Google+ account about this > alleged Botnet herder who has been answering questions about his > operation on reddit: > > https://plus.google.com/108313527900507320366/posts/1oi1v7RxR1i > > === introduction === > > Someone is posting to reddit claiming to be a malware author, botnet > operator, and that they use their Botnet to mine Bitcoin: B9. > > I asked them a question about the economics of using a Botnet for the > Bitcoin distributed transaction-verification service ("Bitcoin > mining"): B2. > > They haven't provided any proof of their claims, but on the other hand > what they write and how they write it sounds plausible to me. > > > === details === > > Here are my notes where I try to double-check their numbers and see if > they make sense. > > They in their initial post B9 that they do 13-20 gigahashes/sec of work > on the Bitcoin distributed transaction verification service. > > The screenshot they provided B3 shows 10.6 gigahashes/sec (GH/s) in > progress, and that they're using a mining pool named BTCGuild. > According to this chart of mining pools b4, BTCGuild currently totals > about 12.5% of all known hashing power, and according to b5 the current > total hashing power on the network is about 12.5 terahashes/sec > (TH/s), so BTCGuild probably accounts for about 1.5 TH/s. > > They say that their Botnet has about 10,000 bots. The screen shot > shows a count of "total bots" = 12,000 and "connected in the last 24 > hours" = 3500. This ratio of total bots to bots connected in the last > 24 hours is consistent with other reports I've read of Botnets b6, and > also consistent with my experience in p2p networking. The number of > "live bots" available at any one time for this Botnet herder should > probably average out to somewhere between 350 and 550. Let's pick 500 > as an easy number to work with. Does it makes sense that 500 bots > could generate 10 GH/s? That's 20 MH/s per live bot. According to the > Bitcoin wiki's page on mining hardware b7, a typical widely-available > GPU should provide about 200 MH/s. Hm, so they are claiming only 1/10 > the total hashpower that our back-of-the-envelope estimates would > assign to them. Here is an answer they give to another person's > question that sheds light on this: b8. > > Q: "Isn't Bitcoin mining pretty resource intensive on a computer? Like > to the point someone would notice something is up on their system form > it slowing eveyrthing down?" > > A: "My Botnet only mines if the computer is unused for 2 minutes and > if the owner gets back it stops mining immidiatly, so it doesn't suck > your fps at MW3. Also it mines as low priority so movies don't lag. I > also set up a very safe threshold, the cards work at around 60% so > they don't get overheated and the fans don't spin as crazy." > > It sounds plausible to me that those stealth measures could cut the > throughput by 10 compared to running flat-out 24/7. Also it isn't > clear if the botnet counts computers that don't have a GPU at all, or > don't have a usable one. Maybe such computers are rare nowadays? > Anyway if they are counted in there then that would be another reason > why the hashing throughput per bot is lower than I calculated. > > In answer to another question B9b0, they said they get a steady $40/day > from running the Bitcoin transaction-confirmation ("mining") service. > According to this chart B9B9 from B9B2, the current U.S. Dollar value of > Bitcoin mining is (or was a couple of days ago when they wrote that) > about $0.33 per day for 100 MH/s. Multiplying that out by their claim > of 10.6 GH/s results in $35/day. So that adds up, too. > > (Note that it sounds like their primary business is stealing and > selling credit card numbers, and the Bitcoin transaction-verification > service is a sideline.) > > I don't see a reason to doubt that they really generate about 10.6 > GH/s of the Bitcoin distributed transaction verification service. > > My primary question is: if this is profitable on a per-bot basis, then > why don't they scale up their operation? Of course, the answer to this > presumably sheds light on the related question of why competitors of > theirs don't launch similar operations. Perhaps one limiting factor is > that the larger your Botnet, the more likely you'll be arrested by > police or extorted by competitors. That may be a limiting factor that > this person doesn't yet know about or doesn't like to think about. > They mentioned b9 that most of their fellow cybercriminals are "too > inexperienced to accept Bitcoin", so it may be that this person is > just ahead of the curve and more people will launch operations like > this in the future. > > That's the question that I asked them on redditbwhy don't they scale > up? They haven't yet replied to my question, but they earlier > mentioned in response to a different question b9: > > Q: "How many botted machines do you typically gain per month or per campaign." > > A: "about 500-1000 a day, weekends more. I'm thinking about just > buying them in bulks and milking them for bitcoins. Asian installs are > very cheap, 15$/1000 installs and have good GPUs." > > If they're really gaining 500 to 1000 new bots per day but they have a > total of only 12,000 then either their operation is rapidly expanding, > or the attrition rate is similarly high as the acquisition rate. > > > === the bottom line and my take === > > I don't see any reason to doubt that this is real, and that this > person with their Botnet is responsible for about 0.08% (i.e. less > than 1/1000 b not 8%!) of the total Bitcoin distributed > transaction-verification service, and that they profit for it at the > rate of about $35 per day. > > There's one open question in my mind about whether this particular > operator is currently rapidly expanding (adding 1000 bots per day to > their network of 12,000 bots) or if the attrition rate of bots > departing from the 12,000-node network is close to 1000 per day. > > If the $35/day revenue is really mostly profit (i.e., they don't have > to spend so much time maintaining their 12,000-node Botnet that they > forego more profitable activities, like stealing more credit cards or > finishing their homework), I would expect them and others like them to > turn more and more bots to this purpose. > > However, the nature of Bitcoin is that all providers of distributed > transaction-confirmation service are in competition with one another. > In the two weeks since this post went up on reddit, people around the > globe deployed about 2 TH/s more hash power (see this graph of > aggregate Bitcoin hash power b5), which cut the profitability of this > one person's operation from $35.00/day to $30.00/day. If more and more > Botnet operators get into the Bitcoin mining game, they will reduce > the profitability of Bitcoin mining. (As well as competing with each > other for access to victim computers, which has got to be a limited > resources, right? Right? Or is there just a practically infinite > supply of vulnerable computers waiting to be tapped if only someone > can find a way to profit from them?) > > In parallel, the legitimate Bitcoin miners appear to be continuing to > roll out new distributed transaction-verification service on their own > hardware. Here is a recent post by "Bitcoinminer" about commercial > Bitcoin farms based on GPU: B9B3. The operation spotlighted in that post > apparently delivers 100 GH/s (about 10X that of our Botnet herder). At > the same time, sales of FPGA-based Bitcoin devices appear to be > booming. I wrote a post about that: B9b4. You'll have to scroll down > through extensive discussion to find where I summarized the numbers, > but in summary it appears that people are in the process of investing > half a million USD in Bitcoin FPGA which, when all deployed, will > deliver around 430 GH/s. > > I think there may be a kind of "Game of Chicken" going on: if someone > makes a convincing show of investing in Bitcoin mining then they may > deter other people from getting into the game and dividing up the > profits. That may be the subtext of Bitcoinminer's blog postbhe may be > trying to discourage competitors. An interesting thing about "Game of > Chicken" is that large upfront costs can actually be an advantage > because they demonstrate your commitment! If people are spending half > a million dollars on FPGA Bitcoin miners, then their competitors had > better believe they're really going to keep running them, even if > competition drives down profitability. > > See, to deploy 10 GH/s of Bitcoin hash power using FPGA would require > you to purchase about $10,000 worth of hardware which has no resell > value except to other Bitcoin miners. To deploy 10 GH/s using GPU > would require an outlay on about $5000 of hardware, which you could > later resell for gaming (or whatever other uses GPUs have nowadays -- > CAD/CAM?). To deploy 10 GH/s using a Botnet requires an unknown-to-me > outlay of time, money, skill, or risk of personal harm, but at least > the marginal cost of adding another few MH/s seems much lower than in > the hardware-based approach. Our Botnet herder on reddit said he could > buy access to Asian PCs with good GPUs for $15 for 1000 PCs. If that's > true then it should cost a piddling $180 to set up a new network as > big as his current 10 GH/s network. > > However, if he is considering doing something else with his time and > money, then the fact that people have convincingly committed to > large-scale FGPA mining may deter him, because no matter how well he > does at competing with them, they've already paid a sunk cost, and > their marginal cost for electricity is low, so they won't quit. > (Unless competition swells to such a level that it drives revenue > below their cost of electricity, which seems like a distant prospect > at this point.) Thus they might win at the Game of Chicken and > persuade him to spend his time and money on different projects (such > stealing more credit cards or doing a better job on his homework). > > (There are also several organizations who are loudly proclaiming that > they're developing custom ASIC chips for Bitcoin mining. I haven't yet > seen hard evidence of any of them having really spent substantial > money on it or having demonstrable progress on the engineering and > manufacturing.) > > > === last word === > > I'm delighted to see such vigorous and varied competition for > contributing to the distributed, planet-wide transaction-confirmation > service. I especially like the "sunk-cost" people such as the FPGA > miners with their low electricity requirements, because they seem > likely to be long-term, always-on contributors. > > > B9 http://www.reddit.com/r/IAmA/comments/sq7cy/iama_a_malware_coder_and_botnet… > > B2 http://www.reddit.com/r/IAmA/comments/sq7cy/iama_a_malware_coder_and_botnet… > > B3 https://lafsgateway.zooko.com/file/URI:CHK:sdk72a5zmncihhmhdsremrglem:ez25w… > > b4 http://blockorigin.pfoe.be/chart.php > > b5 http://bitcoin.sipa.be > > b6 http://blog.damballa.com/?p=330 > > b7 https://en.bitcoin.it/wiki/Mining_Hardware_Comparison > > b8 http://www.reddit.com/r/IAmA/comments/sq7cy/iama_a_malware_coder_and_botnet… > > b9 http://www.reddit.com/r/IAmA/comments/sq7cy/iama_a_malware_coder_and_botnet… > > B9b0 http://www.reddit.com/r/IAmA/comments/sq7cy/iama_a_malware_coder_and_botnet… > > B9B9 http://bitcoinx.com/charts/chart_large_lin_30d.png > > B9B2 http://bitcoinx.com/charts/ > > B9B3 http://www.bitcoinminer.com/post/22769728108/commercial-mining-farms > > B9b4 https://plus.google.com/108313527900507320366/posts/2ztAhLnXQK > _______________________________________________ > cryptography mailing list > cryptography(a)randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [cryptography] Bitcoin-mining Botnets observed in the wild? (was: Re: Bitcoin in endgame
by Adam Back 06 Jul '18

06 Jul '18

Strikes me 12TH/sec is not actually very much computation? http://bitcoinwatch.com/ also gives network hashrate at 12.4 TH/sec. But a single normally clocked (925Mhz) AMD 7970 based graphics card which has 2048 cores is claimed to provide 555MH/sec. https://en.bitcoin.it/wiki/Mining_hardware_comparison#ARM (ignore the aggresively overclocked 7970s... the one that counts has 925 in the clock speed column!) But that means the entire bitcoin network compute is only equivalent to 23 AMD 7970 GPUs? That seems wrong by orders of magnitude, there are youtube videos of private individuals with mining rigs in that range in their garage. (Somewhat amusing scale of raw compute being thrown via SHA256 hashcash at the bitcoin core at this thing- still its arguably not wasted CPU because as human endeavours go other forms of currencies have their costs too. So a p2p currency if it played out might save a lot. Personally I lost a bundle on major currency devaluation GBP, EUR, USD look at them against the CHF to see how much you'all lost due to whatever human / political inefficiencies you attribute currency devaluation on that scale to. A stable mechanism for value storage would be a rather useful instrument.) Adam On Fri, May 11, 2012 at 01:20:48PM -0600, Zooko Wilcox-O'Hearn wrote: > Folks: > > Here's a copy of a post I just made to my Google+ account about this > alleged Botnet herder who has been answering questions about his > operation on reddit: > > https://plus.google.com/108313527900507320366/posts/1oi1v7RxR1i > > === introduction === > > Someone is posting to reddit claiming to be a malware author, botnet > operator, and that they use their Botnet to mine Bitcoin: B9. > > I asked them a question about the economics of using a Botnet for the > Bitcoin distributed transaction-verification service ("Bitcoin > mining"): B2. > > They haven't provided any proof of their claims, but on the other hand > what they write and how they write it sounds plausible to me. > > > === details === > > Here are my notes where I try to double-check their numbers and see if > they make sense. > > They in their initial post B9 that they do 13-20 gigahashes/sec of work > on the Bitcoin distributed transaction verification service. > > The screenshot they provided B3 shows 10.6 gigahashes/sec (GH/s) in > progress, and that they're using a mining pool named BTCGuild. > According to this chart of mining pools b4, BTCGuild currently totals > about 12.5% of all known hashing power, and according to b5 the current > total hashing power on the network is about 12.5 terahashes/sec > (TH/s), so BTCGuild probably accounts for about 1.5 TH/s. > > They say that their Botnet has about 10,000 bots. The screen shot > shows a count of "total bots" = 12,000 and "connected in the last 24 > hours" = 3500. This ratio of total bots to bots connected in the last > 24 hours is consistent with other reports I've read of Botnets b6, and > also consistent with my experience in p2p networking. The number of > "live bots" available at any one time for this Botnet herder should > probably average out to somewhere between 350 and 550. Let's pick 500 > as an easy number to work with. Does it makes sense that 500 bots > could generate 10 GH/s? That's 20 MH/s per live bot. According to the > Bitcoin wiki's page on mining hardware b7, a typical widely-available > GPU should provide about 200 MH/s. Hm, so they are claiming only 1/10 > the total hashpower that our back-of-the-envelope estimates would > assign to them. Here is an answer they give to another person's > question that sheds light on this: b8. > > Q: "Isn't Bitcoin mining pretty resource intensive on a computer? Like > to the point someone would notice something is up on their system form > it slowing eveyrthing down?" > > A: "My Botnet only mines if the computer is unused for 2 minutes and > if the owner gets back it stops mining immidiatly, so it doesn't suck > your fps at MW3. Also it mines as low priority so movies don't lag. I > also set up a very safe threshold, the cards work at around 60% so > they don't get overheated and the fans don't spin as crazy." > > It sounds plausible to me that those stealth measures could cut the > throughput by 10 compared to running flat-out 24/7. Also it isn't > clear if the botnet counts computers that don't have a GPU at all, or > don't have a usable one. Maybe such computers are rare nowadays? > Anyway if they are counted in there then that would be another reason > why the hashing throughput per bot is lower than I calculated. > > In answer to another question B9b0, they said they get a steady $40/day > from running the Bitcoin transaction-confirmation ("mining") service. > According to this chart B9B9 from B9B2, the current U.S. Dollar value of > Bitcoin mining is (or was a couple of days ago when they wrote that) > about $0.33 per day for 100 MH/s. Multiplying that out by their claim > of 10.6 GH/s results in $35/day. So that adds up, too. > > (Note that it sounds like their primary business is stealing and > selling credit card numbers, and the Bitcoin transaction-verification > service is a sideline.) > > I don't see a reason to doubt that they really generate about 10.6 > GH/s of the Bitcoin distributed transaction verification service. > > My primary question is: if this is profitable on a per-bot basis, then > why don't they scale up their operation? Of course, the answer to this > presumably sheds light on the related question of why competitors of > theirs don't launch similar operations. Perhaps one limiting factor is > that the larger your Botnet, the more likely you'll be arrested by > police or extorted by competitors. That may be a limiting factor that > this person doesn't yet know about or doesn't like to think about. > They mentioned b9 that most of their fellow cybercriminals are "too > inexperienced to accept Bitcoin", so it may be that this person is > just ahead of the curve and more people will launch operations like > this in the future. > > That's the question that I asked them on redditbwhy don't they scale > up? They haven't yet replied to my question, but they earlier > mentioned in response to a different question b9: > > Q: "How many botted machines do you typically gain per month or per campaign." > > A: "about 500-1000 a day, weekends more. I'm thinking about just > buying them in bulks and milking them for bitcoins. Asian installs are > very cheap, 15$/1000 installs and have good GPUs." > > If they're really gaining 500 to 1000 new bots per day but they have a > total of only 12,000 then either their operation is rapidly expanding, > or the attrition rate is similarly high as the acquisition rate. > > > === the bottom line and my take === > > I don't see any reason to doubt that this is real, and that this > person with their Botnet is responsible for about 0.08% (i.e. less > than 1/1000 b not 8%!) of the total Bitcoin distributed > transaction-verification service, and that they profit for it at the > rate of about $35 per day. > > There's one open question in my mind about whether this particular > operator is currently rapidly expanding (adding 1000 bots per day to > their network of 12,000 bots) or if the attrition rate of bots > departing from the 12,000-node network is close to 1000 per day. > > If the $35/day revenue is really mostly profit (i.e., they don't have > to spend so much time maintaining their 12,000-node Botnet that they > forego more profitable activities, like stealing more credit cards or > finishing their homework), I would expect them and others like them to > turn more and more bots to this purpose. > > However, the nature of Bitcoin is that all providers of distributed > transaction-confirmation service are in competition with one another. > In the two weeks since this post went up on reddit, people around the > globe deployed about 2 TH/s more hash power (see this graph of > aggregate Bitcoin hash power b5), which cut the profitability of this > one person's operation from $35.00/day to $30.00/day. If more and more > Botnet operators get into the Bitcoin mining game, they will reduce > the profitability of Bitcoin mining. (As well as competing with each > other for access to victim computers, which has got to be a limited > resources, right? Right? Or is there just a practically infinite > supply of vulnerable computers waiting to be tapped if only someone > can find a way to profit from them?) > > In parallel, the legitimate Bitcoin miners appear to be continuing to > roll out new distributed transaction-verification service on their own > hardware. Here is a recent post by "Bitcoinminer" about commercial > Bitcoin farms based on GPU: B9B3. The operation spotlighted in that post > apparently delivers 100 GH/s (about 10X that of our Botnet herder). At > the same time, sales of FPGA-based Bitcoin devices appear to be > booming. I wrote a post about that: B9b4. You'll have to scroll down > through extensive discussion to find where I summarized the numbers, > but in summary it appears that people are in the process of investing > half a million USD in Bitcoin FPGA which, when all deployed, will > deliver around 430 GH/s. > > I think there may be a kind of "Game of Chicken" going on: if someone > makes a convincing show of investing in Bitcoin mining then they may > deter other people from getting into the game and dividing up the > profits. That may be the subtext of Bitcoinminer's blog postbhe may be > trying to discourage competitors. An interesting thing about "Game of > Chicken" is that large upfront costs can actually be an advantage > because they demonstrate your commitment! If people are spending half > a million dollars on FPGA Bitcoin miners, then their competitors had > better believe they're really going to keep running them, even if > competition drives down profitability. > > See, to deploy 10 GH/s of Bitcoin hash power using FPGA would require > you to purchase about $10,000 worth of hardware which has no resell > value except to other Bitcoin miners. To deploy 10 GH/s using GPU > would require an outlay on about $5000 of hardware, which you could > later resell for gaming (or whatever other uses GPUs have nowadays -- > CAD/CAM?). To deploy 10 GH/s using a Botnet requires an unknown-to-me > outlay of time, money, skill, or risk of personal harm, but at least > the marginal cost of adding another few MH/s seems much lower than in > the hardware-based approach. Our Botnet herder on reddit said he could > buy access to Asian PCs with good GPUs for $15 for 1000 PCs. If that's > true then it should cost a piddling $180 to set up a new network as > big as his current 10 GH/s network. > > However, if he is considering doing something else with his time and > money, then the fact that people have convincingly committed to > large-scale FGPA mining may deter him, because no matter how well he > does at competing with them, they've already paid a sunk cost, and > their marginal cost for electricity is low, so they won't quit. > (Unless competition swells to such a level that it drives revenue > below their cost of electricity, which seems like a distant prospect > at this point.) Thus they might win at the Game of Chicken and > persuade him to spend his time and money on different projects (such > stealing more credit cards or doing a better job on his homework). > > (There are also several organizations who are loudly proclaiming that > they're developing custom ASIC chips for Bitcoin mining. I haven't yet > seen hard evidence of any of them having really spent substantial > money on it or having demonstrable progress on the engineering and > manufacturing.) > > > === last word === > > I'm delighted to see such vigorous and varied competition for > contributing to the distributed, planet-wide transaction-confirmation > service. I especially like the "sunk-cost" people such as the FPGA > miners with their low electricity requirements, because they seem > likely to be long-term, always-on contributors. > > > B9 http://www.reddit.com/r/IAmA/comments/sq7cy/iama_a_malware_coder_and_botnet… > > B2 http://www.reddit.com/r/IAmA/comments/sq7cy/iama_a_malware_coder_and_botnet… > > B3 https://lafsgateway.zooko.com/file/URI:CHK:sdk72a5zmncihhmhdsremrglem:ez25w… > > b4 http://blockorigin.pfoe.be/chart.php > > b5 http://bitcoin.sipa.be > > b6 http://blog.damballa.com/?p=330 > > b7 https://en.bitcoin.it/wiki/Mining_Hardware_Comparison > > b8 http://www.reddit.com/r/IAmA/comments/sq7cy/iama_a_malware_coder_and_botnet… > > b9 http://www.reddit.com/r/IAmA/comments/sq7cy/iama_a_malware_coder_and_botnet… > > B9b0 http://www.reddit.com/r/IAmA/comments/sq7cy/iama_a_malware_coder_and_botnet… > > B9B9 http://bitcoinx.com/charts/chart_large_lin_30d.png > > B9B2 http://bitcoinx.com/charts/ > > B9B3 http://www.bitcoinminer.com/post/22769728108/commercial-mining-farms > > B9b4 https://plus.google.com/108313527900507320366/posts/2ztAhLnXQK > _______________________________________________ > cryptography mailing list > cryptography(a)randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

FC: FBI arrests Russian hacker visiting U.S. for alleged DMCA breach
by Declan McCullagh 06 Jul '18

06 Jul '18

http://www.wired.com/news/politics/0,1283,45298,00.html Russian Adobe Hacker Busted By Declan McCullagh (declan(a)wired.com) 7:04 a.m. July 17, 2001 PDT LAS VEGAS -- FBI agents have arrested a Russian programmer for giving away software that removes the restrictions on encrypted Adobe Acrobat files. Dmitry Sklyarov, a lead programmer for Russian software company ElcomSoft, was visiting the United States for the annual Defcon hacker convention, where he gave a talk on the often-flawed security of e-books. This would be the second known prosecution under the criminal sections of the controversial Digital Millennium Copyright Act, (DMCA) which took effect last year and makes it a crime to "manufacture" products that circumvent copy protection safeguards. [...] ------------------------------------------------------------------------- POLITECH -- Declan McCullagh's politics and technology mailing list You may redistribute this message freely if you include this notice. To subscribe, visit http://www.politechbot.com/info/subscribe.html This message is archived at http://www.politechbot.com/ ------------------------------------------------------------------------- ----- End forwarded message -----

1 0