July 2018 - cypherpunks-legacy

[cryptography] RSA admits securID tokens have been compromised
by Adam Back 06 Jul '18

06 Jul '18

http://www.net-security.org/secworld.php?id=11122 "RSA has finally admitted publicly that the March breach into its systems has resulted in the compromise of their SecurID two-factor authentication tokens." I guess everyone was suspecting as much reading between the lines of what was said so far, but there it is. Adam _______________________________________________ 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

PGP Corp. Purchases PGP Desktop Encryption and Wireless Product
by Network Associates 06 Jul '18

06 Jul '18

Lines from NET August 19, 2002 Dear Customer, Today we are pleased to announce that PGP Corporation, a newly formed, venture-funded security company, has acquired the PGP desktop encryption and wireless product lines from Network Associates. As you know, prior to placing the products into maintenance mode, we were actively looking for a buyer that would continue the development and support of the technology. Network Associates has retained products developed using PGPsdk including McAfee E-Business Server for encrypted server-to-server file transfer, McAfee Desktop Firewall and McAfee VPN Client. These products will remain a part of Network Associates existing product portfolio and we will continue to develop them to meet your security needs. PGP Corporation has acquired PGPmail, PGPfile, PGPdisk, PGPwireless, PGPadmin and PGPkeyserver encryption software products for Win32 and Macintosh, PGPsdk encryption software development kit, and PGP Corporate Desktop for Macintosh. In addition to the technology, PGP Corporation has acquired all worldwide customer license agreements and technical support obligations. To ensure a seamless transition, Network Associates will work with PGP Corporation to support PGP customers through October 26, 2002. PGP Corporation will contact you shortly with details on its plans and product direction. We trust that you will have continued success with the PGP desktop and wireless encryption products through PGP Corporation. Network Associates appreciates your business and we value our continued relationship across our remaining product lines. Best Regards, Sandra England Executive Vice President, Business Development and Strategic Research Network Associates **************************************************************************************************** You have received this message because you are a subscriber to the Network Associates Web sites. To unsubscribe, please follow the instructions at the end of this message. This information update is available at no charge to all registered users of Network Associates Web site. * To change your email address, send a reply to this email address and to subscribe(a)nai.com with the words, "change-address" in the subject line. In the body of the message include your old and new email addresses with the original message. Use the following format for email changes: OLD: enduser(a)olddomain.com NEW: Joseph_User(a)newdomain.com ______________________________________________________________________ This message was sent by Network Associates, Inc. using Responsys Interact (TM). If you prefer not to receive future e-mail from Network Associates, Inc.: http://nai.rsc01.net/servlet/optout?gHpgJDWWBEkHoFpINJDJhtE0 To view our permission marketing policy: http://www.rsvp0.net --- 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

<nettime> Help Wanted: Internet Spy
by Jack 06 Jul '18

06 Jul '18

Interesting ad seen at http://www.rand.org/jobs: ***** Posting Title: Research Programmer Location: (S) Santa Monica Reference: 001241 Job Description: Research Programmer RAND is seeking a Research Programmer to work on various information technology, security and assurance projects in our Santa Monica office. It is preferred that the individual have familiarity with various applied psychological measures that can be used to help with information protection systems. Under general supervision, the research programmer will be expected to search, monitor and track information and software tools that relate and leverage off these measures in the context of information security. More generally, the position requires skills in searching for highly technical, computer-related information and programs within a variety of Internet and Web sources, and organizing and structuring this material in a database for a project's use. Educational Requirements: Bachelors degree (or equivalent experience) in Mathematics, Economics, Statistics, Computer Science, Engineering, or other quantitative or computer discipline. Master preferred. Coursework or experience must cover research methods, policy analysis, and critical infrastructure protection. Specific technical skills required: Thorough technical knowledge of current computer operating systems (e.g., Linux, Solaris, Open BSD, Windows), and programming languages (e.g., Lisp, Prolog, C, Perl). Must be extremely proficient in such Internet and Web technologies as anonymizing sites, IRC and "chat rooms," and downloading and investigating properties of hacker "toolkits" and related software. Ability to organize and structure information within a database for project use is mandatory. Related experience required: 3 - 5 years Type of experience required/preferred: Applicant should have excellent interpersonal skills, be able to conduct independent investigations of online sites, and participate in online dialogs (IRC, chats) by gaining the trust of relevant persons. Experience with the content and participants of such computer security conferences as the Black Hat Briefings, DEFCON, and CANSECWest/core03 would be useful. A security clearance is not required, but is desirable. Location: Santa Monica # distributed via <nettime>: no commercial use without permission # <nettime> is a moderated mailing list for net criticism, # collaborative text filtering and cultural politics of the nets # more info: majordomo(a)bbs.thing.net and "info nettime-l" in the msg body # archive: http://www.nettime.org contact: nettime(a)bbs.thing.net --- 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'

1 0

CRYPTO-GRAM, October 15, 2009
by Bruce Schneier 06 Jul '18

06 Jul '18

CRYPTO-GRAM October 15, 2009 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-0910.html>. These same essays appear in the "Schneier on Security" blog: <http://www.schneier.com/blog>. An RSS feed is available. ** *** ***** ******* *********** ************* In this issue: Ass Bomber News Unauthentication The Futility of Defending the Targets Schneier News Texas Instruments Signing Keys Broken The Doghouse UK Defense Security Manual Leaked Comments from Readers ** *** ***** ******* *********** ************* Ass Bomber Nobody tell the TSA, but last month someone tried to assassinate a Saudi prince by exploding a bomb stuffed in his rectum. He pretended to be a repentant militant, when in fact he was a Trojan horse: "The resulting explosion ripped al-Asiri to shreds but only lightly injured the shocked prince -- the target of al-Asiri's unsuccessful assassination attempt." For years, I have made the joke about Richard Reid: "Just be glad that he wasn't the underwear bomber." Now, sadly, we have an example of one. Lewis Page, an "improvised-device disposal operator tasked in support of the UK mainland police from 2001-2004," pointed out that this isn't much of a threat for three reasons: 1) you can't stuff a lot of explosives into a body cavity, 2) detonation is, um, problematic, and 3) the human body can stifle an explosion pretty effectively (think of someone throwing himself on a grenade to save his friends). But who ever accused the TSA of being rational? http://www.stratfor.com/weekly/20090902_aqap_paradigm_shifts_and_lessons_le… or http://tinyurl.com/ye9rdgg http://timesofindia.indiatimes.com/articleshow/msid-4951665,prtpage-1.cms or http://tinyurl.com/ybxvm5q http://www.stuff.co.nz/sunday-star-times/news/world/2833157/Bomb-in-anal-ca… or http://tinyurl.com/na7rbd http://homelandsecuritynewswire.com/single.php?id=8705 http://www.hlswatch.com/2009/09/18/anal-secrets-and-the-coming-tempest-in-h… or http://tinyurl.com/yds7vwg Page on the feasibility of the tactic: http://www.theregister.co.uk/2009/09/21/bum_bombing/ ** *** ***** ******* *********** ************* News Printing police handcuff keys using a 3D printer: http://blackbag.nl/?p=940 http://www.schneier.com/blog/archives/2009/09/printing_police.html#c393047 or http://tinyurl.com/yf66534 http://www.schneier.com/blog/archives/2009/09/printing_police.html#c393012 or http://tinyurl.com/yf6cj5e The DHS is considering modifying the color-coded threat alert system -- the useless system that's widely mocked -- by removing two of the five levels. I hope you all feel safer now. http://www.schneier.com/blog/archives/2009/09/modifying_the_c.html Good essay on "terrorist havens" -- like Afghanistan -- and why they're not as big a worry as some maintain. http://www.washingtonpost.com/wp-dyn/content/article/2009/09/15/AR200909150… or http://tinyurl.com/mvgc2c Inferring friendship from location data: http://www.schneier.com/blog/archives/2009/09/inferring_frien.html Back in 2005, I wrote about the failure of two-factor authentication to mitigate banking fraud. We're now seeing attacks that bypass that security measure. http://www.schneier.com/blog/archives/2009/09/hacking_two-fac.html Quantum computer factors the number 15. It's an important development, but don't give up on public-key cryptography just yet. http://www.schneier.com/blog/archives/2009/09/quantum_compute.html This is a good thing: "An Illinois district court has allowed a couple to sue their bank on the novel grounds that it may have failed to sufficiently secure their account, after an unidentified hacker obtained a $26,500 loan on the account using the customers' user name and password." As I've previously written, this is the only way to mitigate this kind of fraud. It's an important security principle: ensure that the person who has the ability to mitigate the risk is responsible for the risk. In this case, the account holders had nothing to do with the security of their account. They could not audit it. They could not improve it. The bank, on the other hand, has the ability to improve security and mitigate the risk, but because they pass the cost on to their customers, they have no incentive to do so. Litigation like this has the potential to fix the externality and improve security. http://www.schneier.com/blog/archives/2009/09/eliminating_the.html More information on the Monopoly sets with hidden escape information given to WWII POWs: http://www.abcnews.go.com/Technology/monopolys-hidden-maps-wwii-pows-escape… or http://tinyurl.com/lcjxut http://www.schneier.com/blog/archives/2007/12/monopoly_sets_w.html Sears spies on its customers; it's not just hackers who steal financial and medical information. http://www.walletpop.com/blog/2009/09/14/sears-gets-a-gentle-touch-to-the-w… or http://tinyurl.com/nznrmu The Sears story reminds me of the 2005 Sony rootkit, which -- oddly enough -- is in the news again, too: http://torrentfreak.com/retailer-must-compensate-sony-anti-piracy-rootkit-v… or http://tinyurl.com/o7j7qs "Authorities Called in to Examine Suspicious-Looking Ham," from the Onion: http://www.theonion.com/content/radio_news/authorities_called_in_to A stick figure guide to AES. http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html Predicting characteristics of people by the company they keep: http://www.schneier.com/blog/archives/2009/09/predicting_char.html The average American commits three felonies a day: the title of a new book by Harvey Silverglate. More specifically, the problem is the intersection of vague laws and fast-moving technology. http://www.schneier.com/blog/archives/2009/09/the_problem_of.html Immediacy affects risk assessments: http://www.sciencedaily.com/releases/2009/09/090923102405.htm During a daring bank robbery in Sweden that involved a helicopter, the criminals disabled a police helicopter by placing a package with the word "bomb" near the helicopter hangar, thus engaging the full caution/evacuation procedure while they escaped. This attack worked, even though the police had been warned. http://news.bbc.co.uk/2/hi/europe/8270619.stm http://www.youtube.com/watch?v=Bqc0NrI6iv0 http://www.thelocal.se/22260/20090924/ http://www.stockholmnews.com/more.aspx?NID=4044 Reproducing keys from distant and angled photographs: http://vision.ucsd.edu/~blaxton/sneakey.html Those of you who carry your keys on a ring dangling from a belt loop, take note. Proving a computer program's correctness: http://www.schneier.com/blog/archives/2009/10/proving_a_compu.html Security theater in New York for the U.N. General Assembly: http://politics.theatlantic.com/2009/09/for_those_entranced_by_security.php or http://tinyurl.com/nuqpda If you were curious what the DHS knows about you, here's an actual DHS travel record. http://philosecurity.org/2009/09/07/what-does-dhs-know-about-you Moving hippos in a post-9/11 world: http://www.schneier.com/blog/archives/2009/10/moving_hippos_i.html There's a Trojan horse out there that not only makes transactions in your name from your bank accounts, but alters your online bank statements so you won't notice the money transfers. If there's a moral here, it's that banks can't rely on the customer to detect fraud. But we already knew that. http://www.wired.com/threatlevel/2009/09/rogue-bank-statements/ http://news.bbc.co.uk/2/hi/technology/8271384.stm You'd think this would be an obvious piece of advice: don't let hacker inmates reprogram the prison's computers. But, then again, this is the same prison that gave a lockpicking inmate access to the prison's keys. What's next: inmate sharpshooters in charge of prison's gun locker? http://www.mirror.co.uk/news/top-stories/2009/09/27/conputer-meltdown-11587… or http://tinyurl.com/yedoph2 Witnesses are much more accurate at identifying criminals when computers assist in the identification process rather than police officers. http://www.newscientist.com/article/mg20327275.500-virtual-cop-to-run-ident… or http://tinyurl.com/yaoa86l Behavioral detection: detecting people who want to do harm: http://www.boston.com/news/science/articles/2009/09/18/spotting_a_terrorist/ or http://tinyurl.com/o6pajr Interesting hotel safe scam: http://www.schneier.com/blog/archives/2009/10/hotel_safe_scam.html Detecting forged signatures using pen pressure and angle: http://www.schneier.com/blog/archives/2009/10/detecting_forge.html Earlier this month, DHS Secretary Janet Napolitano said that the U.S. needed to hire 1,000 cybersecurity experts over the next three years. Bob Cringeley doubts that there even are 1,000 cybersecurity experts out there to hire. I suppose it depends on what she means by "experts." http://www.cnn.com/2009/POLITICS/10/02/dhs.cybersecurity.jobs/ http://www.cringely.com/2009/10/the-cybersecurity-myth/ Pigs defeating RFID-enabled feeding systems: http://www.youtube.com/watch?v=8ImZmDYme_s Using wi-fi to "see" through walls: http://www.wired.com/threatlevel/2009/10/see-through-walls/ Wi-fi blocking paint: http://news.bbc.co.uk/2/hi/technology/8279549.stm Good essay by David Dittrich: "Malware to crimeware: How far have they gone, and how do we catch up?" http://staff.washington.edu/dittrich/papers/dittrich-login0809.pdf The current state of P versus NP: http://cacm.acm.org/magazines/2009/9/38904-the-status-of-the-p-versus-np-pr… or http://tinyurl.com/n9amud 1777 steganography. http://www.lettersofnote.com/2009/10/masked-letter.html ** *** ***** ******* *********** ************* Unauthentication In computer security, a lot of effort is spent on the authentication problem. Whether it's passwords, secure tokens, secret questions, image mnemonics, or something else, engineers are continually coming up with more complicated -- and hopefully more secure -- ways for you to prove you are who you say you are over the Internet. This is important stuff, as anyone with an online bank account or remote corporate network knows. But a lot less thought and work have gone into the other end of the problem: how do you tell the system on the other end of the line that you're no longer there? How do you unauthenticate yourself? My home computer requires me to log out or turn my computer off when I want to unauthenticate. This works for me because I know enough to do it, but lots of people just leave their computers on and running when they walk away. As a result, many office computers are left logged in when people go to lunch, or when they go home for the night. This, obviously, is a security vulnerability. The most common way to combat this is by having the system time out. I could have my computer log me out automatically after a certain period of inactivity -- five minutes, for example. Getting it right requires some fine tuning, though. Log the person out too quickly, and he gets annoyed; wait too long before logging him out, and the system could be vulnerable during that time. My corporate e-mail server logs me out after 10 minutes or so, and I regularly get annoyed at my corporate e-mail system. Some systems have experimented with a token: a USB authentication token that has to be plugged in for the computer to operate, or an RFID token that logs people out automatically when the token moves more than a certain distance from the computer. Of course, people will be prone to just leave the token plugged in to their computer all the time; but if you attach it to their car keys or the badge they have to wear at all times when walking around the office, the risk is minimized. That's expensive, though. A research project used a Bluetooth device, like a cell phone, and measured its proximity to a computer. The system could be programmed to lock the computer if the Bluetooth device moved out of range. Some systems log people out after every transaction. This wouldn't work for computers, but it can work for ATMs. The machine spits my card out before it gives me my cash, or just requires a card swipe, and makes sure I take it out of the machine. If I want to perform another transaction, I have to reinsert my card and enter my PIN a second time. There's a physical analogue that everyone can explain: door locks. Does your door lock behind you when you close the door, or does it remain unlocked until you lock it? The first instance is a system that automatically logs you out, and the second requires you to log out manually. Both types of locks are sold and used, and which one you choose depends on both how you use the door and who you expect to try to break in. Designing systems for usability is hard, especially when security is involved. Almost by definition, making something secure makes it less usable. Choosing an unauthentication method depends a lot on how the system is used as well as the threat model. You have to balance increasing security with pissing the users off, and getting that balance right takes time and testing, and is much more an art than a science. Automatic logout: http://www.schneier.com/blog/archives/2009/06/protecting_agai.html Proximity logout: http://www.matthew.ath.cx/projects/bluemon/ This essay originally appeared on ThreatPost. http://threatpost.com/blogs/difficulty-un-authentication-128 ** *** ***** ******* *********** ************* The Futility of Defending the Targets This is just silly: Beaver Stadium is a terrorist target. It is most likely the No. 1 target in the region. As such, it deserves security measures commensurate with such a designation, but is the stadium getting such security? [..] When the stadium is not in use it does not mean it is not a target. It must be watched constantly. An easy solution is to assign police officers there 24 hours a day, seven days a week. This is how a plot to destroy the Brooklyn Bridge was thwarted -- police presence. Although there are significant costs to this, the costs pale in comparison if the stadium is destroyed or damaged. The idea is to create omnipresence, which is a belief in everyone's minds (terrorists and pranksters included) that the stadium is constantly being watched so that any attempt would be futile. Actually, the Brooklyn Bridge plot failed because the plotters were idiots and the plot -- cutting through cables with blowtorches -- was dumb. That, and the all-too-common police informant who egged the plotters on. But never mind that. Beaver Stadium is Pennsylvania State University's football stadium, and this article argues that it's a potential terrorist target that needs 24/7 police protection. The problem with that kind of reasoning is that it makes no sense. As I said in an article that will appear in "New Internationalist": To be sure, reasonable arguments can be made that some terrorist targets are more attractive than others: aeroplanes because a small bomb can result in the death of everyone aboard, monuments because of their national significance, national events because of television coverage, and transportation because of the numbers of people who commute daily. But there are literally millions of potential targets in any large country (there are five million commercial buildings alone in the US), and hundreds of potential terrorist tactics; it's impossible to defend every place against everything, and it's impossible to predict which tactic and target terrorists will try next. Defending individual targets only makes sense if the number of potential targets is few. If there are seven terrorist targets and you defend five of them, you seriously reduce the terrorists' ability to do damage. But if there are a million terrorist targets and you defend five of them, the terrorists won't even notice. I tend to dislike security measures that merely cause the bad guys to make a minor change in their plans. And the expense would be enormous. Add up these secondary terrorist targets -- stadiums, theaters, churches, schools, malls, office buildings, anyplace where a lot of people are packed together -- and the number is probably around 200,000, including Beaver Stadium. Full-time police protection requires people, so that's 1,000,000 policemen. At an encumbered cost of $100,000 per policeman per year, probably a low estimate, that's a total annual cost of $100B. (That's about what we're spending each year in Iraq.) On the other hand, hiring one out of every 300 Americans to guard our nation's infrastructure would solve our unemployment problem. And since policemen get health care, our health care problem as well. Just make sure you don't accidentally hire a terrorist to guard against terrorists -- that would be embarrassing. The whole idea is nonsense. As I've been saying for years, what works is investigation, intelligence, and emergency response: We need to defend against the broad threat of terrorism, not against specific movie plots. Security is most effective when it doesn't make arbitrary assumptions about the next terrorist act. We need to spend more money on intelligence and investigation: identifying the terrorists themselves, cutting off their funding, and stopping them regardless of what their plans are. We need to spend more money on emergency response: lessening the impact of a terrorist attack, regardless of what it is. And we need to face the geopolitical consequences of our foreign policy and how it helps or hinders terrorism. Beaver Stadium piece: http://www.centredaily.com/opinion/story/1548830.html Terrorists as idiots: http://www.schneier.com/essay-174.html Informants: http://www.cbsnews.com/stories/2009/05/22/opinion/main5034353.shtml My essay on investigation, intelligence, and emergency response: http://www.schneier.com/essay-087.html ** *** ***** ******* *********** ************* Schneier News I'm speaking at Information Security Decisions in Chicago on October 21. http://infosecuritydecisions.techtarget.com/infosecuritydecisions/html/inde… or http://tinyurl.com/ygqwx8l I'm speaking at the 4th International Workshop on Security in Toyama, Japan on October 28. http://www.iwsec.org/2009/ I'm speaking at the ISF Annual World Congress in Vancouver on November 2. https://www.securityforum.org/html/congres.htm I'm speaking at the Gartner Identity and Access Management Conference in San Diego on November 9. http://www.gartner.com/it/page.jsp?id=838920 I'm speaking at the Internet Governance Forum in Sharm el-Sheikh, Egypt, on November 15. http://igf09.eg/home.html ** *** ***** ******* *********** ************* Texas Instruments Signing Keys Broken Texas Instruments' calculators use RSA digital signatures to authenticate any updates to their operating system. Unfortunately, their signing keys are too short: 512 bits. Earlier this month, a collaborative effort factored the moduli and published the private keys. Texas Instruments responded by threatening websites that published the keys with the DMCA, but it's too late. So far, we have the operating-system signing keys for the TI-92+, TI-73, TI-89, TI-83+/TI-83+ Silver Edition, Voyage 200, TI-89 Titanium, and the TI-84+/TI-84 Silver Edition, and the date-stamp signing key for the TI-73, Explorer, TI-83 Plus, TI-83 Silver Edition, TI-84 Plus, TI-84 Silver Edition, TI-89, TI-89 Titanium, TI-92 Plus, and the Voyage 200. Moral: Don't assume that if your application is obscure, or if there's no obvious financial incentive for doing so, that your cryptography won't be broken if you use too-short keys. http://www.ticalc.org/archives/news/articles/14/145/145273.html http://wikileaks.org/wiki/Suppressed_Texas_Instruments_cryptographic_signin… or http://tinyurl.com/nrorec http://www.ticalc.org/archives/news/articles/14/145/145316.html http://en.wikipedia.org/wiki/Texas_Instruments_signing_key_controversy http://diomedes.phear.cc/~chronomex/keys.shtml http://88.80.16.63/leak/ti-os-keys-dmca-2009.txt ** *** ***** ******* *********** ************* The Doghouse Two entries this time. Crypteto: http://www.schneier.com/blog/archives/2009/09/the_doghouse_cr.html Privacy Inside: http://www.schneier.com/blog/archives/2009/10/the_doghouse_pr_1.html Both are entertaining to read. ** *** ***** ******* *********** ************* UK Defense Security Manual Leaked It's over 2,000 pages, so it'll take time to make any sense of. According to Ross Anderson, who's given it a quick look over, "it seems to be the bureaucratic equivalent of spaghetti code: a hodgepodge of things written by people from different backgrounds, and with different degrees of clue, in different decades." The computer security stuff starts at page 1,531. http://www.wikileaks.org/wiki/UK_MoD_Manual_of_Security_Volumes_1%2C_2_and_… or http://tinyurl.com/ybc4yxj http://www.theregister.co.uk/2009/10/05/leaked_defence_manual/ ** *** ***** ******* *********** ************* Comments from Readers There are thousands of comments -- many of them interesting -- on these topics on my blog. Search for the story you want to comment on, and join in. http://www.schneier.com/blog ** *** ***** ******* *********** ************* 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) 2009 by Bruce Schneier. ----- 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

CRYPTO-GRAM, October 15, 2009
by Bruce Schneier 06 Jul '18

06 Jul '18

CRYPTO-GRAM October 15, 2009 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-0910.html>. These same essays appear in the "Schneier on Security" blog: <http://www.schneier.com/blog>. An RSS feed is available. ** *** ***** ******* *********** ************* In this issue: Ass Bomber News Unauthentication The Futility of Defending the Targets Schneier News Texas Instruments Signing Keys Broken The Doghouse UK Defense Security Manual Leaked Comments from Readers ** *** ***** ******* *********** ************* Ass Bomber Nobody tell the TSA, but last month someone tried to assassinate a Saudi prince by exploding a bomb stuffed in his rectum. He pretended to be a repentant militant, when in fact he was a Trojan horse: "The resulting explosion ripped al-Asiri to shreds but only lightly injured the shocked prince -- the target of al-Asiri's unsuccessful assassination attempt." For years, I have made the joke about Richard Reid: "Just be glad that he wasn't the underwear bomber." Now, sadly, we have an example of one. Lewis Page, an "improvised-device disposal operator tasked in support of the UK mainland police from 2001-2004," pointed out that this isn't much of a threat for three reasons: 1) you can't stuff a lot of explosives into a body cavity, 2) detonation is, um, problematic, and 3) the human body can stifle an explosion pretty effectively (think of someone throwing himself on a grenade to save his friends). But who ever accused the TSA of being rational? http://www.stratfor.com/weekly/20090902_aqap_paradigm_shifts_and_lessons_le… or http://tinyurl.com/ye9rdgg http://timesofindia.indiatimes.com/articleshow/msid-4951665,prtpage-1.cms or http://tinyurl.com/ybxvm5q http://www.stuff.co.nz/sunday-star-times/news/world/2833157/Bomb-in-anal-ca… or http://tinyurl.com/na7rbd http://homelandsecuritynewswire.com/single.php?id=8705 http://www.hlswatch.com/2009/09/18/anal-secrets-and-the-coming-tempest-in-h… or http://tinyurl.com/yds7vwg Page on the feasibility of the tactic: http://www.theregister.co.uk/2009/09/21/bum_bombing/ ** *** ***** ******* *********** ************* News Printing police handcuff keys using a 3D printer: http://blackbag.nl/?p=940 http://www.schneier.com/blog/archives/2009/09/printing_police.html#c393047 or http://tinyurl.com/yf66534 http://www.schneier.com/blog/archives/2009/09/printing_police.html#c393012 or http://tinyurl.com/yf6cj5e The DHS is considering modifying the color-coded threat alert system -- the useless system that's widely mocked -- by removing two of the five levels. I hope you all feel safer now. http://www.schneier.com/blog/archives/2009/09/modifying_the_c.html Good essay on "terrorist havens" -- like Afghanistan -- and why they're not as big a worry as some maintain. http://www.washingtonpost.com/wp-dyn/content/article/2009/09/15/AR200909150… or http://tinyurl.com/mvgc2c Inferring friendship from location data: http://www.schneier.com/blog/archives/2009/09/inferring_frien.html Back in 2005, I wrote about the failure of two-factor authentication to mitigate banking fraud. We're now seeing attacks that bypass that security measure. http://www.schneier.com/blog/archives/2009/09/hacking_two-fac.html Quantum computer factors the number 15. It's an important development, but don't give up on public-key cryptography just yet. http://www.schneier.com/blog/archives/2009/09/quantum_compute.html This is a good thing: "An Illinois district court has allowed a couple to sue their bank on the novel grounds that it may have failed to sufficiently secure their account, after an unidentified hacker obtained a $26,500 loan on the account using the customers' user name and password." As I've previously written, this is the only way to mitigate this kind of fraud. It's an important security principle: ensure that the person who has the ability to mitigate the risk is responsible for the risk. In this case, the account holders had nothing to do with the security of their account. They could not audit it. They could not improve it. The bank, on the other hand, has the ability to improve security and mitigate the risk, but because they pass the cost on to their customers, they have no incentive to do so. Litigation like this has the potential to fix the externality and improve security. http://www.schneier.com/blog/archives/2009/09/eliminating_the.html More information on the Monopoly sets with hidden escape information given to WWII POWs: http://www.abcnews.go.com/Technology/monopolys-hidden-maps-wwii-pows-escape… or http://tinyurl.com/lcjxut http://www.schneier.com/blog/archives/2007/12/monopoly_sets_w.html Sears spies on its customers; it's not just hackers who steal financial and medical information. http://www.walletpop.com/blog/2009/09/14/sears-gets-a-gentle-touch-to-the-w… or http://tinyurl.com/nznrmu The Sears story reminds me of the 2005 Sony rootkit, which -- oddly enough -- is in the news again, too: http://torrentfreak.com/retailer-must-compensate-sony-anti-piracy-rootkit-v… or http://tinyurl.com/o7j7qs "Authorities Called in to Examine Suspicious-Looking Ham," from the Onion: http://www.theonion.com/content/radio_news/authorities_called_in_to A stick figure guide to AES. http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html Predicting characteristics of people by the company they keep: http://www.schneier.com/blog/archives/2009/09/predicting_char.html The average American commits three felonies a day: the title of a new book by Harvey Silverglate. More specifically, the problem is the intersection of vague laws and fast-moving technology. http://www.schneier.com/blog/archives/2009/09/the_problem_of.html Immediacy affects risk assessments: http://www.sciencedaily.com/releases/2009/09/090923102405.htm During a daring bank robbery in Sweden that involved a helicopter, the criminals disabled a police helicopter by placing a package with the word "bomb" near the helicopter hangar, thus engaging the full caution/evacuation procedure while they escaped. This attack worked, even though the police had been warned. http://news.bbc.co.uk/2/hi/europe/8270619.stm http://www.youtube.com/watch?v=Bqc0NrI6iv0 http://www.thelocal.se/22260/20090924/ http://www.stockholmnews.com/more.aspx?NID=4044 Reproducing keys from distant and angled photographs: http://vision.ucsd.edu/~blaxton/sneakey.html Those of you who carry your keys on a ring dangling from a belt loop, take note. Proving a computer program's correctness: http://www.schneier.com/blog/archives/2009/10/proving_a_compu.html Security theater in New York for the U.N. General Assembly: http://politics.theatlantic.com/2009/09/for_those_entranced_by_security.php or http://tinyurl.com/nuqpda If you were curious what the DHS knows about you, here's an actual DHS travel record. http://philosecurity.org/2009/09/07/what-does-dhs-know-about-you Moving hippos in a post-9/11 world: http://www.schneier.com/blog/archives/2009/10/moving_hippos_i.html There's a Trojan horse out there that not only makes transactions in your name from your bank accounts, but alters your online bank statements so you won't notice the money transfers. If there's a moral here, it's that banks can't rely on the customer to detect fraud. But we already knew that. http://www.wired.com/threatlevel/2009/09/rogue-bank-statements/ http://news.bbc.co.uk/2/hi/technology/8271384.stm You'd think this would be an obvious piece of advice: don't let hacker inmates reprogram the prison's computers. But, then again, this is the same prison that gave a lockpicking inmate access to the prison's keys. What's next: inmate sharpshooters in charge of prison's gun locker? http://www.mirror.co.uk/news/top-stories/2009/09/27/conputer-meltdown-11587… or http://tinyurl.com/yedoph2 Witnesses are much more accurate at identifying criminals when computers assist in the identification process rather than police officers. http://www.newscientist.com/article/mg20327275.500-virtual-cop-to-run-ident… or http://tinyurl.com/yaoa86l Behavioral detection: detecting people who want to do harm: http://www.boston.com/news/science/articles/2009/09/18/spotting_a_terrorist/ or http://tinyurl.com/o6pajr Interesting hotel safe scam: http://www.schneier.com/blog/archives/2009/10/hotel_safe_scam.html Detecting forged signatures using pen pressure and angle: http://www.schneier.com/blog/archives/2009/10/detecting_forge.html Earlier this month, DHS Secretary Janet Napolitano said that the U.S. needed to hire 1,000 cybersecurity experts over the next three years. Bob Cringeley doubts that there even are 1,000 cybersecurity experts out there to hire. I suppose it depends on what she means by "experts." http://www.cnn.com/2009/POLITICS/10/02/dhs.cybersecurity.jobs/ http://www.cringely.com/2009/10/the-cybersecurity-myth/ Pigs defeating RFID-enabled feeding systems: http://www.youtube.com/watch?v=8ImZmDYme_s Using wi-fi to "see" through walls: http://www.wired.com/threatlevel/2009/10/see-through-walls/ Wi-fi blocking paint: http://news.bbc.co.uk/2/hi/technology/8279549.stm Good essay by David Dittrich: "Malware to crimeware: How far have they gone, and how do we catch up?" http://staff.washington.edu/dittrich/papers/dittrich-login0809.pdf The current state of P versus NP: http://cacm.acm.org/magazines/2009/9/38904-the-status-of-the-p-versus-np-pr… or http://tinyurl.com/n9amud 1777 steganography. http://www.lettersofnote.com/2009/10/masked-letter.html ** *** ***** ******* *********** ************* Unauthentication In computer security, a lot of effort is spent on the authentication problem. Whether it's passwords, secure tokens, secret questions, image mnemonics, or something else, engineers are continually coming up with more complicated -- and hopefully more secure -- ways for you to prove you are who you say you are over the Internet. This is important stuff, as anyone with an online bank account or remote corporate network knows. But a lot less thought and work have gone into the other end of the problem: how do you tell the system on the other end of the line that you're no longer there? How do you unauthenticate yourself? My home computer requires me to log out or turn my computer off when I want to unauthenticate. This works for me because I know enough to do it, but lots of people just leave their computers on and running when they walk away. As a result, many office computers are left logged in when people go to lunch, or when they go home for the night. This, obviously, is a security vulnerability. The most common way to combat this is by having the system time out. I could have my computer log me out automatically after a certain period of inactivity -- five minutes, for example. Getting it right requires some fine tuning, though. Log the person out too quickly, and he gets annoyed; wait too long before logging him out, and the system could be vulnerable during that time. My corporate e-mail server logs me out after 10 minutes or so, and I regularly get annoyed at my corporate e-mail system. Some systems have experimented with a token: a USB authentication token that has to be plugged in for the computer to operate, or an RFID token that logs people out automatically when the token moves more than a certain distance from the computer. Of course, people will be prone to just leave the token plugged in to their computer all the time; but if you attach it to their car keys or the badge they have to wear at all times when walking around the office, the risk is minimized. That's expensive, though. A research project used a Bluetooth device, like a cell phone, and measured its proximity to a computer. The system could be programmed to lock the computer if the Bluetooth device moved out of range. Some systems log people out after every transaction. This wouldn't work for computers, but it can work for ATMs. The machine spits my card out before it gives me my cash, or just requires a card swipe, and makes sure I take it out of the machine. If I want to perform another transaction, I have to reinsert my card and enter my PIN a second time. There's a physical analogue that everyone can explain: door locks. Does your door lock behind you when you close the door, or does it remain unlocked until you lock it? The first instance is a system that automatically logs you out, and the second requires you to log out manually. Both types of locks are sold and used, and which one you choose depends on both how you use the door and who you expect to try to break in. Designing systems for usability is hard, especially when security is involved. Almost by definition, making something secure makes it less usable. Choosing an unauthentication method depends a lot on how the system is used as well as the threat model. You have to balance increasing security with pissing the users off, and getting that balance right takes time and testing, and is much more an art than a science. Automatic logout: http://www.schneier.com/blog/archives/2009/06/protecting_agai.html Proximity logout: http://www.matthew.ath.cx/projects/bluemon/ This essay originally appeared on ThreatPost. http://threatpost.com/blogs/difficulty-un-authentication-128 ** *** ***** ******* *********** ************* The Futility of Defending the Targets This is just silly: Beaver Stadium is a terrorist target. It is most likely the No. 1 target in the region. As such, it deserves security measures commensurate with such a designation, but is the stadium getting such security? [..] When the stadium is not in use it does not mean it is not a target. It must be watched constantly. An easy solution is to assign police officers there 24 hours a day, seven days a week. This is how a plot to destroy the Brooklyn Bridge was thwarted -- police presence. Although there are significant costs to this, the costs pale in comparison if the stadium is destroyed or damaged. The idea is to create omnipresence, which is a belief in everyone's minds (terrorists and pranksters included) that the stadium is constantly being watched so that any attempt would be futile. Actually, the Brooklyn Bridge plot failed because the plotters were idiots and the plot -- cutting through cables with blowtorches -- was dumb. That, and the all-too-common police informant who egged the plotters on. But never mind that. Beaver Stadium is Pennsylvania State University's football stadium, and this article argues that it's a potential terrorist target that needs 24/7 police protection. The problem with that kind of reasoning is that it makes no sense. As I said in an article that will appear in "New Internationalist": To be sure, reasonable arguments can be made that some terrorist targets are more attractive than others: aeroplanes because a small bomb can result in the death of everyone aboard, monuments because of their national significance, national events because of television coverage, and transportation because of the numbers of people who commute daily. But there are literally millions of potential targets in any large country (there are five million commercial buildings alone in the US), and hundreds of potential terrorist tactics; it's impossible to defend every place against everything, and it's impossible to predict which tactic and target terrorists will try next. Defending individual targets only makes sense if the number of potential targets is few. If there are seven terrorist targets and you defend five of them, you seriously reduce the terrorists' ability to do damage. But if there are a million terrorist targets and you defend five of them, the terrorists won't even notice. I tend to dislike security measures that merely cause the bad guys to make a minor change in their plans. And the expense would be enormous. Add up these secondary terrorist targets -- stadiums, theaters, churches, schools, malls, office buildings, anyplace where a lot of people are packed together -- and the number is probably around 200,000, including Beaver Stadium. Full-time police protection requires people, so that's 1,000,000 policemen. At an encumbered cost of $100,000 per policeman per year, probably a low estimate, that's a total annual cost of $100B. (That's about what we're spending each year in Iraq.) On the other hand, hiring one out of every 300 Americans to guard our nation's infrastructure would solve our unemployment problem. And since policemen get health care, our health care problem as well. Just make sure you don't accidentally hire a terrorist to guard against terrorists -- that would be embarrassing. The whole idea is nonsense. As I've been saying for years, what works is investigation, intelligence, and emergency response: We need to defend against the broad threat of terrorism, not against specific movie plots. Security is most effective when it doesn't make arbitrary assumptions about the next terrorist act. We need to spend more money on intelligence and investigation: identifying the terrorists themselves, cutting off their funding, and stopping them regardless of what their plans are. We need to spend more money on emergency response: lessening the impact of a terrorist attack, regardless of what it is. And we need to face the geopolitical consequences of our foreign policy and how it helps or hinders terrorism. Beaver Stadium piece: http://www.centredaily.com/opinion/story/1548830.html Terrorists as idiots: http://www.schneier.com/essay-174.html Informants: http://www.cbsnews.com/stories/2009/05/22/opinion/main5034353.shtml My essay on investigation, intelligence, and emergency response: http://www.schneier.com/essay-087.html ** *** ***** ******* *********** ************* Schneier News I'm speaking at Information Security Decisions in Chicago on October 21. http://infosecuritydecisions.techtarget.com/infosecuritydecisions/html/inde… or http://tinyurl.com/ygqwx8l I'm speaking at the 4th International Workshop on Security in Toyama, Japan on October 28. http://www.iwsec.org/2009/ I'm speaking at the ISF Annual World Congress in Vancouver on November 2. https://www.securityforum.org/html/congres.htm I'm speaking at the Gartner Identity and Access Management Conference in San Diego on November 9. http://www.gartner.com/it/page.jsp?id=838920 I'm speaking at the Internet Governance Forum in Sharm el-Sheikh, Egypt, on November 15. http://igf09.eg/home.html ** *** ***** ******* *********** ************* Texas Instruments Signing Keys Broken Texas Instruments' calculators use RSA digital signatures to authenticate any updates to their operating system. Unfortunately, their signing keys are too short: 512 bits. Earlier this month, a collaborative effort factored the moduli and published the private keys. Texas Instruments responded by threatening websites that published the keys with the DMCA, but it's too late. So far, we have the operating-system signing keys for the TI-92+, TI-73, TI-89, TI-83+/TI-83+ Silver Edition, Voyage 200, TI-89 Titanium, and the TI-84+/TI-84 Silver Edition, and the date-stamp signing key for the TI-73, Explorer, TI-83 Plus, TI-83 Silver Edition, TI-84 Plus, TI-84 Silver Edition, TI-89, TI-89 Titanium, TI-92 Plus, and the Voyage 200. Moral: Don't assume that if your application is obscure, or if there's no obvious financial incentive for doing so, that your cryptography won't be broken if you use too-short keys. http://www.ticalc.org/archives/news/articles/14/145/145273.html http://wikileaks.org/wiki/Suppressed_Texas_Instruments_cryptographic_signin… or http://tinyurl.com/nrorec http://www.ticalc.org/archives/news/articles/14/145/145316.html http://en.wikipedia.org/wiki/Texas_Instruments_signing_key_controversy http://diomedes.phear.cc/~chronomex/keys.shtml http://88.80.16.63/leak/ti-os-keys-dmca-2009.txt ** *** ***** ******* *********** ************* The Doghouse Two entries this time. Crypteto: http://www.schneier.com/blog/archives/2009/09/the_doghouse_cr.html Privacy Inside: http://www.schneier.com/blog/archives/2009/10/the_doghouse_pr_1.html Both are entertaining to read. ** *** ***** ******* *********** ************* UK Defense Security Manual Leaked It's over 2,000 pages, so it'll take time to make any sense of. According to Ross Anderson, who's given it a quick look over, "it seems to be the bureaucratic equivalent of spaghetti code: a hodgepodge of things written by people from different backgrounds, and with different degrees of clue, in different decades." The computer security stuff starts at page 1,531. http://www.wikileaks.org/wiki/UK_MoD_Manual_of_Security_Volumes_1%2C_2_and_… or http://tinyurl.com/ybc4yxj http://www.theregister.co.uk/2009/10/05/leaked_defence_manual/ ** *** ***** ******* *********** ************* Comments from Readers There are thousands of comments -- many of them interesting -- on these topics on my blog. Search for the story you want to comment on, and join in. http://www.schneier.com/blog ** *** ***** ******* *********** ************* 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) 2009 by Bruce Schneier. ----- 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

[tahoe-lafs-weekly-news] Tahoe-LAFS Weekly News #2
by Patrick R McDonald 06 Jul '18

06 Jul '18

Ladies and gentlemen, We proudly present issue #2 of the Tahoe Weekly News. -- ---------------------------------------------------------------- | Patrick R. McDonald GPG Key: 668AA5DF | | https://www.antagonism.org/ <marlowe(a)antagonism.org> | | <mcdonald.patrick.r(a)gmail.com> | | <patrick(a)opensecurityfoundation.org> | ---------------------------------------------------------------- | Malo periculosam libertatem quam quietum servitium | ---------------------------------------------------------------- ========================================== Tahoe-LAFS Weekly News, issue number 2 ========================================== Welcome to the Tahoe-LAFS Weekly News (TWN) brought to you by Patrick McDonald, scribe. Tahoe-LAFS_ is a secure, distributed storage. .. _Tahoe-LAFS: http://tahoe-lafs.org Announcements and News ====================== The 1.9.0 planning has begun. The development team is evicting tickets. Brian Wagner will be posting to the tahoe-dev list regarding the 1.9.0 schedule. Tuesday at the Tahoe Summit will be deep design day with Brian Wagner. While no specifics yet, deep design day will most likely cover accounting and `signed Introducer announcements`_. Both of these features Brian has been working on for a long time. He is looking for some assistance so he can land some code. Also up for discussion will be new capability formats as MDMF caps are due in the 1.9.0 release. .. _`signed Introducer announcements`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/466 David Triendl announced he is stepping down from his longstanding role as manager for the public demo test grid. TWN would like to extend our thanks to David for his supports. We greatly appreciate it. Charles Wyble volunteered to take over the role. Charles welcome aboard, we look forward to working with you. The tahoe-dev mailing list provided an interesting discussion regarding the access control policies Tahoe-LAFS offers. Two newcomers asked the list about these policies to which various "old timers" provided explanations. See `the mailing list archives`_ for the discussion and `the overview of Tahoe-LAFS`_ for a summary of access control features. .. _`the mailing list archives`: http://tahoe-lafs.org/pipermail/tahoe-dev/2011-June/date.html .. _`the overview of Tahoe-LAFS`: http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/about.rst#access-c… Tahoe is now a `special remote`_ for git-annex_. .. _`special remote`: http://git-annex.branchable.com/forum/tips:_special__95__remotes__47__hook_… .. _`git-annex`: http://git-annex.branchable.com `210 Bitcoins`_ have been pledged to integrate Tahoe-LAFS and Bitcoin. A new ticket, 1408_ was created in response to this bounty. .. _`210 Bitcoins`: http://forum.bitcoin.org/?topic=2236.0 .. _1408: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1408 Interview with the Developers ============================= This past week, TWN interview Kevan. Kevan is a member of the Tahoe-LAFS development team. Kevan is working on MDMF which is the major feature of the upcoming 1.9.0 release. Thank Kevan for taking the time for this interview. Patrick: First give us a little introduction. Tell us a bit about who you are? Kevan: My Name is Kevan. I am 24. I live near Los Angeles. I work as a system administrator and am slowly completing a Master's degree in computer science. Patrick: What made you decide to develop for Tahoe-LAFS? Kevan: I learned about the project on a mailing list I follow; I think it was an email Zooko sent about Tahoe-LAFS being a (last minute) entry into the Google Summer of Code program. I looked at it, noted that it dealt with areas which interested me and noted it was primarily written in Python, which I was learning at the time. Patrick: What areas in particular interested you? Kevan: The P2P aspects, at that time. I've since grown to appreciate the use of capabilities (and capability research in general), though I'm not as familiar with that as I'd like to be. Patrick: With the upcoming new release, the big new feature is MDMF, a feature you are working on. Can you tell us what is MDMF? Kevan: In short, MDMF is more efficient mutable files. Immutable file have (always?) been segmented; in other words, they're processed not as one big piece, but in little parts. Current mutable files aren't segmented; they are processed in one big chunk. There are a few significant downsides to not chunking mutable files. Patrick: Such as? Kevan: Memory footprint, for one. If you want to add something to the end of an SDMF mutable file, you have to download and decrypt the whole thing, add your something to the end of the plaintext, then reencrypt and reupload the result. Patrick: How would the same thing work with MDMF, what would be the difference? Kevan: You'd only need to download at most the last segment (which is probably only 128KB or so in size), and all of your operations are performed on that. So that's less data sitting in RAM while you upload and less data that you need to download and upload as a result of your modification. Patrick: Sounds like this would be a significant improvement in speed. Kevan: Hopefully. I'm curious to see if any interesting use cases are enabled by efficiently modified mutable files. Patrick: Will you be attending the Tahoe Summit in San Franscisco? Kevan: Yes, I plan to. Patrick: Anything you are looking forward to at the Summit? Kevan: I don't think I've ever met any of the other developers in person, so I'm looking forward to that. I hope that we'll get close to having MDMF ready for trunk; being in one place should help speed code review along. Patrick: Any words of wisdom for new developers looking to join the Tahoe-LAFS dev team? Kevan: Join the mailing list and introduce yourself. It's likely that someone will point you to an easy starter ticket. In my experience, the hardest part of getting into a new codebase is finding a place to start, so I found that really helpful. I'm impressed with the other developers and I know I've learned a lot by working on Tahoe-LAFS. Patch Needing Review of the Week ================================ Ticket 1342_ needs review. This ticket, "rename tests of packaging and improve them to avoid spurious system-dependent test failures", is to manage small clean-up patches which we would like to see applied to 1.9.0. Review of this patch would be greatly appreciated. This page_ covers the procedures for code review. .. _1342: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1342 .. _page: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/PatchReviewProcess Bug of the week =============== Ticket 1395_ wins the award for bug of the week. This ticket covers an error which occurs when doing a check --verify on files which are bigger than 1GB. We would like to see this bug resolved in time for inclusion in 1.9.0. We would appreciate any help the community can provide with this ticket. .. _1395: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1395 Company of the Week =================== Starting next week, TWN will be running a company of the week section. In this section, TWN will highlight companies which contribute to Tahoe-LAFS. It is our way of saying thank you. Related/Similar/Competive Project of the Week ============================================= Starting next week, TWN will be running a related/similar/competitive project of the week. In this section, we will discuss things we feel are good with similar or even competitive projects. Please note, no non-open source projects will be covered. .. _fifteen: http://tahoe-lafs.org/trac/tahoe-lafs/query?status=!closed&keywords=~review… .. _page: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/PatchReviewProcess _______________________________________________ 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

Re: [tor-talk] Choosing a name for a .onon
by Maxim Kammerer 06 Jul '18

06 Jul '18

On Fri, Mar 30, 2012 at 01:54, Seth David Schoen <schoen(a)eff.org> wrote: > Choosing the first 40 bits of a hash generally requires trying an average of 2b4b0 > possibilities; my laptop does about 3-4 million SHA1 operations per second > (per CPU core) so it would take me 3-4 days (per CPU core) of computation > to try that many possibilities on my laptop. Due to proliferation of Bitcoin, there are now very efficient SHA-256 generators for off-the-shelf GPUs. The numbers at [1] suggest performance that's at least two orders of magnitude faster than your laptop b and for double-SHA-256 instead of a single SHA-1 (which I assume can be done by the same software after some simple adaptation). [1] https://en.bitcoin.it/wiki/Mining_hardware_comparison > Of course this requires being able to change something trivial about the > public key when generating the .onion address. Not necessarily b you can generate the hash first, and then check whether the public key is legal. I.e., generate a 512-bit prime p, and then go on with producing a completely random 512-bit e, and checking whether SHA-1(ASN.1-RSAPublicKey(modulus=p*e, exponent=65537)) (which is how Tor computes the .onion address) produces the desired result. If it does, check whether e is prime. Density of primes in the range of e is ~1/512, so that's just 9 bits more of search space, and primality checking efficiency doesn't matter much. -- Maxim Kammerer LibertC) Linux (discussion / support: http://dee.su/liberte-contribute) _______________________________________________ tor-talk mailing list tor-talk(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- 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

PGP Corp. Purchases PGP Desktop Encryption and Wireless Product
by Network Associates 06 Jul '18

06 Jul '18

Lines from NET August 19, 2002 Dear Customer, Today we are pleased to announce that PGP Corporation, a newly formed, venture-funded security company, has acquired the PGP desktop encryption and wireless product lines from Network Associates. As you know, prior to placing the products into maintenance mode, we were actively looking for a buyer that would continue the development and support of the technology. Network Associates has retained products developed using PGPsdk including McAfee E-Business Server for encrypted server-to-server file transfer, McAfee Desktop Firewall and McAfee VPN Client. These products will remain a part of Network Associates existing product portfolio and we will continue to develop them to meet your security needs. PGP Corporation has acquired PGPmail, PGPfile, PGPdisk, PGPwireless, PGPadmin and PGPkeyserver encryption software products for Win32 and Macintosh, PGPsdk encryption software development kit, and PGP Corporate Desktop for Macintosh. In addition to the technology, PGP Corporation has acquired all worldwide customer license agreements and technical support obligations. To ensure a seamless transition, Network Associates will work with PGP Corporation to support PGP customers through October 26, 2002. PGP Corporation will contact you shortly with details on its plans and product direction. We trust that you will have continued success with the PGP desktop and wireless encryption products through PGP Corporation. Network Associates appreciates your business and we value our continued relationship across our remaining product lines. Best Regards, Sandra England Executive Vice President, Business Development and Strategic Research Network Associates **************************************************************************************************** You have received this message because you are a subscriber to the Network Associates Web sites. To unsubscribe, please follow the instructions at the end of this message. This information update is available at no charge to all registered users of Network Associates Web site. * To change your email address, send a reply to this email address and to subscribe(a)nai.com with the words, "change-address" in the subject line. In the body of the message include your old and new email addresses with the original message. Use the following format for email changes: OLD: enduser(a)olddomain.com NEW: Joseph_User(a)newdomain.com ______________________________________________________________________ This message was sent by Network Associates, Inc. using Responsys Interact (TM). If you prefer not to receive future e-mail from Network Associates, Inc.: http://nai.rsc01.net/servlet/optout?gHpgJDWWBEkHoFpINJDJhtE0 To view our permission marketing policy: http://www.rsvp0.net --- 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

<nettime> Help Wanted: Internet Spy
by Jack 06 Jul '18

06 Jul '18

Interesting ad seen at http://www.rand.org/jobs: ***** Posting Title: Research Programmer Location: (S) Santa Monica Reference: 001241 Job Description: Research Programmer RAND is seeking a Research Programmer to work on various information technology, security and assurance projects in our Santa Monica office. It is preferred that the individual have familiarity with various applied psychological measures that can be used to help with information protection systems. Under general supervision, the research programmer will be expected to search, monitor and track information and software tools that relate and leverage off these measures in the context of information security. More generally, the position requires skills in searching for highly technical, computer-related information and programs within a variety of Internet and Web sources, and organizing and structuring this material in a database for a project's use. Educational Requirements: Bachelors degree (or equivalent experience) in Mathematics, Economics, Statistics, Computer Science, Engineering, or other quantitative or computer discipline. Master preferred. Coursework or experience must cover research methods, policy analysis, and critical infrastructure protection. Specific technical skills required: Thorough technical knowledge of current computer operating systems (e.g., Linux, Solaris, Open BSD, Windows), and programming languages (e.g., Lisp, Prolog, C, Perl). Must be extremely proficient in such Internet and Web technologies as anonymizing sites, IRC and "chat rooms," and downloading and investigating properties of hacker "toolkits" and related software. Ability to organize and structure information within a database for project use is mandatory. Related experience required: 3 - 5 years Type of experience required/preferred: Applicant should have excellent interpersonal skills, be able to conduct independent investigations of online sites, and participate in online dialogs (IRC, chats) by gaining the trust of relevant persons. Experience with the content and participants of such computer security conferences as the Black Hat Briefings, DEFCON, and CANSECWest/core03 would be useful. A security clearance is not required, but is desirable. Location: Santa Monica # distributed via <nettime>: no commercial use without permission # <nettime> is a moderated mailing list for net criticism, # collaborative text filtering and cultural politics of the nets # more info: majordomo(a)bbs.thing.net and "info nettime-l" in the msg body # archive: http://www.nettime.org contact: nettime(a)bbs.thing.net --- 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'

1 0

[tahoe-lafs-weekly-news] Tahoe-LAFS Weekly News #2
by Patrick R McDonald 06 Jul '18

06 Jul '18

Ladies and gentlemen, We proudly present issue #2 of the Tahoe Weekly News. -- ---------------------------------------------------------------- | Patrick R. McDonald GPG Key: 668AA5DF | | https://www.antagonism.org/ <marlowe(a)antagonism.org> | | <mcdonald.patrick.r(a)gmail.com> | | <patrick(a)opensecurityfoundation.org> | ---------------------------------------------------------------- | Malo periculosam libertatem quam quietum servitium | ---------------------------------------------------------------- ========================================== Tahoe-LAFS Weekly News, issue number 2 ========================================== Welcome to the Tahoe-LAFS Weekly News (TWN) brought to you by Patrick McDonald, scribe. Tahoe-LAFS_ is a secure, distributed storage. .. _Tahoe-LAFS: http://tahoe-lafs.org Announcements and News ====================== The 1.9.0 planning has begun. The development team is evicting tickets. Brian Wagner will be posting to the tahoe-dev list regarding the 1.9.0 schedule. Tuesday at the Tahoe Summit will be deep design day with Brian Wagner. While no specifics yet, deep design day will most likely cover accounting and `signed Introducer announcements`_. Both of these features Brian has been working on for a long time. He is looking for some assistance so he can land some code. Also up for discussion will be new capability formats as MDMF caps are due in the 1.9.0 release. .. _`signed Introducer announcements`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/466 David Triendl announced he is stepping down from his longstanding role as manager for the public demo test grid. TWN would like to extend our thanks to David for his supports. We greatly appreciate it. Charles Wyble volunteered to take over the role. Charles welcome aboard, we look forward to working with you. The tahoe-dev mailing list provided an interesting discussion regarding the access control policies Tahoe-LAFS offers. Two newcomers asked the list about these policies to which various "old timers" provided explanations. See `the mailing list archives`_ for the discussion and `the overview of Tahoe-LAFS`_ for a summary of access control features. .. _`the mailing list archives`: http://tahoe-lafs.org/pipermail/tahoe-dev/2011-June/date.html .. _`the overview of Tahoe-LAFS`: http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/about.rst#access-c… Tahoe is now a `special remote`_ for git-annex_. .. _`special remote`: http://git-annex.branchable.com/forum/tips:_special__95__remotes__47__hook_… .. _`git-annex`: http://git-annex.branchable.com `210 Bitcoins`_ have been pledged to integrate Tahoe-LAFS and Bitcoin. A new ticket, 1408_ was created in response to this bounty. .. _`210 Bitcoins`: http://forum.bitcoin.org/?topic=2236.0 .. _1408: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1408 Interview with the Developers ============================= This past week, TWN interview Kevan. Kevan is a member of the Tahoe-LAFS development team. Kevan is working on MDMF which is the major feature of the upcoming 1.9.0 release. Thank Kevan for taking the time for this interview. Patrick: First give us a little introduction. Tell us a bit about who you are? Kevan: My Name is Kevan. I am 24. I live near Los Angeles. I work as a system administrator and am slowly completing a Master's degree in computer science. Patrick: What made you decide to develop for Tahoe-LAFS? Kevan: I learned about the project on a mailing list I follow; I think it was an email Zooko sent about Tahoe-LAFS being a (last minute) entry into the Google Summer of Code program. I looked at it, noted that it dealt with areas which interested me and noted it was primarily written in Python, which I was learning at the time. Patrick: What areas in particular interested you? Kevan: The P2P aspects, at that time. I've since grown to appreciate the use of capabilities (and capability research in general), though I'm not as familiar with that as I'd like to be. Patrick: With the upcoming new release, the big new feature is MDMF, a feature you are working on. Can you tell us what is MDMF? Kevan: In short, MDMF is more efficient mutable files. Immutable file have (always?) been segmented; in other words, they're processed not as one big piece, but in little parts. Current mutable files aren't segmented; they are processed in one big chunk. There are a few significant downsides to not chunking mutable files. Patrick: Such as? Kevan: Memory footprint, for one. If you want to add something to the end of an SDMF mutable file, you have to download and decrypt the whole thing, add your something to the end of the plaintext, then reencrypt and reupload the result. Patrick: How would the same thing work with MDMF, what would be the difference? Kevan: You'd only need to download at most the last segment (which is probably only 128KB or so in size), and all of your operations are performed on that. So that's less data sitting in RAM while you upload and less data that you need to download and upload as a result of your modification. Patrick: Sounds like this would be a significant improvement in speed. Kevan: Hopefully. I'm curious to see if any interesting use cases are enabled by efficiently modified mutable files. Patrick: Will you be attending the Tahoe Summit in San Franscisco? Kevan: Yes, I plan to. Patrick: Anything you are looking forward to at the Summit? Kevan: I don't think I've ever met any of the other developers in person, so I'm looking forward to that. I hope that we'll get close to having MDMF ready for trunk; being in one place should help speed code review along. Patrick: Any words of wisdom for new developers looking to join the Tahoe-LAFS dev team? Kevan: Join the mailing list and introduce yourself. It's likely that someone will point you to an easy starter ticket. In my experience, the hardest part of getting into a new codebase is finding a place to start, so I found that really helpful. I'm impressed with the other developers and I know I've learned a lot by working on Tahoe-LAFS. Patch Needing Review of the Week ================================ Ticket 1342_ needs review. This ticket, "rename tests of packaging and improve them to avoid spurious system-dependent test failures", is to manage small clean-up patches which we would like to see applied to 1.9.0. Review of this patch would be greatly appreciated. This page_ covers the procedures for code review. .. _1342: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1342 .. _page: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/PatchReviewProcess Bug of the week =============== Ticket 1395_ wins the award for bug of the week. This ticket covers an error which occurs when doing a check --verify on files which are bigger than 1GB. We would like to see this bug resolved in time for inclusion in 1.9.0. We would appreciate any help the community can provide with this ticket. .. _1395: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1395 Company of the Week =================== Starting next week, TWN will be running a company of the week section. In this section, TWN will highlight companies which contribute to Tahoe-LAFS. It is our way of saying thank you. Related/Similar/Competive Project of the Week ============================================= Starting next week, TWN will be running a related/similar/competitive project of the week. In this section, we will discuss things we feel are good with similar or even competitive projects. Please note, no non-open source projects will be covered. .. _fifteen: http://tahoe-lafs.org/trac/tahoe-lafs/query?status=!closed&keywords=~review… .. _page: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/PatchReviewProcess _______________________________________________ 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