July 2018 - cypherpunks-legacy

CRYPTO-GRAM, May 15, 2011
by Bruce Schneier 06 Jul '18

06 Jul '18

CRYPTO-GRAM May 15, 2011 by Bruce Schneier Chief Security Technology Officer, BT schneier(a)schneier.com http://www.schneier.com A free monthly newsletter providing summaries, analyses, insights, and commentaries on security: computer and otherwise. For back issues, or to subscribe, visit <http://www.schneier.com/crypto-gram.html>. You can read this issue on the web at <http://www.schneier.com/crypto-gram-1105.html>. These same essays and news items appear in the "Schneier on Security" blog at <http://www.schneier.com/blog>, along with a lively comment section. An RSS feed is available. ** *** ***** ******* *********** ************* In this issue: Status Report: "The Dishonest Minority" RFID Tags Protecting Hotel Towels News Hijacking the Coreflood Botnet Schneier News Drugging People and Then Robbing Them Interviews with Me About the Sony Hack ** *** ***** ******* *********** ************* Status Report: "The Dishonest Minority" Three months ago, I announced that I was writing a book on why security exists in human societies. This is basically the book's thesis statement: All complex systems contain parasites. In any system of cooperative behavior, an uncooperative strategy will be effective -- and the system will tolerate the uncooperatives -- as long as they're not too numerous or too effective. Thus, as a species evolves cooperative behavior, it also evolves a dishonest minority that takes advantage of the honest majority. If individuals within a species have the ability to switch strategies, the dishonest minority will never be reduced to zero. As a result, the species simultaneously evolves two things: 1) security systems to protect itself from this dishonest minority, and 2) deception systems to successfully be parasitic. Humans evolved along this path. The basic mechanism can be modeled simply. It is in our collective group interest for everyone to cooperate. It is in any given individual's short-term self-interest not to cooperate: to defect, in game theory terms. But if everyone defects, society falls apart. To ensure widespread cooperation and minimal defection, we collectively implement a variety of societal security systems. Two of these systems evolved in prehistory: morals and reputation. Two others evolved as our social groups became larger and more formal: laws and technical security systems. What these security systems do, effectively, is give individuals incentives to act in the group interest. But none of these systems, with the possible exception of some fanciful science-fiction technologies, can ever bring that dishonest minority down to zero. In complex modern societies, many complications intrude on this simple model of societal security. Decisions to cooperate or defect are often made by groups of people -- governments, corporations, and so on -- and there are important differences because of dynamics inside and outside the groups. Much of our societal security is delegated -- to the police, for example -- and becomes institutionalized; the dynamics of this are also important. Power struggles over who controls the mechanisms of societal security are inherent: "group interest" rapidly devolves to "the king's interest." Societal security can become a tool for those in power to remain in power, with the definition of "honest majority" being simply the people who follow the rules. The term "dishonest minority" is not a moral judgment; it simply describes the minority who does not follow societal norm. Since many societal norms are in fact immoral, sometimes the dishonest minority serves as a catalyst for social change. Societies without a reservoir of people who don't follow the rules lack an important mechanism for societal evolution. Vibrant societies need a dishonest minority; if society makes its dishonest minority too small, it stifles dissent as well as common crime. At this point, I have most of a first draft: 75,000 words. The tentative title is still "The Dishonest Minority: Security and its Role in Modern Society." I have signed a contract with Wiley to deliver a final manuscript in November for February 2012 publication. Writing a book is a process of exploration for me, and the final book will certainly be a little different -- and maybe even very different -- from what I wrote above. But that's where I am today. And it's why my other writings -- and the issues of Crypto-Gram -- continue to be sparse. Lots of comments -- over 200 -- to the blog post. Please comment there; I want the feedback. http://www.schneier.com/blog/archives/2011/02/societal_securi.html ** *** ***** ******* *********** ************* RFID Tags Protecting Hotel Towels The stealing of hotel towels isn't a big problem in the scheme of world problems, but it can be expensive for hotels. Sure, we have moral prohibitions against stealing -- that'll prevent most people from stealing the towels. Many hotels put their name or logo on the towels. That works as a reputational societal security system; most people don't want their friends to see obviously stolen hotel towels in their bathrooms. Sometimes, though, this has the opposite effect: making towels and other items into souvenirs of the hotel and thus more desirable to steal. It's against the law to steal hotel towels, of course, but with the exception of large-scale thefts, the crime will never be prosecuted. (This might be different in third world countries. In 2010, someone was sentenced to three months in jail for stealing two towels from a Nigerian hotel.) The result is that more towels are stolen than hotels want. And for expensive resort hotels, those towels are expensive to replace. The only thing left for hotels to do is take security into their own hands. One system that has become increasingly common is to set prices for towels and other items -- this is particularly common with bathrobes -- and charge the guest for them if they disappear from the rooms. This works with some things, but it's too easy for the hotel to lose track of how many towels a guest has in his room, especially if piles of them are available at the pool. A more recent system, still not widespread, is to embed washable RFID chips into the towels and track them that way. The one data point I have for this is an anonymous Hawaii hotel that claims they've reduced towel theft from 4,000 a month to 750, saving $16,000 in replacement costs monthly. Assuming the RFID tags are relatively inexpensive and don't wear out too quickly, that's a pretty good security trade-off. Blog entry URL: http://www.schneier.com/blog/archives/2011/05/rfid_tags_prote.html Stealing hotel items: http://today.msnbc.msn.com/id/31046570 Nigerian case: http://travel.usatoday.com/hotels/post/2010/09/woman-faces-jailed-for-steal… or http://tinyurl.com/3z7p98w RFID chips in towels: http://intransit.blogs.nytimes.com/2011/04/11/gee-how-did-that-towel-end-up… or http://tinyurl.com/6bp4lkr ** *** ***** ******* *********** ************* News WikiLeaks cable about Chinese hacking of U.S. networks: http://www.schneier.com/blog/archives/2011/04/wikileaks_cable.html Increasingly, chains of evidence include software steps. It's not just the RIAA suing people -- and getting it wrong -- based on automatic systems to detect and identify file sharers. It's forensic programs used to collect and analyze data from computers and smart phones. It's audit logs saved and stored by ISPs and websites. It's location data from cell phones. It's e-mails and IMs and comments posted to social networking sites. It's tallies from digital voting machines. It's images and meta-data from surveillance cameras. The list goes on and on. We in the security field know the risks associated with trusting digital data, but this evidence is routinely assumed by courts to be accurate. Sergey Bratus is starting to look at this problem. His paper, written with Ashlyn Lembree and Anna Shubina, is "Software on the Witness Stand: What Should it Take for Us to Trust it?." http://www.schneier.com/blog/archives/2011/04/software_as_evi.html Interesting blog post on the security costs for the $50B Air Force bomber program -- estimated to be $8B. This isn't all computer security, but the original article specifically calls out Chinese computer espionage as a primary threat. http://taosecurity.blogspot.com/2011/04/apt-drives-up-bomber-cost.html A criminal gang is stealing truckloads of food. It's a professional operation. The group knew how wholesale foodstuff trucking worked. They set up a bogus trucking company. They bid for jobs, collected the trailers, and disappeared. Presumably they knew how to fence the goods, too. http://www.nytimes.com/2011/04/15/business/15bandits.html The CIA has just declassified six documents about World War I security techniques. (The media is reporting they're CIA documents, but the CIA didn't exist before 1947.) Lots of stuff about secret writing and pre-computer tradecraft. http://www.foia.cia.gov/CIAsOldest/Secret-writing-document-one.pdf http://www.foia.cia.gov/CIAsOldest/Secret-writing-document-two.pdf http://www.foia.cia.gov/CIAsOldest/Secret-writing-document-three.pdf http://www.foia.cia.gov/CIAsOldest/Secret-writing-document-four.pdf http://www.foia.cia.gov/CIAsOldest/Secret-writing-document-five.pdf http://www.foia.cia.gov/CIAsOldest/Secret-writing-document-six.pdf http://www.fas.org/blog/secrecy/2011/04/cia_wwi.html http://www.huffingtonpost.com/2011/04/19/cia-world-war-one-documents-declas… or http://tinyurl.com/6h5e6zg Hard-drive steganography through fragmentation: http://www.newscientist.com/article/mg21028095.200-covert-hard-drive-fragme… or http://tinyurl.com/4xz4vc5 http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6V8G-51BBKRS-1&_u… or http://tinyurl.com/3cyhves As I've written before, I run an open wi-fi network. After the stories of people being arrested and their homes being invaded based on other people using their networks to download child porn, I rethought that position -- and decided I *still* want to run an open wireless network. http://arstechnica.com/tech-policy/news/2011/04/fbi-child-porn-raid-a-stron… or http://tinyurl.com/3nvokkh http://www.schneier.com/blog/archives/2008/01/my_open_wireles.html The EFF is calling for an open wireless movement. https://www.eff.org/deeplinks/2011/04/open-wireless-movement It's standard sociological theory that a group experiences social solidarity in response to external conflict. This paper studies the phenomenon in the United States after the 9/11 terrorist attacks. http://septembereleven2001.files.wordpress.com/2010/06/collins_2004_rituals… or http://tinyurl.com/3oxwkm5 http://onlinelibrary.wiley.com/doi/10.1111/j.1467-9558.2004.00204.x/abstract or http://tinyurl.com/3moz2en Good paper: "Loving the Cyber Bomb? The Dangers of Threat Inflation in Cybersecurity Policy," by Jerry Brito and Tate Watkins. http://mercatus.org/publication/loving-cyber-bomb-dangers-threat-inflation-… or http://tinyurl.com/3dcahg3 http://arstechnica.com/security/news/2011/04/are-we-talking-cyber-war-like-… or http://tinyurl.com/3pdmlou Also worth reading is an earlier paper by Sean Lawson: "Beyond Cyber Doom." http://mercatus.org/publication/beyond-cyber-doom "ReallyVirtual" tweeted the bin Laden assassination without realizing it. http://chirpstory.com/li/1288 The Nikon image authentication has been cracked. http://blog.crackpassword.com/2011/04/nikon-image-authentication-system-com… or http://tinyurl.com/4yv49pw http://www.theregister.co.uk/2011/04/28/nikon_image_faking_hack/ Canon's system is just as bad, by the way. http://www.elcomsoft.com/canon.html Fifteen years ago, I co-authored a paper on the problem. The idea was to use a hash chain to better deal with the possibility of a secret-key compromise. http://www.schneier.com/paper-camera.html According to this article, students are no longer learning how to write in cursive. And, if they are learning it, they're forgetting how. Certainly the ubiquity of keyboards is leading to a decrease in writing by hand. Relevant to security, the article claims that this is making signatures easier to forge. I'm skeptical. Everyone has a scrawl of some sort; mine has been completely illegible for years. But I don't see document forgery as a big risk; far bigger is the automatic authentication systems that don't have anything to do with traditional forgery. http://www.nytimes.com/2011/04/28/us/28cursive.html Unintended security consequences of the new Pyrex recipe: because it's no longer useful in cooking crack cocaine, drug makers now have to steal better stuff from laboratories. http://www.popsci.com/science/article/2011-03/gray-matter-cant-take-heat or http://tinyurl.com/6967a22 "Operation Pumpkin": Wouldn't it have been great if this were not a joke: the security contingency in place if Kate Middleton tried to run away just before the wedding. http://www.theregister.co.uk/2011/04/28/operation_pumpkin/ Bin Laden's death causes spike in suspicious package reports. It's not that the risk is greater, it's that the fear is greater. http://www.schneier.com/blog/archives/2011/05/osamas_death_ca.html Exactly how did they confirm it was bin Laden's body? http://www.newscientist.com/article/dn20439-osama-bin-laden-how-dna-identif… or http://tinyurl.com/3vrate8 http://www.cnn.com/2011/HEALTH/05/02/bin.laden.body.id/index.html Here's a clever Web app that locates your stolen camera by searching the EXIF data on public photo databases for your camera's serial number. http://www.stolencamerafinder.com/ Forged memory: a scary development in rootkits. http://www.techrepublic.com/blog/security/forged-memory-fools-antimalware-a… or http://tinyurl.com/3dpxsyk New vulnerability in online payment system: the connection between the merchant site and PayPal. http://www.newscientist.com/article/mg21028095.600-hackers-trick-goods-out-… or http://tinyurl.com/3q3j4ob http://research.microsoft.com/pubs/145858/caas-oakland-final.pdf In online hacking, we've moved to the world of "steal everything." As both data storage and data processing becomes cheaper, more and more data is collected and stored. An unanticipated effect of this is that more and more data can be stolen and used. As the article says, data minimization is the most effective security tool against this sort of thing. But -- of course -- it's not in the database owner's interest to limit the data it collects; it's in the interests of those whom the data is about. http://www.bbc.co.uk/news/technology-13213632 Medieval tally stick discovered in Germany. Note the security built into this primitive contract system. Neither side can cheat -- alter the notches -- because if they do, the two sides won't match. http://www.schneier.com/blog/archives/2011/05/medieval_tally.html "Resilience of the Internet Interconnection Ecosystem," by Richard Clayton -- worth reading. http://www.lightbluetouchpaper.org/2011/04/12/resilience-of-the-internet-in… or http://tinyurl.com/69fcyql http://www.enisa.europa.eu/act/res/other-areas/inter-x/report/interx-report… or http://tinyurl.com/3kkzdmq http://www.enisa.europa.eu/act/res/other-areas/inter-x/report/interx-report… or http://tinyurl.com/3fmskr7 FBI surveillance tools: https://www.eff.org/deeplinks/2011/04/CIPAV_Post ** *** ***** ******* *********** ************* Hijacking the Coreflood Botnet Earlier this month, the FBI seized control of the Coreflood botnet and shut it down: "According to the filing, ISC, under law enforcement supervision, planned to replace the servers with servers that it controlled, then collect the IP addresses of all infected machines communicating with the criminal servers, and send a remote 'stop' command to infected machines to disable the Coreflood malware operating on them." This is a big deal; it's the first time the FBI has done something like this. My guess is that we're going to see a lot more of this sort of thing in the future; it's the obvious solution for botnets. Not that the approach is without risks: "'Even if we could absolutely be sure that all of the infected Coreflood botnet machines were running the exact code that we reverse-engineered and convinced ourselves that we understood,' said Chris Palmer, technology director for the Electronic Frontier Foundation, 'this would still be an extremely sketchy action to take. It's other people's computers and you don't know what's going to happen for sure. You might blow up some important machine.'" I just don't see this argument convincing very many people. Leaving Coreflood in place could blow up some important machine. And leaving Coreflood in place not only puts the infected computers at risk; it puts the whole Internet at risk. Minimizing the collateral damage is important, but this feels like a place where the interest of the Internet as a whole trumps the interest of those affected by shutting down Coreflood. The problem as I see it is the slippery slope. Because next, the RIAA is going to want to remotely disable computers they feel are engaged in illegal file sharing. And the FBI is going to want to remotely disable computers they feel are encouraging terrorism. And so on. It's important to have serious legal controls on this counterattack sort of defense. http://www.wired.com/threatlevel/2011/04/coreflood/ http://baylinks.com/blogs/?p=181 http://krebsonsecurity.com/2011/04/u-s-government-takes-down-coreflood-botn… or http://tinyurl.com/63qupg8 http://garwarner.blogspot.com/2011/04/bold-fbi-move-shutters-coreflood-bot.… or http://tinyurl.com/3koydsp ** *** ***** ******* *********** ************* Schneier News Last year, I spoke last year at a regional TED event: TEDxPSU. The talk is now on the TED website. http://on.ted.com/Schneier ** *** ***** ******* *********** ************* Interviews with Me About the Sony Hack These two interviews are what I get for giving interviews when I'm in a bad mood. For the record, I think Sony did a terrible job with its customers' security. I also think that most companies do a terrible job with customers' security, simply because there isn't a financial incentive to do better. And that most of us are pretty secure, despite that. One of my biggest complaints with these stories is how little actual information we have. We often don't know if any data was actually stolen, only that hackers had access to it. We rarely know how the data was accessed: what sort of vulnerability was used by the hackers. We rarely know the motivations of the hackers: were they criminals, spies, kids, or someone else? We rarely know if the data is actually used for any nefarious purposes; it's generally impossible to connect a data breach with a corresponding fraud incident. Given all of that, it's impossible to say anything useful or definitive about the attack. But the press always wants definitive statements. http://m.kotaku.com/5797602/dont-blame-sony-you-cant-trust-any-networks http://www.20minutes.fr/article/718918/bruce-schneier-une-intrusion-informa… ** *** ***** ******* *********** ************* Drugging People and Then Robbing Them This is a pretty scary criminal tactic from Turkey. Burglars dress up as doctors, and ring doorbells handing out pills under some pretense or another. They're actually powerful sedatives, and when people take them they pass out, and the burglars can ransack the house. According to the article, when the police tried the same trick with placebos, they got an 86% compliance rate. Kind of like a real-world version of those fake anti-virus programs that actually contain malware. http://au.news.yahoo.com/odd/a/-/odd/9268075/police-dress-up-as-doctors-to-… or http://tinyurl.com/3flomba ** *** ***** ******* *********** ************* Since 1998, CRYPTO-GRAM has been a free monthly newsletter providing summaries, analyses, insights, and commentaries on security: computer and otherwise. You can subscribe, unsubscribe, or change your address on the Web at <http://www.schneier.com/crypto-gram.html>. Back issues are also available at that URL. Please feel free to forward CRYPTO-GRAM, in whole or in part, to colleagues and friends who will find it valuable. Permission is also granted to reprint CRYPTO-GRAM, as long as it is reprinted in its entirety. CRYPTO-GRAM is written by Bruce Schneier. Schneier is the author of the best sellers "Schneier on Security," "Beyond Fear," "Secrets and Lies," and "Applied Cryptography," and an inventor of the Blowfish, Twofish, Threefish, Helix, Phelix, and Skein algorithms. He is the Chief Security Technology Officer of BT BCSG, and is on the Board of Directors of the Electronic Privacy Information Center (EPIC). He is a frequent writer and lecturer on security topics. See <http://www.schneier.com>. Crypto-Gram is a personal newsletter. Opinions expressed are not necessarily those of BT. Copyright (c) 2011 by Bruce Schneier. ** *** ***** ******* *********** ************* To unsubscribe, click this link: http://listserv.modwest.com/cgi-bin/wa?TICKET=NzM0MzAxIGV1Z2VuQExFSVRMLk9SR… ----- 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

[IP] DNA may tell police the surname of the criminal
by Dave Farber 06 Jul '18

06 Jul '18

-------- Original Message -------- Subject: DNA may tell police the surname of the criminal Date: Wed, 22 Feb 2006 13:09:16 +0000 From: Brian Randell <Brian.Randell(a)newcastle.ac.uk> To: dave(a)farber.net Hi Dave: >From today's (UK) Guardian: >How DNA may tell police the surname of the criminal > >Alok Jha >Wednesday February 22, 2006 >The Guardian > >Police will soon be able to predict the surnames of criminals whose >DNA is found at crime scenes, according to research published >yesterday. The technique would only work in finding men, however, as >it is based on identifying similarities in the Y chromosome, which >is passed from father to son. > >The technique relies on research carried out by University of >Leicester scientists into how Y chromosomes have spread through the >British population. They analysed these chromosomes in 150 pairs of >men with the same surname and found that, in a quarter of cases, the >pair had matching Y chromosomes. > >When the most common names were excluded from the list - Smith, >Jones, Williams and Taylor, for example - the chance that two men >with the same surname shared a Y chromosome jumped to 50%. The >research appears in the latest edition of Current Biology. > >Mark Jobling, a geneticist at the University of Leicester who led >the work, said the police would need a relatively small collection >of male DNA - around 40,000 people - to allow useful matches to be >made. "That sounds big but the national DNA database is nearly 100 >times bigger," he said. By matching the Y chromosome details of >unidentified DNA at a crime scene with the database, police would >get a list of potential surname matches. > >"That would allow you to prioritise suspects in your investigation," >said Dr Jobling. "If you have a lot of suspects - say a whole town >or something - you can say we have 50 names, are these names >represented here, if so let's go and interview these people." > >Y chromosomes are passed from father to son mostly unaltered. Once >in a while, they will acquire random mutations as they pass through >the generations. Some parts of the chromosome are known to mutate >less rapidly than others and, by mapping these differences, >scientists can create a tree showing the relationships between >different Y chromosomes. > >"If men fall in different branches of the tree, there's no way they >can be related to a recent male ancestor," said Dr Jobling. "If they >lie within the same branch, there is a chance they are, but it >doesn't prove it. > >"When we do that simple test, we find that a highly statistically >significant excess of pairs share a branch of the tree, much more >than we expect by chance." > >It is a surprising result, since there are plenty of reasons why >people might have the same surname but be unrelated: many names were >founded by more than one man, for example. There is also the issue >of illegitimacy. The researchers predicted that more than 1% of >children were illegitimate in each generation. Over many >generations, this could have built up a significant error. > >"Those two elements would act as a strong force to break any links," >said Dr Jobling. "It was a surprise that by choosing just pairs we >got a clear signal of sharing ancestors." http://www.guardian.co.uk/crime/article/0,,1715022,00.html -- School of Computing Science, University of Newcastle, Newcastle upon Tyne, NE1 7RU, UK EMAIL = Brian.Randell(a)ncl.ac.uk PHONE = +44 191 222 7923 FAX = +44 191 222 8232 URL = http://www.cs.ncl.ac.uk/~brian.randell/ ------------------------------------- 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

[tahoe-lafs-weekly-news] TWN 36
by Patrick R McDonald 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 ===================================================== Tahoe-LAFS Weekly News, issue number 36, July 16 2012 ===================================================== Welcome to the Tahoe-LAFS Weekly News (TWN). Tahoe-LAFS_ is a secure, distributed storage system. `View TWN on the web`_ *or* `subscribe to TWN`_. If you would like to view the "new and improved" TWN, complete with pictures; please take a `look`_. .. _Tahoe-LAFS: https://tahoe-lafs.org .. _View TWN on the web: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TahoeLAFSWeeklyNews .. _subscribe to TWN: https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news .. _look: https://tahoe-lafs.org/~marlowe/TWN36.html Announcement and News ===================== 1.9.2 Released - -------------- David-Sarah |davidsarah| `announced the release of Tahoe-LAFS 1.9.2`_. Tahoe-LAFS 1.9.2 is primarily a bugfix release which fixes regressions in mutable file support. Take a look at `NEWS`_ to see all the fixes. .. |davidsarah| image:: davidsarah_bw.png :height: 35 :alt: davidsarah :target: http://tahoe-lafs.org/trac/tahoe-lafs/wikiAboutUs .. _`announced the release of Tahoe-LAFS 1.9.2`: https://tahoe-lafs.org/pipermail/tahoe-dev/2012-July/007527.html .. _`NEWS`: https://tahoe-lafs.org/trac/tahoe-lafs/browser/NEWS.rst Glowing Quotes ============== b It's very well designed, a pleasure to see such a system.b b Geoffroy Couprie <geo.couprie(a)gmail.com> Tahoe-LAFS on Twitter ===================== Just heard #tahoe-lafs mentioned in a #HOPE9 lightning talk, Crypto Tools for Distributed Social Media [`0`_] Setting up Tahoe-LAFS over I2P. This is b& interesting! [`1`_] @KimDotcom checkout tahoe-lafs by @zooko [`2`_] .. _`0`: https://twitter.com/antagonismorg/status/224565359431270400 .. _`1`: https://twitter.com/UnOrigMoniker/status/224468401119178753 .. _`2`: https://twitter.com/sj_mackenzie/status/223697328404578304 - From the tahoe-dev Mailing List =============================== On the limits of the use cases for authenticated encryption - ----------------------------------------------------------- Zooko |zooko| `announced` Tahoe-LAFS's use case was discussed at `Directions in Authenticated Ciphers workshop`. Zooko decided "authenticated encryption" is not useless for Tahoe-LAFS use cases. He believes Tahoe-LAFS needs "public key authenticated encryption" instead of "symmetric key". .. |zooko| image:: zooko.png :height: 35 :alt: zooko :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs .. _`announced`: https://tahoe-lafs.org/pipermail/tahoe-dev/2012-July/007568.html .. _`Directions in Authenticated Ciphers workshop`: http://hyperelliptic.org/DIAC/ p2p or client/server (Introducers to gossip) - -------------------------------------------- `Discussion continues` on the introducers to gossip thread. The discussion centers on whether to continue with the client/server architecture or move to a p2p style architecture. Users of client/server most likely want: Which services? Each node operates, by default, only the services that the operator manually configured it to run. Even better you can install the software sufficient to run a specific kind of node, e.g. a storage server, without installing the software that would let it run other servers, such as introducers or storage clients (`#1694`_). Which IP addresses? Nodes do not automatically detect their own IP addresses, but instead use only the IP address that their sysadmin manually told them to use. This is especially important for tor and i2p people where any auto-discovered IP address threatens the user's safety (`#517`_). Which connections? You try to establish the prescribed TCP connection(s) to your server. If that fails, you log/announce failure. In the future you might even be able to configure it to run exclusively over HTTP(S) and then pass all of its connections through your HTTP proxies and Web Services tools (`#510`_, `#1007`_). (Although sysadmins may actually like the "try to connect to multiple IP/DNS addresses at once" feature, if it is sufficiently understandable and controllable to them. It would ease some headaches provided by the Amazon Web Services EC2 TCP/DNS infrastructure, for example.) How to handle NAT/firewall/inconveniently-behaving-router? If you can't establish a TCP connection to your prescribed target, then obviously you should not talk to it. Either some wise sysadmin doesn't want you to (firewall) or some stupid sysadmin has screwed up the network config and needs to fix it. In either case you should log failure and give up immediately. Reverse connections? Clients connect to servers. Servers do not connect to clients, clients do not connect to other clients, and servers do not connect to other servers (`#344`_). To violate this principle means you will receive a visit from your keen-eyed sysadmin who will want to know what the hell you are doing. Users of the p2p model probably want: Which services? Each node operates, by default, only the services that the operator manually configured it to run. Even better you can install the software sufficient to run a specific kind of node, e.g. a storage server, without installing the software that would let it run other servers, such as introducers or storage clients (`#1694`_). Which IP addresses? Nodes do not automatically detect their own IP addresses, but instead use only the IP address that their sysadmin manually told them to use. This is especially important for tor and i2p people where any auto-discovered IP address threatens the user's safety (`#517`_). Which connections? You try to establish the prescribed TCP connection(s) to your server. If that fails, you log/announce failure. In the future you might even be able to configure it to run exclusively over HTTP(S) and then pass all of its connections through your HTTP proxies and Web Services tools (`#510`_, `#1007`_). (Although sysadmins may actually like the "try to connect to multiple IP/DNS addresses at once" feature, if it is sufficiently understandable and controllable to them. It would ease some headaches provided by the Amazon Web Services EC2 TCP/DNS infrastructure, for example.) How to handle NAT/firewall/inconveniently-behaving-router? If you can't establish a TCP connection to your prescribed target, then obviously you should not talk to it. Either some wise sysadmin doesn't want you to (firewall) or some stupid sysadmin has screwed up the network config and needs to fix it. In either case you should log failure and give up immediately. Reverse connections? Clients connect to servers. Servers do not connect to clients, clients do not connect to other clients, and servers do not connect to other servers (`#344`_). To violate this principle means you will receive a visit from your keen-eyed sysadmin who will want to know what the hell you are doing . Users of a p2p model probably want: Which services? Each node operates, by default, multiple services -- storage server, storage client == web gateway, introducer/gossiper, and in the future other services like relay server (to help get around incomplete connectivity of the underlying network -- `#445`_). Which IP addresses? Nodes automatically detect their own IP addresses, such as by inspecting the output of "/sbin/ifconfig" or "route.exe", or opening a TCP connection to some helpful STUNT/ICE server and asking that server what IP address your packets appear to be coming from (`#50`_). Which connections? Nodes advertise multiple IP addresses / DNS names (possibly including those auto-discovered as above, plus any that were manually entered by the user (`#754`_), plus 127.0.0.1 or any globally-non-routeable IP addresses revealed by ifconfig, and possibly in the future including indirection through a relay server), peers attempt to connect to nodes on all advertised IP addresses / DNS names in parallel, then use whichever connections succeeded. How to handle NAT/firewall/inconveniently-behaving-router? Nodes utilize the latest and greatest Romulan packet technology, such as UPnP (`#49`_), "NAT hole punching" techniques (`#169`_) or even B5TP (`#1179`_) or relay service (`#445`_) to breeze through such impediments as though they weren't even there. Reverse connections? If a TCP connection is established from node A to node B, then B can use that in the "reverse direction" to make requests of A, just as well as A can use it to make requests of B. This means that if A is behind a firewall which allows outgoing but not incoming connections to be established, and A established an outgoing connection to B, then B can use A as a server, but C, which for some reason didn't get a connection from A, cannot use A as a server. (`#1086`_) .. _`#1694`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1694 .. _`#517`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/517 .. _`#510`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/510 .. _`#1007`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1007 .. _`#344`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/344 .. _`#445`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/445 .. _`#50`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/50 .. _`#754`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/754 .. _`#49`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/49 .. _`#169`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/169 .. _`#1179`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1179 .. _`#445`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/445 .. _`#1086`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1086 Patches Needing Review of the Week ================================== There are six (6) ticket still needing review for 1.10.0: * `#1777`_: cleanups to tests and mutables for 1.10 * `#166`_: command line order is problematic * `#937`_: 'tahoe run' doesn't work for an introducer node * `#1539`_: stop putting pkg_resources.require() into .tac files * `#1159`_: stop using .tac files: make it possible to change appname, Python package-directory name, perhaps other names * `#1693`_: flogtool doesn't get automatically provided There are two (2) tickets still needing review of 1.11.0: * `#1265`_: New Visualizer is insufficiently labelled/documented (plus layout problem) * `#1382`_: immutable peer selection refactoring and enhancements .. _`#1777`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1777 .. _`#166`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/166 .. _`#937`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/937 .. _`#1539`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1539 .. _`#1159`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1159 .. _`#1693`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1693 .. _`#1265`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1265 .. _`#1382`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1382 - ---- *The Tahoe-LAFS Weekly News is published once a week by The Tahoe-LAFS* *Software Foundation, President and Treasurer: Peter Secor* |peter| *. Scribes: Patrick "marlowe" McDonald* |marlowe| *, Zooko Wilcox-O'Hearn* *, Editor: Zooko.* `View TWN on the web`_ *or* `subscribe to TWN`_ *. Send your news stories to* `marlowe(a)antagonism.org`_ *b submission deadline: Friday night.* .. _marlowe(a)antagonism.org: mailto:marlowe@antagonism.org .. |peter| image:: psecor.jpg :height: 35 :alt: peter :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs .. |marlowe| image:: marlowe-x75-bw.jpg :height: 35 :alt: marlowe :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQBMLoAAoJEAT4nRyi0elyvJEP/3SSUW/kBS5gxCm9kMFTbJaf V9WIavIjmdOVCZ2WRsoV6X3+Z3oTM1JeKMM/7N+w3ACYLUA5d8GV1FkqHar3zPbD pwBLZKeNg+YgcCXfygFZTJl4nsde6JsRUDCzHcXXYL3uSnDgrPt+RfmStkSLs7Ce dcgKSOT/w+cTqrNPwaHmkC6xGMGn8O4IukvJAIeqhHlm5+7d43vfnRXfxAT8hgcG GXz23ZI3lTaxmSA3H3PhMwxsAGUTR28Mpv5F5YgGqHTQbGODwqwPBcGS/87Gi4U7 0a3YsYBzzkCVm3kTGdhmlxd2WXu5ffaaglLonOW6J7up04+vaB4XAp3BJ5Y/Cmmr YvZBWIw6r8PMvrFQ9LRN74EvYnYSDDqqxBXNRNcefZyuyojvcsZeLMP3zt4eC8lt pbH5r871zrSa3+X/cQ2iW4qSZwIPMOVODbWkesa2usQyWmLWzoLh/mjdW2xs/8mN nayWsSH615hv0kzi61giqesNyRkXTYz6Ubmzu5d3UQPPu7XxTlrnWywJ631iKuev ++JJ9Go9zwOqfu92OpmH5qS3GtF7mQ1bk4ZGyH1c16jSQWcmZZbd/CaR1+CzwPM0 VCCSkfPHmT5vPCBkvEk6ac89yiS8c8nww0h3GlFKLyr6Dz5/wL1ry6bvxDeM2gJv wBCaAbFXUMNrJah8sdB4 =/Nj8 -----END PGP SIGNATURE----- _______________________________________________ tahoe-lafs-weekly-news mailing list tahoe-lafs-weekly-news(a)tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news ----- 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

[p2p-hackers] Automatic reputation systems for P2P security?
by paul＠nmedia.net 06 Jul '18

06 Jul '18

I've seen several papers referencing advogato, among other things, and it seems like reputation/trust systems solve a lot of problems related to P2P misbehavior. For instance, clients can track other clients that send out bogus files, that report a file and then refuse to share it, that create bogus queueing data (big problem with Emule/Edonkey networks), that might outright lie or otherwise cheat/steal and attempt to disrupt a Chord network, etc. It seems that scalar trust systems aren't going to do it because it is fairly easy to cheat by creating fake nodes, etc. So the real trick is the "group" or vector trust metrics. However, that may solve the theoretical issue but I haven't seen any real examples of implementation. For instance, most of the papers referring to Advogato and Advogato-like systems are based on the client-server model. And to implement trust networks as it appears that they are done now, the shear amount of data necessary makes them pretty darned unwieldy. In addition, it is relatively well known (but time/bandwidth consuming) for a node to detect misbehaving nodes. But translating that to a trust metric, or even how to handle that on an implementation level has not been published anywhere. SO...is there anything out there on this sort of idea, especially on the implementation side? I mean...if this can be done in reality, then it has a whole host of uses even just in the small world of file sharing networks. As it stands, any trust metric that's been tried so far is easily tampered with by the clients. _______________________________________________ p2p-hackers mailing list p2p-hackers(a)zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

[p2p-hackers] Automatic reputation systems for P2P security?
by paul＠nmedia.net 06 Jul '18

06 Jul '18

I've seen several papers referencing advogato, among other things, and it seems like reputation/trust systems solve a lot of problems related to P2P misbehavior. For instance, clients can track other clients that send out bogus files, that report a file and then refuse to share it, that create bogus queueing data (big problem with Emule/Edonkey networks), that might outright lie or otherwise cheat/steal and attempt to disrupt a Chord network, etc. It seems that scalar trust systems aren't going to do it because it is fairly easy to cheat by creating fake nodes, etc. So the real trick is the "group" or vector trust metrics. However, that may solve the theoretical issue but I haven't seen any real examples of implementation. For instance, most of the papers referring to Advogato and Advogato-like systems are based on the client-server model. And to implement trust networks as it appears that they are done now, the shear amount of data necessary makes them pretty darned unwieldy. In addition, it is relatively well known (but time/bandwidth consuming) for a node to detect misbehaving nodes. But translating that to a trust metric, or even how to handle that on an implementation level has not been published anywhere. SO...is there anything out there on this sort of idea, especially on the implementation side? I mean...if this can be done in reality, then it has a whole host of uses even just in the small world of file sharing networks. As it stands, any trust metric that's been tried so far is easily tampered with by the clients. _______________________________________________ p2p-hackers mailing list p2p-hackers(a)zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

Re: [liberationtech] /. ITU Approves Deep Packet Inspection
by Petter Ericson 06 Jul '18

06 Jul '18

Reading the draft document provided by Asher, I find nowhere any reference to this being a required activity for any ISP. Instead, it talks mainly about how data flows between generalised entities (think "devices"). So no, if ITU received a more governing role of the internet, that would not _in itself_ lead to Y.2770 being a "required standard" to implement for all ISPs (and I have no idea how this would happen anyway, given it doesn't concern itself with specififying any actions for ISPs). There are legitimate uses for DPI, though the examples cited in the draft seems to be more about limiting BitTorrent traffic... So basically, the standard is probably going to do mostly these things: a) DPI equipment manufacturers can claim to be "standards compliant" which is a selling point in some circumstances b) DPI might get more widely accepted as a technique. It is up to us and other hackers to make sure that censorship and traffic discrimination is not. c) It might be slightly more easy for surveillance tech to interoperate between manufacturers, given that the main point of the standard is to suggest everyone output data and accept rules in a standard way. To be frank, I have been trying to find out what the fuss has been about regarding this standard and come up.. not blank, as it _is_ worrying that ITU is spending time on this shit, but at least I haven't found anything to inspire the absolutely massive shitstorm I have been seeing in certain places (e.g. /.). Is it just because it's the ITU doing it rather than, say, ISO or ANSI? Best /P On 05 December, 2012 - Nicholas Judd wrote: > Hi list, Nick from techPresident here. If I could tap into your hive-mind intelligence for a moment to help me be more precise about explaining why this is an issue, I would appreciate it ... > > Governments, intelligence organizations and assorted nogoodniks already use deep-packet inspection, so the declaration of a standard for DPI comes off as vaguely Orwellian but not news. I'm searching for a way to explain the privacy-advocate position on this is both accurately and concisely. > > The sense I get from CDT's blog post is that there are three reasons why this is more than just creepy in principle: > > 1. The standard outlines ways that, in the ITU's view, ISPs should structure their operations so that highly invasive surveillance can function; > 2. Under current governance, this standard could be as widely ignored as the <blink> tag, but ISPs could be forced to comply if the ITU becomes a must-follow standards-making body for the Internet b meaning all traffic in every ITU member state, in this extreme example, would be vulnerable by design; > 3. On principle, IETF and W3C don't address standards for surveillance, highlighting another way the ITU is ideologically removed from the way the Internet is now governed. > > Am I on target here? > > On Dec 5, 2012, at 12:41 PM, Cynthia Wong wrote: > > > The final version of the standard should show up here... eventually: > > > > http://www.itu.int/en/ITU-T/publications/Pages/latest.aspx > > > > http://www.itu.int/dms_pages/itu-t/rec/T-REC-RSS.xml > > > > > > > > -----Original Message----- > > From: liberationtech-bounces(a)lists.stanford.edu [mailto:liberationtech-bounces@lists.stanford.edu] On Behalf Of Asher Wolf > > Sent: Wednesday, December 05, 2012 7:38 AM > > To: liberationtech(a)lists.stanford.edu > > Subject: Re: [liberationtech] /. ITU Approves Deep Packet Inspection > > > > From http://committee.tta.or.kr : > > Revision of Y.2770 Requirements for #DPI in Next Generation Networks http://bit.ly/Yx0Sya (via @BetweenMyths) > > > > On 5/12/12 9:25 PM, Andre Rebentisch wrote: > >> Am 05.12.2012 10:27, schrieb Eugen Leitl: > >>> http://yro.slashdot.org/story/12/12/05/0115214/itu-approves-deep-pack > >>> et-inspection > >>> > >>> > >>> ITU Approves Deep Packet Inspection > >>> > >>> Posted by Soulskill on Tuesday December 04, @08:19PM > >>> > >>> from the inspect-my-encryption-all-you'd-like dept. > >>> > >>> dsinc sends this quote from Techdirt about the International > >>> Telecommunications Union's ongoing conference in Dubai that will have > >>> an effect on the internet everywhere: > >> The WCIT is a "diplomatic conference" for the rules governing the ITU, > >> the ITRs. It seems wrong to mix that with ongoing specific > >> standardisation work of the ITU. > >> > >> Anyway, interesting discussions over at circleid.com: > >> http://www.circleid.com/posts/20121203_wcit_off_to_a_flying_start/ > >> Apparently ITU fellows are disgruntled that they cannot control the > >> media coverage and complain about all the "misinformation". > >> > >> Best, > >> AndrC) > >> > >> > >> -- > >> Unsubscribe, change to digest, or change password at: > >> https://mailman.stanford.edu/mailman/listinfo/liberationtech > > > > -- > > Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech > > -- > > Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech > > -- > Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Petter Ericson (pettter(a)acc.umu.se) Telecomix Sleeper Jellyfish -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [cryptography] Tigerspike claims world first with Karacell for mobile security
by Jon Callas 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I took a look at it. Amusing. I didn't spend a lot of time on it. Probably not more than twice what it took me to write this. It has an obvious problem with known plaintext. You can work backward from known plaintext to get a piece of their "tumbler" and since the tumbler is just a big bitstring, work from there to pull out the whole thing. The encrypted Karacell file format has 64 bits that must decrypt to zero. Since encryption is an XOR onto a pseudo-one-time-pad, this leaks 64 bits of the tumbler. Similarly, the "checksum" at the end is a bunch of hash blocks of their special hash all XORed together. This doesn't work against malicious modificationp; you can cut-and-paste through XOR, etc. There are obvious vulnerabilities to linear and differential cryptanalysis. It is a lot of XORing on large-ish fixed longterm secrets with only bit-rotating through the secrets, and between the vulnerabilities of known plaintext as well as the leaks in it, I don't see a lot of long-term strength. I bet that you can use known structure of plaintext (like that it's ASCII/UTF8, let alone things like known headers on XML files) to start prying bits out of the tumblers and you just work backwards. But beyond that, it isn't even particularly fast. Since it needs a lot of bit extraction and rotations, I doubt it would be as fast as AES on a processor with AES-NI instructions. The whole thing is based on doing 16-bit calculations and some bit sliding; I don't expect it to be as fast as RC4 or some of the fast estream ciphers. Obviously, I could be missing something, but there are other errors of art that lead me to think there isn't a lot here. For example, if your basic encryption system is to take a one-time-pad and try to expand that out to more uses, zero constants are errors of art. You should know better. There are similar errors like easily deducible parameters that give more known plaintext. The author discusses using a text string directly as a key, which is very bad with his expansion system. He invented his own "message digest" functions, and they look like complete linear functions to me. They're in uncommented C that's light on indenting and whitespace. Confirmation bias might be making me miss something, but it's not like he made it easy for me. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFQ225dsTedWZOD3gYRArauAKC5vrbr9HKPd0a0NoXL+eVQq428uQCgiiFE GFlyVpZAY6w80CBqxXl2qHs= =gncJ -----END PGP SIGNATURE----- _______________________________________________ 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: [IP] more on E-mail intercept ruling - good grief!!
by Peter Swire 06 Jul '18

06 Jul '18

Dave: On VOIP interception, there is a statutory and a constitutional issue. The statutory issue is whether VOIP is a "wire" communication (like a phone call) or an "electronic" communication (like an e-mail or web communication). The Councilman court said that "wire" communications are considered "intercepted" even if they are in temporary storage. The key holding of the case was that "electronic" communications are not "intercepted" if the wiretap takes place while the communication is in temporary storage. "Wire communication" is defined as "any aural transfer made in whole or in part through the use of facilities for the transmission of communications by the aid of wire, cable or other like connection between the point of origin and the point of reception." I do not know whether a court has ruled on whether VOIP counts as a "wire communication." Quick research just now suggests we don't have a case on that yet. I can see arguments either way, based in part on whether a packet-switched communication counts as "aural." Under Councilman, if VOIP is an "electronic communication", then the provider therefore could intercept the VOIP calls for the provider's own use without it counting as an "interception." Providers already can intercept communications with user consent or to protect the system, but this would be blanket permission to intercept communications. The constitutional question is whether users have a "reasonable expectation of privacy" in VOIP phone calls. Since the 1960's, the Supreme Court has found a 4th Amendment protection for voice phone calls. Meanwhile, it has found no constitutional protection for stored records. In an article coming out shortly from the Michigan Law Review, I show why VOIP calls quite possibly will be found NOT to have constitutional protection under the 4th Amendment. It would then be up to Congress to fix this, or else have the Supreme Court change its doctrine to provide more protections against future wiretaps. Article at http://papers.ssrn.com/sol3/papers.cfm?abstract_id=490623 . Peter Prof. Peter P. Swire Moritz College of Law, Ohio State University John Glenn Scholar in Public Policy Research (240) 994-4142, www.peterswire.net -----Original Message----- From: owner-ip(a)v2.listbox.com [mailto:owner-ip@v2.listbox.com] On Behalf Of David Farber Sent: Thursday, July 01, 2004 12:12 PM To: Ip Subject: [IP] more on E-mail intercept ruling - good grief!! Begin forwarded message:

1 0

Re: [IP] E-mail intercept ruling - good grief!!
by Ed Belove 06 Jul '18

06 Jul '18

But Councilman argued that no violation of the Wiretap Act had occurred because the e-mails were copied while in "electronic storage" -- the messages were in the process of being routed through a network of servers to recipients. A scary thought: does this mean that VOIP packets can be copied from routers (by ISPs or anyone else) while they are "stored"? ------------------------------------- You are subscribed as peter(a)peterswire.net To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ------------------------------------- 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> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0