Re: [cryptography] To Protect and Infect Slides
On 9/01/14 00:38 AM, 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. Irony, delicious irony. Google, Facebook and Yahoo are banned from crossing the border by Wassenar. And that's just the commercial players. Wait until those other bureaucracies wake up, like the FATF, which explicitly requires the implementation of ... all of 5. above. All the same arguments that applied exportation bans for crypto software apply here, especially that of pointlessness. Cold war warriors never die, they just add more clauses to Wassenaar. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Techniques for protecting CA Root certificate Secret Key
On Wed, Jan 8, 2014 at 11:54 PM, ianG i...@iang.org wrote: 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. (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.) Is there a better reference for safe or a place that has commentary on the 'best practice' weaknesses? ___ 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 18:05 PM, Peter Bowen wrote: On Wed, Jan 8, 2014 at 11:54 PM, ianG i...@iang.org wrote: 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. (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.) Is there a better reference for safe I'm not aware of one. You probably have to invent your own process. You might do worse by looking at what Dan pointed at: Steve Bellovin: Nuclear Weapons, Permissive Action Links, and the History of Public Key Cryptography, USENIX, 2006. http://www.usenix.org/events/usenix06/tech/mp3/bellovin.mp3 http://www.usenix.org/events/usenix06/tech/slides/bellovin_2006.pdf http://64.233.169.104/search?q=cache:_gevj9vbdqsJ:www.usenix.org/events/usenix06/tech/slides/bellovin_2006.pdf or a place that has commentary on the 'best practice' weaknesses? Pointing out weaknesses in best practices is not best practices. You're either in or your out. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Speaking of key management [was Re: Techniques for protecting CA Root certificate Secret]
Hi, Those who are interested in key management may wish to note: Cryptographic Key Management Workshop 2014 http://www.nist.gov/itl/csd/ct/ckm_workshop2014.cfm March 4-5, 2014, NIST, Gaithersburg MD See also: SP 800-152 DRAFT A Profile for U. S. Federal Cryptographic Key Management Systems (CKMS) http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-152 Released 7 Jan 2014, comments due by March 5, 2014 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
Peter Bowen wrote: On Wed, Jan 8, 2014 at 11:54 PM, ianG i...@iang.org wrote: 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. (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.) Is there a better reference for safe or a place that has commentary on the 'best practice' weaknesses? The short answer is 'no'. As a first comment replace CA certificate Secret Key by root CA private signature key [used to sign certificates] because 1) you want to trust (or establish trustworthiness for) a CA *entity*, 2) you might wish to have some continuity if the CA entity replaces its signature key pair, and 3) a secret key might refer to some other type of key. If you understand the fundamentals, you may see that the root DNSSEC signature key (handled by ICANN/IANA, see https://www.iana.org/dnssec ) requires indeed the exact same type of protections. Documents were circulated prior to the launch of the DNSSEC service for the DNS root zone that disclosed a lot of design decisions that are now embedded in the details of KSK ceremonies. I got the feeling that ICANN employees are nowadays in the public-relations mood when questioned (more or less consciously by the person asking a question who may have been absent when call for comments were made). I would suggest that the DNSSEC deployment at the root would be a good case study for IT security management, from an historic perspective. The primary source documents, and the conclusion of such case study, could be helpful to you but ... ... if you want to do it right (and since the resources -- money, personnel, organizational trustworthiness, immediate attention from a community of experts -- available to ICANN aren't available to you), you may need to revise your understanding of underlying principles (hint: don't start by reverse engineering the PKCS#12 specifications). You may want to do it best practice and there you go. Good luck -- - Thierry Moreau ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Speaking of key management [was Re: Techniques for protecting CA Root certificate Secret]
Joe St Sauver wrote: Hi, Those who are interested in key management may wish to note: Cryptographic Key Management Workshop 2014 http://www.nist.gov/itl/csd/ct/ckm_workshop2014.cfm March 4-5, 2014, NIST, Gaithersburg MD See also: SP 800-152 DRAFT A Profile for U. S. Federal Cryptographic Key Management Systems (CKMS) http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-152 Released 7 Jan 2014, comments due by March 5, 2014 Don't forget to look at SP 800-130 in parallel. A Framework for Designing Cryptographic Key Management Systems Overall, an endless list of requirements that may be useful as a barrier to entry in the US Federal Government IT security market. Not necessarily a bad checklist; I could not identify any specific innovation-suppressor element (over the ones already present in the NIST mandatory techniques) after a quick glimpse at a few document sections. The crazy things in Canada is that NIST mandatory techniques are merely recommended in the Canadian Federal Government. So the official crypto policy is the NIST one but departments and government agencies have no incentive to ever procure NIST-approved solutions: they have much more freedom when doing otherwise. Have fun with key management challenges! -- - Thierry Moreau ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Techniques for protecting CA Root certificate Secret Key
On Thu, Jan 9, 2014 at 7:51 AM, Thierry Moreau thierry.mor...@connotech.com wrote: I would suggest that the DNSSEC deployment at the root would be a good case study for IT security management, from an historic perspective. The primary source documents, and the conclusion of such case study, could be helpful to you but ... I'd actually look at DNSSEC as something of an antipattern. They ostensibly seem to be using One Key To Rule Them all and a Shamir-like secret sharing scheme. This makes less sense to me than a multisignature trust system / threshold signature system with n root keys and a threshold t such that we need t of n signatures in order for something to be considered signed. While I'm sure they took great care to airgap and delete the DNSSEC root key from the computer it was generated on, that's an unnecessary risk that simply doesn't have to exist. Furthermore a multisignature trust system makes it easy to rotate the root keys: if one is compromised you simply sign a new root key document with t of n signatures again, listing out the newly reissued public key. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Techniques for protecting CA Root certificate Secret Key
On Thu, Jan 09, 2014 at 10:36:23AM -0800, Tony Arcieri wrote: I'd actually look at DNSSEC as something of an antipattern. They ostensibly seem to be using One Key To Rule Them all and a Shamir-like secret sharing scheme. This makes less sense to me than a multisignature trust system / threshold signature system with n root keys and a threshold t such that we need t of n signatures in order for something to be considered signed. While I'm sure they took great care to airgap and delete the DNSSEC root key from the computer it was generated on, that's an unnecessary risk that simply doesn't have to exist. Furthermore a multisignature trust system makes it easy to rotate the root keys: if one is compromised you simply sign a new root key document with t of n signatures again, listing out the newly reissued public key. -- Tony Arcieri A talk from 29C3 explains the DNSSEC root key generation process: An overview of secure name resolution http://mirror.netcologne.de/CCC/congress/29C3/mp4-h264-HQ/29c3-5146-en-an_overview_of_secure_name_resolution_h264.mp4 http://youtu.be/eOGezLjlzFU if you prefer YouTube. -- staticsafe ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Techniques for protecting CA Root certificate Secret Key
Tony Arcieri wrote: On Thu, Jan 9, 2014 at 7:51 AM, Thierry Moreau thierry.mor...@connotech.com mailto:thierry.mor...@connotech.com wrote: I would suggest that the DNSSEC deployment at the root would be a good case study for IT security management, from an historic perspective. The primary source documents, and the conclusion of such case study, could be helpful to you but ... I'd actually look at DNSSEC as something of an antipattern. They ostensibly seem to be using One Key To Rule Them all and a Shamir-like secret sharing scheme. This makes less sense to me than a multisignature trust system / threshold signature system with n root keys and a threshold t such that we need t of n signatures in order for something to be considered signed. While I'm sure they took great care to airgap and delete the DNSSEC root key from the computer it was generated on, that's an unnecessary risk that simply doesn't have to exist. Furthermore a multisignature trust system makes it easy to rotate the root keys: if one is compromised you simply sign a new root key document with t of n signatures again, listing out the newly reissued public key. I guess a multisignature trust system requires some algorithm support beyond RSA and ECC signature schemes pushed by NIST, and thus would have been rejected on the (questionable) basis of lack of support in the DNS software culture and the (political) basis of lack of NIST approval. But yes! That is the type of suggestion/innovation that someone might look at while revisiting the fundamentals of root signature key management. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Speaking of key management [was Re: Techniques for protecting CA Root certificate Secret]
Hi, Those who are interested in key management may wish to note: Cryptographic Key Management Workshop 2014 http://www.nist.gov/itl/csd/ct/ckm_workshop2014.cfm March 4-5, 2014, NIST, Gaithersburg MD See also: SP 800-152 DRAFT A Profile for U. S. Federal Cryptographic Key Management Systems (CKMS) http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-152 Released 7 Jan 2014, comments due by March 5, 2014 I will probably be there causing trouble. DJ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Techniques for protecting CA Root certificate Secret Key
On Thu, Jan 9, 2014 at 11:08 AM, Thierry Moreau thierry.mor...@connotech.com wrote: I guess a multisignature trust system requires some algorithm support beyond RSA and ECC signature schemes pushed by NIST, and thus would have been rejected on the (questionable) basis of lack of support in the DNS software culture and the (political) basis of lack of NIST approval. Not at all. You can use any digital signature scheme you want. Give the data you want signed to each of the participants and they can add their signature. It's not much different than the digital equivalent of a paper document signed by multiple parties. Verifiers merely ensure there's t signatures present on a given piece of data before treating it as valid. An example of a system using this approach is The Update Framework: http://freehaven.net/~arma/tuf-ccs2010.pdf See section 6.2: Multi-Signature Trust. There are also multisignature Bitcoin addresses: http://bitcoin.stackexchange.com/questions/3718/what-are-multi-signature-transactions -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Speaking of key management [was Re: Techniques for protecting CA Root certificate Secret]
SP 800-152 Don't forget to look at SP 800-130 in parallel. Overall, an endless list of requirements that may be useful as a barrier to entry in the US Federal Government IT security market. That's why I'm going. To try and trim the obstructive requirements. If we're building on-chip key management to secure on-chip things from other on-chip things, requiring a human 'officer' to bless keys, IDs and entities is an impassable barrier. That spec needs a lobotomy. Either it gets fixed, or we ignore it. So I'll try one pass at fixing it and if that doesn't work, we'll move on. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Techniques for protecting CA Root certificate Secret Key
On 2014-01-09, 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? In addition to what Joe sent, you may also be interested in the CertiPath certificate policy: https://www.certipath.com/policy-management-authority/policy-documents Best regards, Timo ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
On Tue, Dec 24, 2013 at 5:09 AM, danimoth danim...@cryptolab.net wrote: On 24/12/13 at 04:20am, grarpamp wrote: This thread pertains specifically to the use of P2P/DHT models to replace traditional email as we know it today. There was a former similarly named thread on this that diverged... from the concept and challenge of P2P/DHT handling the transport and lookups... back to more traditional models. This thread does not care about those antique models, please do not take it there. A problem which could rise is the 'incentive' for peers to continuosly providing bandwidth and disk space to store messages. I'm a simple dude, with a mailflow of ~5 email per day. Why I should work for you, with your ~1 mail per day for all your mailing list? Somewhere on this list (or p2p-hackers?) there was a post of mine, regardings an economic incentive between peers, which could be a solution, but as always technical problems arose, like pricing the services and a fair exchange between peers. There may be advantage to the security of your own traffic if you also handle the traffic of others. Economically, it's probably not right to expect 'free' transport in such a system. Though perhaps at minimum you should be expected to provide benefit to the network an equivalent of what you consume, including the extended cost to the net of your consumption. ie: in a multi-hop network your impact is not just over your own interface. And in an anonymous network it's most assuredly not right to force users to pay using non-anonymous payment methods. Though they may optionally do so if they wish. How close is the research on these issues to being codeable into actual p2p transports (whether anonymous (preferred) or not)? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Cuckoo Cycles: a new memory-hard proof-of-work system
Hello John Tromp! That is neat! The paper could use a related work section, for example Litecoin uses scrypt in the attempt to make it harder to implement in ASIC: https://litecoin.info/Scrypt The current Password Hashing Contest (disclosure: I am on the panel) may be relevant to your interests: https://password-hashing.net/ Regards, Zooko ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
