Re: [cryptography] Security Pop-Up of the Day
ianG i...@iang.org writes: C.f., revocation is broken. The disablement of OCSP checking has been ... e widely suggested. Which leads to a curious puzzler; if it doesn't work for users, who does it work for? Ah, the cynicism :P There are a number of revocation vendors who have (or had, a few years ago) a considerable revenue stream built around selling OCSP services. Identrus(t) was one of those. The problem was that some silly CAs were misguided enough to take the whole OCSP theatrical performance public, spoiling it for everyone. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Security Pop-Up of the Day
On 22/09/11 09:37 AM, James A. Donald wrote: On 2011-09-22 8:20 AM, Joe St Sauver wrote: Understood that would be the zipless ideal, but how would the binding of the private/public keypair to the email address occur then, eh? Well, it wouldn't, in those terms, you need to unwrap the judo flip first. What you need to do is look at the email before it had a cert attached, and consider that as the baseline. E.g., this one. Then, next, you see an email with a cert attached. The second email is *at least as good as the first email*. Obviously, the words in this (first) email carry some weight, and attaching a cert cannot reduce that weight. It's an interesting judo trick that PKI does with people's minds. Email with a funny cert/sig is apparently worse than email without a cert/sig. Yet, we we sign contracts, negotiate deals, plan marriages, get jobs, talk to governments, etc etc, in email without any funky sigs certs. It's only when we start adding this crypto blah blah does our mind starts doing mental flips about the value. S/MIME achieves the extraordinary feat of subtracting value by adding crypto blah blah. For this reason, people won't use it. If S/MIME stuck to the normal rule of society -- add value -- then we'd be soaking in it by now. ( ... Same flaw with HTTP, which phishers so successfully exploit.) Email client generates private/public keypair. Sends public key to CA server. CA server certifies that the owner of the private key corresponding to this public key is capable of receiving email at the address, emails certificate it back to ostensible email address. Right, easy enough. What the CA would need to do is figure out a way to add some value to that process. Easy enough. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Math corrections
Hi Arshad, It occurs to me that we're almost there. On 22/09/11 02:30 AM, Arshad Noor wrote: Thirdly, lets assume that the compromised CA has *explicitly* entered into a cross-certification agreement with one or more other TTP CAs. Right, they got themselves listed by the browsers, who hid the CAs under dialog-camo. This is Peter's universal implicit cross-certification. That fact. Plus this result: Are there problems with PKI? I have already said, undoubtedly. But, these are certificate manufacturing and distribution problems that must be addressed. They are not a fundamental weakness of PKI itself. And we're there. Causality. To address the certificate manufacturing and distribution problem (aka the race to the bottom) then you need to address the universal implicit cross-certification. P.S. The use of the term universal implicit cross-certification only serves to add confusion to an already complex field; you are the only one that uses it (3 of the top 5 responses in a Google search of this term are from this thread; the remaining two come from your paper and presentation at IDTrust from some years ago). It took me a while to realize that its just your term for independent trust- chains in the browser. It might help the PKI community if we called a spade a spade. Thank you. Probably what is confusing to the PKI community is that you've stepped outside your theoretical models into the world of business. In business, if we certify and hide, then we start a race to the bottom. This is why branding is so important in business; because it gives the company a reason to establish a quality. In the CA world, the decision of the vendors to unbrand the CAs caused them to not need a quality approach, just a compliance approach. It's not personal :) It's just business. You see the same effect of compliance in other industries, the famous example we talk about is Sarbanes-Oxley and securitization and the race to global bankruptcy :) x iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Security Pop-Up of the Day
On Thu, Sep 22, 2011 at 09:37:42AM +1000, James A. Donald wrote: Email client generates private/public keypair. Sends public key to CA server. CA server certifies that the owner of the private key corresponding to this public key is capable of receiving email at the address, emails certificate it back to ostensible email address. User changes email client, or has two clients on different machines. Second certificate is received by CA server. Does it now certify both keys? Does it assume that one is an attack? User's machine crashes. How do they tell the CA server that the owner of the public key is no longer capable of receiving email with that private key? -- Paul Fsck, either way I'm screwed. -- petro Now *that* is the Sysadmin's motto. -- PdS ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] code signing a nuisance?
On Thu, Sep 22, 2011 at 1:32 AM, Chris Palmer snackypa...@gmail.com wrote: On Sep 21, 2011, at 10:11 PM, M.R. wrote: Please look into how code signing on Android works and what it means. A quick summary would be appreciated, especially on the meaning part. Google: [ android code signing ] http://www.isecpartners.com/files/iSEC_Securing_Android_Apps.pdf Android’s process isolation obviates the need for complicated policy configuration files for sandboxes. This gives applications the flexibility to use native code without compromising Android’s security or granting the application additional rights. Android permissions are rights given to applications to allow them to do things like take pictures, use the GPS or make phone calls. When installed, applications are given a unique UID, and the application will always run as that UID on that particular device. The UID of an application is used to protect its data and developers need to be explicit about sharing data with other applications. Android supports building applications that use phone features while protecting users by minimizing the consequences of bugs and malicious software. Android’s process isolation obviates the need for complicated policy configuration files for sandboxes. This gives applications the flexibility to use native code without compromising Android’s security or granting the application additional rights. The code signing is so that the installer daemon can know that the package was transmitted correctly, and it uses signing keys to enforce the UID separation — only apps signed by the same key can request to have the same UID or to use each other's private permissions. (Any app can use another app's public permissions.) http://developer.android.com/guide/topics/manifest/permission-element.html#plevel The Android Eclipse plugin generates you a fresh developer key when you install it and the process of signing apps is an automatic part of the build process. It imposes no limitation or inconvenience on developers. Making applications a security principal (as Microsoft calls it) was an awesome idea. It has the potential to solve a lot of problems. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL trusted root CA reliability (S Korea)
Let's be honest, without any methamatical/design/architectural assumptions, about the current PKI practical context. One of the weakest links of PKI is trust delegation to some sort of governement based legislated system. As said, somewhere on this maling list, CA's are companies in those same legislative ecosystems. This should be seen if you study the current View of certificates you get from popular endpoints using different geographic locations. Cross correlating this with the current PKI CA's/Delegations Trust network should give us an hint that effectively governments are monitoring the People. I think we should make an effort, in name of freedom, and study this more carefully and sooner as possible. SSL Observatory from EFF is a step forward but we need more. 1 - We need data on the details of certificates obtained from different geographic/government locations when pointing to popular endpoints such us google, facebook and so on 2 - We need to map/take_in_account clustered endpoints, like google, when doing this, since certificates differ in the clusters. 3 - Sitting ourselfs in different geographic locations when performing data collection should be done using different methods (use of proxy's, people from different countries submitting their certificates views..???). On Thu, Sep 22, 2011 at 10:38 AM, Ralph Holz h...@net.in.tum.de wrote: Hi, Sorry, but this is too good. This is the Bavarian tax office, and ELSTER is the government's tax software: C=DE, ST=Bayern, L=Muenchen, O=Bayerisches Landesamt fuer Steuern - Dienststelle Muenchen, OU=ELSTER, CN=Elster HTTPS-Client, 41 I seem to live in the country of offenders. Ralph -- Dipl.-Inform. Ralph Holz I8: Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ ___ 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] SSL is not broken by design
Ben Laurie b...@links.org writes: Well, don't tease. How? The link I've posted before (but didn't want to keep spamming to the list): http://www.cs.auckland.ac.nz/~pgut001/pubs/pki_risk.pdf Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL trusted root CA reliability (S Korea)
Hi, study this more carefully and sooner as possible. SSL Observatory from EFF is a step forward but we need more. Their distributed observatory is probably going to help much here, but I can offer the data sets from our paper. I'll put the paper online tomorrow and paste the link here. 1 - We need data on the details of certificates obtained from different geographic/government locations when pointing to popular endpoints such us google, facebook and so on We did not find any differences in the top 200 or so, and the rest did not seem suspicious. See the links in the previous mail for the set of differing certs. 2 - We need to map/take_in_account clustered endpoints, like google, when doing this, since certificates differ in the clusters. We did not observe that too often (Microsoft did it, not sure about Google), but yes, we would need to crawl such clusters. 3 - Sitting ourselfs in different geographic locations when performing data collection should be done using different methods (use of proxy's, people from different countries submitting their certificates views..???). Sorry, I don't quite get that? Ralph -- Dipl.-Inform. Ralph Holz I8: Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL trusted root CA reliability (S Korea)
The way you position yourself in the network infra-structure is of very importance when doing data collection. Users of a given ISP may have rogue certificates while others at the same country but another ISP may not. We as researchers need to position ourselves at different network scopes in order to detect more efficiently rogue certificates and thus identifying more effectively doubtful CA's or even individual persons beings monitored. All users reaching the same endpoint should have the same certificate. So this is an important technical aspect that must be addressed carefully. The best way I think would be making users from those countries run some probe (as volunteers) to get their Certificates View. Actually EFF partially advocates this by telling people how to run their SSL Observatory but at the same time they suggest doing it in a Cloud Environment, thus distorting the main purpose of sitting ourselves at different network locations when collecting data. On Thu, Sep 22, 2011 at 5:30 PM, Ralph Holz h...@net.in.tum.de wrote: Hi, study this more carefully and sooner as possible. SSL Observatory from EFF is a step forward but we need more. Their distributed observatory is probably going to help much here, but I can offer the data sets from our paper. I'll put the paper online tomorrow and paste the link here. 1 - We need data on the details of certificates obtained from different geographic/government locations when pointing to popular endpoints such us google, facebook and so on We did not find any differences in the top 200 or so, and the rest did not seem suspicious. See the links in the previous mail for the set of differing certs. 2 - We need to map/take_in_account clustered endpoints, like google, when doing this, since certificates differ in the clusters. We did not observe that too often (Microsoft did it, not sure about Google), but yes, we would need to crawl such clusters. 3 - Sitting ourselfs in different geographic locations when performing data collection should be done using different methods (use of proxy's, people from different countries submitting their certificates views..???). Sorry, I don't quite get that? Ralph -- Dipl.-Inform. Ralph Holz I8: Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ ___ 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] Nirvana
On Sun, Sep 18, 2011 at 11:22 AM, M.R. makro...@gmail.com wrote: On 18/09/11 10:31, Ian G wrote: On the other hand, a perfectly adequate low-level retail transaction security system can best be achieved by using a trusted-third-party, SSL-like system. That's a marketing claim. Best ignored in any scientific discussion. Yes, I agree, let's ignore it! In your view then, is the alternative at all a public key based crypto system? If yes, is it SSH (or SSH-like) trust on first contact or something else? It could vary. For low-security applications, like blog comments, yes, leap-of-faith will do. For a medium-security application, like shopping (where systems like credit card fraud protection render the risk to the user low), security bootstrapped from leap-of-faith + trust-building or trusted third parties will probably do. For high-security applications (like banking) you'll generally want to bootstrap security via something else, either an off-line interaction, or a trusted third party that can authenticate relatively few peers to you (and thus is probably more trustworthy w.r.t. verification of your peer's credentials). Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Security Pop-Up of the Day
On Thu, Sep 22, 2011 at 09:37:42AM +1000, James A. Donald wrote: Email client generates private/public keypair. Sends public key to CA server. CA server certifies that the owner of the private key corresponding to this public key is capable of receiving email at the address, emails certificate it back to ostensible email address. On 2011-09-22 8:35 PM, Paul Walker wrote: User changes email client, or has two clients on different machines. Second certificate is received by CA server. Does it now certify both keys? Sure - what the certificate is a certificate of is that the holder of the corresponding private key can receive email at this address. He should have as many certificates as he has email clients. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Security Pop-Up of the Day
On Thu, Sep 22, 2011 at 09:37:42AM +1000, James A. Donald wrote: Email client generates private/public keypair. Sends public key to CA server. CA server certifies that the owner of the private key corresponding to this public key is capable of receiving email at the address, emails certificate it back to ostensible email address. On 2011-09-22 8:35 PM, Paul Walker wrote: User's machine crashes. How do they tell the CA server that the owner of the public key is no longer capable of receiving email with that private key? If one encrypts a message, and it fails, recipient may reply, could not read your message, try again. Second one will work, because it will be encrypted to the public key associated with that reply. I would suggest a reasonable timeout on the keys, for example 45 days, with the client getting a new key every thirty days. When sending encrypted messages, client attempts to get a reasonably up to date recipient key. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
