Re: [cryptography] To Protect and Infect Slides
Keying off of one phrase alone, This combat is about far more than crypto... I suggest you immediately familiarize yourself with last month's changes to the Wassenaar Agreement, perhaps starting here: http://oti.newamerica.net/blogposts/2013/international_agreement_reached_controlling_export_of_mass_and_intrusive_surveillance Precis: Two new classes of export prohibited software: Intrusion software Software specially designed or modified to avoid detection by 'monitoring tools', or to defeat 'protective countermeasures', of a computer or network capable device, and performing any of the following: a. The extraction of data or information, from a computer or network capable device, or the modification of system or user data; or b. The modification of the standard execution path of a program or process in order to allow the execution of externally provided instructions. IP network surveillance systems 5. A. 1. j. IP network communications surveillance systems or equipment, and specially designed components therefor, having all of the following: 1. Performing all of the following on a carrier class IP network (e.g., national grade IP backbone): a. Analysis at the application layer (e.g., Layer 7 of Open Systems Interconnection (OSI) model (ISO/IEC 7498-1)); b. Extraction of selected metadata and application content (e.g., voice, video, messages, attachments); and c. Indexing of extracted data; and 2. Being specially designed to carry out all of the following: a. Execution of searches on the basis of 'hard selectors'; and b. Mapping of the relational network of an individual or of a group of people. All the same arguments that applied exportation bans for crypto software apply here, especially that of pointlessness. --dan [ Software doesn't spy on people; people spy on people ] ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] To Protect and Infect Slides
New to the mailing list, sorry if this is formatted improperly. Does the 'intrusion software' category include open-source stuff like Metasploit? Also, how will this affect software security testing by private companies? Many infosec consulting companies have in-house proprietary software for pentesting. On Wed, Jan 8, 2014 at 1:38 PM, d...@geer.org wrote: Keying off of one phrase alone, This combat is about far more than crypto... I suggest you immediately familiarize yourself with last month's changes to the Wassenaar Agreement, perhaps starting here: http://oti.newamerica.net/blogposts/2013/international_agreement_reached_controlling_export_of_mass_and_intrusive_surveillance Precis: Two new classes of export prohibited software: Intrusion software Software specially designed or modified to avoid detection by 'monitoring tools', or to defeat 'protective countermeasures', of a computer or network capable device, and performing any of the following: a. The extraction of data or information, from a computer or network capable device, or the modification of system or user data; or b. The modification of the standard execution path of a program or process in order to allow the execution of externally provided instructions. IP network surveillance systems 5. A. 1. j. IP network communications surveillance systems or equipment, and specially designed components therefor, having all of the following: 1. Performing all of the following on a carrier class IP network (e.g., national grade IP backbone): a. Analysis at the application layer (e.g., Layer 7 of Open Systems Interconnection (OSI) model (ISO/IEC 7498-1)); b. Extraction of selected metadata and application content (e.g., voice, video, messages, attachments); and c. Indexing of extracted data; and 2. Being specially designed to carry out all of the following: a. Execution of searches on the basis of 'hard selectors'; and b. Mapping of the relational network of an individual or of a group of people. All the same arguments that applied exportation bans for crypto software apply here, especially that of pointlessness. --dan [ Software doesn't spy on people; people spy on people ] ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] To Protect and Infect Slides
Thanks. We posted the Wassenaar changes on Cryptome on December 19. http://cryptome.org/2013/12/wassenaar-intrusion.htm http://cryptome.org/2013/12/wassenaar-list-13-1204.pdf The intrusion software has received some but not sufficient attention. And beyond the sections you cite there are many covering other technologies which interrelate and affect crypto. Those have received even less attention, at least in crypto world as far as we have seen. The means to transceive crypto continue to be its Achilles heel and appear headed toward crippling the whole body -- the bubble in which crypto exists precariously dependent on sophisticated support systems which, as seen in the Snowden minimal releases, have overwhelmed public crypto security, not least by leaving the impression public crypto was highly effective. More attention to the support system presumably will be given as the Snowden releases recommence, now dead stopped. Greenwald claimed recently that cryptographers and other techies are now reviewing the material, much of which is beyond the capabilities of journalists, lawyers and politicians. The stumbling block of comprehensive Snowden disclosures is that to do so, allegedly, could severely damage national security. Uh oh, that terrible aroma of complicity to protect secrets too dangerous for the public to know. Instead a few select experts are allowed to perfomr dual-hat assessments. Which is what has led to the current imbroglio of public and expert distrust: who watches the dual-hat experts who operate under the cloak of secrecy. At 04:38 PM 1/8/2014, you wrote: Keying off of one phrase alone, This combat is about far more than crypto... I suggest you immediately familiarize yourself with last month's changes to the Wassenaar Agreement, perhaps starting here: http://oti.newamerica.net/blogposts/2013/international_agreement_reached_controlling_export_of_mass_and_intrusive_surveillance Precis: Two new classes of export prohibited software: Intrusion software Software specially designed or modified to avoid detection by 'monitoring tools', or to defeat 'protective countermeasures', of a computer or network capable device, and performing any of the following: a. The extraction of data or information, from a computer or network capable device, or the modification of system or user data; or b. The modification of the standard execution path of a program or process in order to allow the execution of externally provided instructions. IP network surveillance systems 5. A. 1. j. IP network communications surveillance systems or equipment, and specially designed components therefor, having all of the following: 1. Performing all of the following on a carrier class IP network (e.g., national grade IP backbone): a. Analysis at the application layer (e.g., Layer 7 of Open Systems Interconnection (OSI) model (ISO/IEC 7498-1)); b. Extraction of selected metadata and application content (e.g., voice, video, messages, attachments); and c. Indexing of extracted data; and 2. Being specially designed to carry out all of the following: a. Execution of searches on the basis of 'hard selectors'; and b. Mapping of the relational network of an individual or of a group of people. All the same arguments that applied exportation bans for crypto software apply here, especially that of pointlessness. --dan [ Software doesn't spy on people; people spy on people ] ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Techniques for protecting CA Root certificate Secret Key
Software and physical safe keeping of Root CA secret key are central to security of a large set of issued certificates. Are there any safe techniques for handling this problem taking into account the need to not have the control in the hands of one person? Any links or suggestions of how to handle this problem? regards Paul Fraser ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Techniques for protecting CA Root certificate Secret Key
Den 9 jan 2014 00:56 skrev Paul F Fraser pa...@a2zliving.com: Software and physical safe keeping of Root CA secret key are central to security of a large set of issued certificates. Are there any safe techniques for handling this problem taking into account the need to not have the control in the hands of one person? Any links or suggestions of how to handle this problem? regards Paul Fraser Hardware Security Modules are common. Kind of like smartcards (the chip on your bank card), but big and fast, and usually supporting far more protocols. Designed to be very hard to hack or otherwise extract the keys from. On the algorithmical level, there is Secure Multiparty Computation plus Shamir's Secure Sharing Scheme, such that you need a group of chosen period to work together to use the key to decrypt and sign things, while not revealing the private key to anybody. The people who developed the Speedz (spelling?) protocol is marketing a service for this. - Sent from my phone ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Omidyar-Greenwald Scam to Sell Crypto?
Pierre Omidyar's Business Model for First Look is Like a Second Life or Anti-Virus Guard Scam http://3dblogger.typepad.com/wired_state/2014/01/pierre-omidyars-business-model-for-first-look-is-like-a-second-life-or-anti-virus-guard-scam.html ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Techniques for protecting CA Root certificate Secret Key
Paul Fraser asked: #Software and physical safe keeping of Root CA secret key are central to #security of a large set of issued certificates. # #Are there any safe techniques for handling this problem taking into account the #need to not have the control in the hands of one person? # #Any links or suggestions of how to handle this problem? See Section 16.6 of the Certificate and Browser Forum Baseline Requirements at https://www.cabforum.org/wp-content/uploads/Baseline_Requirements_V1.pdf For devices certified for FIPS 140 at level 3, check out http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm and then search that web page for the appropriate level For Common Criteria EAL 4 or higher, start with http://www.commoncriteriaportal.org/products/ Regards, Joe ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Techniques for protecting CA Root certificate Secret Key
On 9/01/14 02:49 AM, Paul F Fraser wrote: Software and physical safe keeping of Root CA secret key are central to security of a large set of issued certificates. Are there any safe techniques for handling this problem taking into account the need to not have the control in the hands of one person? Any links or suggestions of how to handle this problem? The easiest place to understand the formal approach would be to look at Baseline Requirements, which Joe pointed to. It's the latest in a series of documents that has emphasised a certain direction. However, it is not the only answer. The best way to describe it is that it is 'best practices' for the CA industry, and once you achieve that way, you're on the path to being inculcated. If that's your goal, the BR is your answer. As you don't say much about your problem space is, it's difficult to answer your real question: what are safe techniques for handling root CA keys? (fwiw, the techniques described in BR are not safe, IMHO. But they are industry 'best practice' so you might have to choose between loving acceptance and safety.) iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
