> What's going on under the hood in the term "in an authenticated way"?
I think what the OP meant is not necessarily some fancy crypto authentication, but includes what is illustrated by the following. When you download something (be it OpenSSL or whatever) you download the hash from a known URL, and check it against the thing that you downloaded from wherever. Firefox used to use a url to ensure that you are getting valid updates, and maybe still do. It's possible that attackers may have subverted DNS or hacked into the website, but nonetheless, getting the hash from the familiar website is a form of authentication. Mike ----- Original Message ----- From: "cryptography-requ...@randombit.net" <cryptography-requ...@randombit.net> To: cryptography@randombit.net Cc: Sent: Friday, April 27, 2012 9:00 AM Subject: cryptography Digest, Vol 26, Issue 33 Send cryptography mailing list submissions to cryptography@randombit.net To subscribe or unsubscribe via the World Wide Web, visit http://lists.randombit.net/mailman/listinfo/cryptography or, via email, send a message with subject or body 'help' to cryptography-requ...@randombit.net You can reach the person managing the list at cryptography-ow...@randombit.net When replying, please edit your Subject line so it is more specific than "Re: Contents of cryptography digest..." Today's Topics: 1. Re: data integrity: secret key vs. non-secret verifier; and: are we winning? (Nico Williams) 2. PKI in practice: is there a list of ("widely" deployed) client-certs-issuing CAs? (Thierry Moreau) 3. Re: PKI in practice: is there a list of ("widely" deployed) client-certs-issuing CAs? (Ryan Sleevi) 4. An oldie but a goodie (Peter Gutmann) 5. Re: data integrity: secret key vs. non-secret verifier; and: are we winning? (ianG) 6. Re: PKI in practice: is there a list of ("widely" deployed) client-certs-issuing CAs? (Thierry Moreau) ---------------------------------------------------------------------- Message: 1 Date: Thu, 26 Apr 2012 11:25:59 -0500 From: Nico Williams <n...@cryptonector.com> To: Darren J Moffat <darren.mof...@oracle.com> Cc: Discussion of cryptography and related <cryptography@randombit.net> Subject: Re: [cryptography] data integrity: secret key vs. non-secret verifier; and: are we winning? Message-ID: <CAK3OfOjA3o6-GNLx=FkCVWYqJBmyYy6p4=s_u11ypqwqsp2...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Thu, Apr 26, 2012 at 11:06 AM, Darren J Moffat <darren.mof...@oracle.com> wrote: > The over all dataset size in blocks yes that information is effectively in > the clear. > > However I don't think there is anyway to calculate a file size from the > information in the blkptr_t. ?Since even though the DMU object type and both > logical and physical size are in the blkptr_t I don't see how you easily > work out the size of any given file since the file names are encrypted. I > don't think you can even calculate how many files there are. Yes, I know filenames are encrypted, and so is the directory tree structure. But object size in blocks does leak. That's not a big deal to me, but I can think of situations where that might actually matter. Imagine a person has his laptop confiscated at the border under suspicion of espionage, and though the person does not divulge their passwords the forensics analysts are able to demonstrate that some files on the laptop suspiciously match the size (in blocks, possibly compressed blocks) of the documents the person is thought to have stolen -- strong evidence at trial? Hard to say, but ZFS encryption is not intended to protect against such attacks. Nico -- ------------------------------ Message: 2 Date: Thu, 26 Apr 2012 13:34:44 -0400 From: Thierry Moreau <thierry.mor...@connotech.com> To: cryptography@randombit.net Subject: [cryptography] PKI in practice: is there a list of ("widely" deployed) client-certs-issuing CAs? Message-ID: <4f998734.6050...@connotech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed A question for those who follow PKI usage trends. Is there a list of CAs that issue X.509 end-user certificates? Here is the rationale for the question: If an end-user has a certificate, he (more or less consciously) controls a private key. Suppose one deploys a web server that cares *only* about end-user public keys, e.g. it keeps track of end-user reputation and that's it for trust management. Then any type of certificate is good enough (self-signed, auto-issued, issued by a regular "client-cert-issuing CA"). This web server can have an immediate potential user base if it negotiates the TLS session with a long list of CA distinguished names (in the CertificateRequest message). The management tools for the contemplated web server scheme would include an issuer DN extraction utility from end-user or CA certificates so that the list may be augmented based on casual observations. Also, the SSL debugging tools will report the contents of CertificateRequest messages from public servers supporting client certs. Anyone went through such data collection before? Thanks in advance. -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 ------------------------------ Message: 3 Date: Thu, 26 Apr 2012 23:31:51 -0700 From: "Ryan Sleevi" <ryan+cryptogra...@sleevi.com> To: "Thierry Moreau" <thierry.mor...@connotech.com> Cc: cryptography@randombit.net Subject: Re: [cryptography] PKI in practice: is there a list of ("widely" deployed) client-certs-issuing CAs? Message-ID: <27fc824e75abfd7d8425246af91ea920.squir...@webmail.dreamhost.com> Content-Type: text/plain;charset=iso-8859-1 > A question for those who follow PKI usage trends. > > Is there a list of CAs that issue X.509 end-user certificates? > > Here is the rationale for the question: > > If an end-user has a certificate, he (more or less consciously) controls > a private key. Suppose one deploys a web server that cares *only* about > end-user public keys, e.g. it keeps track of end-user reputation and > that's it for trust management. Then any type of certificate is good > enough (self-signed, auto-issued, issued by a regular > "client-cert-issuing CA"). > > This web server can have an immediate potential user base if it > negotiates the TLS session with a long list of CA distinguished names > (in the CertificateRequest message). > > The management tools for the contemplated web server scheme would > include an issuer DN extraction utility from end-user or CA certificates > so that the list may be augmented based on casual observations. Also, > the SSL debugging tools will report the contents of CertificateRequest > messages from public servers supporting client certs. > > Anyone went through such data collection before? > > Thanks in advance. > > -- > - 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 > Why not just send an empty list for certificate_authorities in the CertificateRequest? Most (all?) user-facing TLS clients will then presume the site has no restriction, and select from all of the available client certs that the user may have. Trying to stuff all the names - not to mention cross-signed intermediates, which are often necessary - and you're likely to blow out the record limits. Many TLS implementations, particularly TLS middleboxen, do not like fragmented handshake messages, so trying to stuff the Whole World into the request will likely break things considerably. I'm not sure how such a scheme would work for self-signed user certs, they inevitably would not match your pre-programmed list of DNs. See, for example, http://support.microsoft.com/kb/933430 ------------------------------ Message: 4 Date: Sat, 28 Apr 2012 01:58:22 +1200 From: Peter Gutmann <pgut...@cs.auckland.ac.nz> To: cryptography@randombit.net Subject: [cryptography] An oldie but a goodie Message-ID: <e1snlgk-0001e9...@login01.fos.auckland.ac.nz> In the 1980s DEC gave us crypt16, reducing password-guessing from 25 DES operations to a suffix search requiring only 5 DES operations. In the 1990s MS gave us LMHASH, reducing it to a single DES operation. Now, in 2012, the WiFi Alliance is proud to present WPS' wps_reg, which splits a 7-digit PIN into 4- and 3-digit halves, easily beating both DEC and MS broken auth-checking mechanisms: http://sviehb.wordpress.com/2011/12/27/wi-fi-protected-setup-pin-brute-force-vulnerability/ The WiFi Alliance is hereby nominated for the Tenex Memorial Prize [*] for innovative design in authentication mechanisms. Peter. [*] The Tenex Memorial Prize dates back to the late 1960s, when this security bug was first introduced. ------------------------------ Message: 5 Date: Sat, 28 Apr 2012 00:15:14 +1000 From: ianG <i...@iang.org> To: cryptography@randombit.net Subject: Re: [cryptography] data integrity: secret key vs. non-secret verifier; and: are we winning? Message-ID: <4f9aa9f2.2020...@iang.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 26/04/12 13:27 PM, Marsh Ray wrote: > On 04/25/2012 10:11 PM, Zooko Wilcox-O'Hearn wrote: >> It goes like this: suppose you >> want to ensure the integrity of a chunk of data. There are at least >> two ways to do this (excluding public key digital signatures): >> >> 1. the secret-oriented way: you make a MAC tag of the chunk (or >> equivalently you use Authenticated Encryption on it) using a secret >> key known to the good guy(s) and unknown to the attacker(s). >> >> 2. the verifier-oriented way: you make a secure hash of the chunk, and >> make the resulting hash value known to the good guy(s) in an >> authenticated way. > > Is option 2 sort of just pushing the problem around? > > What's going on under the hood in the term "in an authenticated way"? No, it's more like ... is there a hood? Are we authenticating it in a way that we expect? Is there some other way of thinking? What about if we walk to work instead of taking the car? Er, was I going to work? Consider the classical PKI v. alternatives argument. In PKI they say we must trust the TTP to authenticate the promise - so we are at mercy of that assumption. In contrast, the alternatives just send the info out and hope the users spot any extremely unlikely attacks in the first instance. If the first time works out, the system locks in to it. The difference is that PKI solves a weakness by substituting in another weakness that later on grows to consume the system. Whereas the alternate (call it skype or ssh?) just says - take the risk up front, get on with life. If anything goes wrong, a few muggles get splattered, but it worked fine for the rest of us. Both are a leap of faith... One just works better in real life, because it is the leap of faith that people do every day. And even that is to assume almost the same application set. > How do you do authentication in an automated system without someone > somewhere keeping something secret? Easy. Take the hash, then publish it. The data can be secret, the hash need not be. (Just one solution - now name the problem...) > Is authenticating the hash value fundamentally different from "ensuring > the integrity of a chunk of data"? Definitions :) iang ------------------------------ Message: 6 Date: Fri, 27 Apr 2012 11:18:25 -0400 From: Thierry Moreau <thierry.mor...@connotech.com> To: cryptography@randombit.net Subject: Re: [cryptography] PKI in practice: is there a list of ("widely" deployed) client-certs-issuing CAs? Message-ID: <4f9ab8c1.2070...@connotech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Follow-up on my own post below ... Thierry Moreau wrote: > A question for those who follow PKI usage trends. > > Is there a list of CAs that issue X.509 end-user certificates? > > Here is the rationale for the question: > > If an end-user has a certificate, he (more or less consciously) controls > a private key. Suppose one deploys a web server that cares *only* about > end-user public keys, e.g. it keeps track of end-user reputation and > that's it for trust management. Then any type of certificate is good > enough (self-signed, auto-issued, issued by a regular > "client-cert-issuing CA"). > > This web server can have an immediate potential user base if it > negotiates the TLS session with a long list of CA distinguished names > (in the CertificateRequest message). > > The management tools for the contemplated web server scheme would > include an issuer DN extraction utility from end-user or CA certificates > so that the list may be augmented based on casual observations. Also, > the SSL debugging tools will report the contents of CertificateRequest > messages from public servers supporting client certs. > > Anyone went through such data collection before? > > Thanks in advance. > I got a few off-list messages. One pointed towards the TLS 1.1 provision for an empty list of client-certs-issuing CA in the CertificateRequest message (in which case the client may use any certificate, which is the intended purpose). This is a protocol relaxation from TLS 1.0. Another observation is that a major TLS *server* implementation truncates this list (from the operator-supplied configuration) to a much smaller size than the protocol limit. I don't know if this reflects some browser-client limitations as a TLS client entity. So, if I had a long list of distinguished names for client-certs-issuing-CA, I am not sure I could recommend to use it as a default configuration item. I guess it's preferable to focus on configuration management tools that ease the job of supporting a more specific server user base. 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 End of cryptography Digest, Vol 26, Issue 33 ******************************************** _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
