This tool attempts to be a (nearly) seamless encryption layer behind popular mail clients. It might be close enough to seamless that average non-technical users would benefit (unlike PGP for example...) But I wonder whether important tradeoffs have been made to achieve this.
The ciphire site has a technical design review by Russ Housley and Niels Ferguson:
One concern that I had was not mentioned in the Housley / Ferguson review (unless I missed it...). During registration, there is a challenge/response between the public keyserver and the registering client which is conducted by email. It seems to me that this exchange may present an opportunity for the email host (or a hacker positioned a the email host) to establish itself as a MITM for all future encrypted emails to this address. This may or may not require collaboration with the public keyserver, but in any case it seems possible that this could be a vulnerable point in the system.
I'm sure this will become more clear once ciphire becomes open source... but unless we also get to examine the keyserver code (and perhaps implement an independent keyserver?), we may not be able to assure that MITM is not possible.
Anyway, I'd love to hear comments. Do they get kudos, or the doghouse? Thanks Alan
Sebastian Gottschalk wrote: > Yes, a very deep level. That means that I have a comparingly deep level > insight in and oversight over my system and understanding of operation, > including knowledge of typical, logically derivable and theoretical weak > points.
You are almost certainly more vulnerable than you realize.
Do you really think the last buffer overflow existing in your O/S has been found and patched? Do you realize that SOMEONE knows about the vulnerability weeks (often months) before a patch is publicly available? Do you really think that, over the past several years, you have patched every vulnerability in your O/S before anyone on the planet had a working exploit?
If not, then there really has been opportunity for someone to alter your system, maliciously and without your knowledge. So, what REALLY happens when you type in your passphrase to access your secring?
As I said, you are almost certainly more vulnerable than you realize. Alan
> Do you really think the last buffer overflow existing in your O/S has > been found and patched? Do you realize that SOMEONE knows about the > vulnerability weeks (often months) before a patch is publicly > available? Do you really think that, over the past several years, you > have patched every vulnerability in your O/S before anyone on the > planet had a working exploit?
No. However these exploits either need a bug in the TCP/IP stack (well, no services running...) or user interaction (well, the latest bug in libjpeg was two years ago...) or need to break out of the VM.
> If not, then there really has been opportunity for someone to alter > your system, maliciously and without your knowledge. So, what REALLY > happens when you type in your passphrase to access your secring?
I wonder how a rootkit could modfiy essential system files without altering the SHA-1 checksums... -- Dieser Schrieb stellt eine private Meinungsäußerung des Verfassers im Sinne der gesetzlich garantierten Meinungsfreiheit dar. Wem das nicht passt, der wende sich an das Bundesverfassungsgericht. Viel Erfolg! Key: 0xA0E28D18 FP: 83AE 1136 1E2B 9767 8FB2 7594 4128 1A9E A0E2 8D18
Sebastian Gottschalk writes: > Alan wrote: > > > Do you really think the last buffer overflow existing in your O/S has > > been found and patched? Do you realize that SOMEONE knows about the > > vulnerability weeks (often months) before a patch is publicly > > available? Do you really think that, over the past several years, you > > have patched every vulnerability in your O/S before anyone on the > > planet had a working exploit? > > No. However these exploits either need a bug in the TCP/IP stack (well, no > services running...) or user interaction (well, the latest bug in libjpeg > was two years ago...) or need to break out of the VM.
Such as the javascript invocation of a java applet which broke out of the JVM only about 2 months ago? I must remember to consign Java to the same bin as C when it comes to unsafe languages...
> > If not, then there really has been opportunity for someone to alter > > your system, maliciously and without your knowledge. So, what REALLY > > happens when you type in your passphrase to access your secring? > > I wonder how a rootkit could modfiy essential system files without altering > the SHA-1 checksums...
It would modify the md5sum/whatever executable. Exactly the same way that boot-sector viruses of old would intercept reads to boot sectors, supplying an archived copy of the original to the requester rather than the now-infected one.
Of course, we all keep an md5sum executable on a read-only floppy nowadays, don't we?
Not that that works when you find that your distribution has mysteriously changed libc versions while you weren't paying attention. (Or silently overnight in some distributions.)
And of course, the rootkit would never do something like take control of the loader such that it recognises an external md5sum program being loaded (or generally any program that takes as input one of the files that it knows it has modified)...
Phil -- The answer to life's mystery is simple and direct: Sex and death. -- Ian 'Lemmy' Kilminster.
> Such as the javascript invocation of a java applet which broke out of the > JVM only about 2 months ago?
You mean a javascript yielding an access_denied_exception when accessing the Java objects due to a good browser configuration where however Java must be explicitely enabled for a given site? Do you really think that I'm that naive?
> I must remember to consign Java to the same bin as C when it comes > to unsafe languages...
That's not actually true, but complexity is still the reason why Java applets are disabled by default.
However, I was refering to VMware, so you would need to break out of this one, too. ;-)
> It would modify the md5sum/whatever executable. > [...] > Of course, we all keep an md5sum executable on a read-only floppy nowadays, > don't we?
For me it's a sha1sum executable both on a read-only floppy and a read-only CD-R, self-compiled and running on a LFS system The sha1sums are stored on a read-only-set 32 MB SD-Card. It's damn easy to reliably detect and analyze a modification.
I guess it's time for a fup2csm. -- Dieser Schrieb stellt eine private Meinungsäußerung des Verfassers im Sinne der gesetzlich garantierten Meinungsfreiheit dar. Wem das nicht passt, der wende sich an das Bundesverfassungsgericht. Viel Erfolg! Key: 0xA0E28D18 FP: 83AE 1136 1E2B 9767 8FB2 7594 4128 1A9E A0E2 8D18
"Sebastian Gottschalk" wrote; > It's damn easy to reliably detect and analyze a modification.
Perhaps... that is, a modification made since you took your checksums.
Maybe you are as good as you say. Even so, it is... umm... a bit unusual to broadcast to the world that you believe you cannot be succesfully hacked. Good luck to you.
> Even so, it is... umm... a bit unusual to broadcast to the world that you > believe you cannot be succesfully hacked.
No, I just believe that my system is very reliable and my key should be threat as being safe in terms of compromise. That is what we call guarding the integrity of the key.
> Good luck to you.
Nah, this is hardly based on luck but more on good knowledge and common sense. -- Dieser Schrieb stellt eine private Meinungsäußerung des Verfassers im Sinne der gesetzlich garantierten Meinungsfreiheit dar. Wem das nicht passt, der wende sich an das Bundesverfassungsgericht. Viel Erfolg! Key: 0xA0E28D18 FP: 83AE 1136 1E2B 9767 8FB2 7594 4128 1A9E A0E2 8D18
> Phil Carmody wrote: > > > Such as the javascript invocation of a java applet which broke out of the > > JVM only about 2 months ago? > > You mean a javascript yielding an access_denied_exception when accessing > the Java objects due to a good browser configuration where however Java > must be explicitely enabled for a given site? Do you really think that I'm > that naive?
I mean the vulnerability in Sun's Java Plugin that allowed an attacker to create an Applet which can disable Java's security restrictions and break out of the Java sandbox.
Configuring ones browser to not run JavaScript would also prevent this exploit from kicking in. That doesn't mean that the vulnerability doesn't exist. The world does not revolve around you, Sebastian, and your browser settings are not the arbiter of whether exploits are possible or not.
And which of the words in my question did you think refered to you, and which to a state of naivete? I can only see words that refer to java, javascript, virtual machines and vulnerabilities.
Phil -- Excerpt from Geoff Bulter's Proscriptive Dictionary: aaa Don't use this, there's no such word aaaa Don't use this, there's no such word aaaaa Don't use this, there's no such word
> Configuring ones browser to not run JavaScript would also prevent this > exploit from kicking in. That doesn't mean that the vulnerability doesn't > exist. The world does not revolve around you, Sebastian, and your browser > settings are not the arbiter of whether exploits are possible or not.
Hello, world... the problem that any interaction of Java and JavaScript effectively creates a possibility to break out of the Java VM ist neither nor surprising, in fact it has been known for years and every reliable JavaScript interpreter wouldn't allow it (IE by default does but can be disabled, and Mozilla partitially has a problem with that - this is the only bug here). Now showing one example of realisation doesn't make it a new vulnerability, but justs proofs a known fact.
The bug in Mozilla, which is much more a configuration issue, has be known and Mozilla's JavaScript object access policy allows to fix that configuration. I'm sorry for those who don't know about it.
> And which of the words in my question did you think refered to you, and which > to a state of naivete? I can only see words that refer to java, javascript, > virtual machines and vulnerabilities.
Configuration issues are related to naivety. -- Dieser Schrieb stellt eine private Meinungsäußerung des Verfassers im Sinne der gesetzlich garantierten Meinungsfreiheit dar. Wem das nicht passt, der wende sich an das Bundesverfassungsgericht. Viel Erfolg! Key: 0xA0E28D18 FP: 83AE 1136 1E2B 9767 8FB2 7594 4128 1A9E A0E2 8D18
Sebastian Gottschalk wrote: >Hello, world... the problem that any interaction of Java and JavaScript >effectively creates a possibility to break out of the Java VM ist neither >nor surprising, in fact it has been known for years and every reliable >JavaScript interpreter wouldn't allow it
Well, gee, the notion of a reliable or secure JavaScript interpreter is itself an oxymoron. But to the point you raised: Have you heard of LiveWire? It is a feature designed to do exactly this. Yes, it adds to the risk and seems pretty crazy. But then one could say the very same thing about Javascript; Javascript is a crazy design and terribly risky. The secure thing to do is just turn off Javascript entirely. Unfortunately, doing so greatly reduces the utility of your web browser. It is just plain frustrating that so many web sites out there are so reliant on Javascript, when they don't need to be...
>>Hello, world... the problem that any interaction of Java and JavaScript >>effectively creates a possibility to break out of the Java VM ist neither >>nor surprising, in fact it has been known for years and every reliable >>JavaScript interpreter wouldn't allow it > > Well, gee, the notion of a reliable or secure JavaScript interpreter > is itself an oxymoron. But to the point you raised: Have you heard of > LiveWire? It is a feature designed to do exactly this. Yes, it adds > to the risk and seems pretty crazy.
It's a relic of the Browser War I and fortunately isn't included in ECMAScript.
> But then one could say the very > same thing about Javascript; Javascript is a crazy design and terribly > risky.
JavaScript is risky do to relying on a correct interpreter, but the specification concludes it to be safe. No access to file system, not access to useful configuration data, no cross-site object access (that's where most interpreters fail) and limited functions.
> The secure thing to do is just turn off Javascript entirely. > Unfortunately, doing so greatly reduces the utility of your web browser. > It is just plain frustrating that so many web sites out there are so > reliant on Javascript, when they don't need to be...
You can still limit the access to JavaScript objects in Mozilla/Firefox, which helps a lot.
Hehe, I used these long before they found the bug in the Java plugin. -- Dieser Schrieb stellt eine private Meinungsäußerung des Verfassers im Sinne der gesetzlich garantierten Meinungsfreiheit dar. Wem das nicht passt, der wende sich an das Bundesverfassungsgericht. Viel Erfolg! Key: 0xA0E28D18 FP: 83AE 1136 1E2B 9767 8FB2 7594 4128 1A9E A0E2 8D18
Sebastian Gottschalk wrote: >JavaScript is risky do to relying on a correct interpreter, but the >specification concludes it to be safe.
Can you explain what you mean by "the specification concludes it to be safe"? I'm not sure I understand your meaning.
>No access to file system, not access >to useful configuration data, no cross-site object access (that's where >most interpreters fail) and limited functions.
It is more fundamental than that. Javascript is designed to do things that otherwise only a human can do -- things like submit forms, etc. Subverting the trusted path is dangerous, because it can render previous security assumptions wrong.
>You can still limit the access to JavaScript objects in Mozilla/Firefox, >which helps a lot. > > >user_pref("capability.policy.default.JSException", "noAccess"); ....
Interesting. I didn't know about that. Is this stuff documented or explained anywhere? What do those restrictions do or mean?
>>JavaScript is risky do to relying on a correct interpreter, but the >>specification concludes it to be safe. > > Can you explain what you mean by "the specification concludes it to > be safe"? I'm not sure I understand your meaning.
If the specification is followed then JavaScript doesn't oppose any security risk except retrival of browser-specific information.
>>No access to file system, not access >>to useful configuration data, no cross-site object access (that's where >>most interpreters fail) and limited functions. > > It is more fundamental than that. Javascript is designed to do > things that otherwise only a human can do -- things like submit > forms, etc.
The only problem would be a , where the value-attribute is writeable and the submit()-function is not omitted, viloating the specification.
> Subverting the trusted path is dangerous, because it > can render previous security assumptions wrong.
Look at what JavaScript can do and what it can't.
>>You can still limit the access to JavaScript objects in Mozilla/Firefox, >>which helps a lot. >> >> >>user_pref("capability.policy.default.JSException", "noAccess"); > ... > > Interesting. I didn't know about that. Is this stuff documented > or explained anywhere?
MozDoc.
> What do those restrictions do or mean?
The deny access to specific JavaScript objects, either generally or attributed by get or set, and specific non-default policies can be defined for collections of websites. Just like the security zone model in IE, but this one actually works. ;-) -- Dieser Schrieb stellt eine private Meinungsäußerung des Verfassers im Sinne der gesetzlich garantierten Meinungsfreiheit dar. Wem das nicht passt, der wende sich an das Bundesverfassungsgericht. Viel Erfolg! Key: 0xA0E28D18 FP: 83AE 1136 1E2B 9767 8FB2 7594 4128 1A9E A0E2 8D18
Sebastian Gottschalk wrote: >If the specification is followed then JavaScript doesn't oppose any >security risk except retrival of browser-specific information.
I don't know. Perhaps I'm just a pessimist about these things, but I wonder whether this is an optimistic view. For instance, take a look at the following web page, which lists Mozilla security vulnerabilities over the past few years. http://www.mozilla.org/projects/security/known-vulnerabilities.html The overwhelming majority of security holes shown there involve Javascript.
>> It is more fundamental than that. Javascript is designed to do >> things that otherwise only a human can do -- things like submit >> forms, etc. > >The only problem would be a , where the value-attribute >is writeable and the submit()-function is not omitted, viloating the >specification.
How sure are you that this is the only risk? What about the fact that Javascript can change to a new URL, can overwrite elements of the address bar or hide it, can change (after it has been loaded!) the contents of a web page or image, can simulate a click on a link, can move, resize, raise, and lower windows, can read and write cookies? That's a lot of dangerous functionality. Sure, many Javascript implementations try to include limits on when and how these functionalities can be invoked, but getting those limits right is invariably complex, and it should come as no surprise that historically there have been many bugs in doing so. I see little reason to think that we have seen the last Javascript security hole.
>>>user_pref("capability.policy.default.JSException", "noAccess"); >> ... >> >> Interesting. I didn't know about that. Is this stuff documented >> or explained anywhere? > >MozDoc.
Can you elaborate a little more? What's a MozDoc? A google search didn't immediately turn up anything that explained those settings, but this sounds quite interesting. Thanks for any pointers.
>>If the specification is followed then JavaScript doesn't oppose any >>security risk except retrival of browser-specific information. > > I don't know. Perhaps I'm just a pessimist about these things, but > I wonder whether this is an optimistic view. For instance, take a > look at the following web page, which lists Mozilla security vulnerabilities > over the past few years.
Yeah, the big problem about a complex specification is to implement it correctly and because ECMAScript is just a subset of JavaScript. That's why it can still be a big issue.
> http://www.mozilla.org/projects/security/known-vulnerabilities.html > The overwhelming majority of security holes shown there involve Javascript.
The implementation of JavaScript in Mozilla through Gecko engine is very different from typical implementations, that's why is hard to manage correctly.
>>> It is more fundamental than that. Javascript is designed to do >>> things that otherwise only a human can do -- things like submit >>> forms, etc. >> >>The only problem would be a , where the value-attribute >>is writeable and the submit()-function is not omitted, viloating the >>specification. > > How sure are you that this is the only risk? > What about the fact that Javascript can change to a new URL,
That what a meta refresh, an IFrame or even a simple Link can do.
> can overwrite elements of the address bar or hide it
It doesn't have this ability.
> can change (after it has been loaded!) the contents of a web page or image,
Do you know what multipart/stream content is? Well, dumb IE users are safe from that useful thing. :-)
> can simulate a click on a link,
It doesn't have this ability.
> can move, resize, raise, and lower windows,
Which is good to be disabled and especially is totally useless for tabbed browsing. Tabbrowser Extension is configured as "open new tabs only on demand". ;-)
> can read and write cookies?
Which is essentially the same as in HTTP header. And is fully under control of the browser's cookie options.
> That's a lot of dangerous functionality. Sure, many Javascript > implementations try to include limits on when and how these functionalities > can be invoked,
In fact all those limitations are defined in the ECMAScript specification. Except of the visited-Attribution of CSS read limitation it's fully implemented in Mozilla.
> but getting those limits right is invariably complex, > and it should come as no surprise that historically there have been many > bugs in doing so.
Many of these bugs are related to the same objects, that's why configuring object access is a good alternative to fully disabling it.
Both the ECMAScript and Netscape's JavaScript specifications are useable to get an overview about standard and custom script objects. -- Dieser Schrieb stellt eine private Meinungsäußerung des Verfassers im Sinne der gesetzlich garantierten Meinungsfreiheit dar. Wem das nicht passt, der wende sich an das Bundesverfassungsgericht. Viel Erfolg! Key: 0xA0E28D18 FP: 83AE 1136 1E2B 9767 8FB2 7594 4128 1A9E A0E2 8D18
Sebastian Gottschalk wrote: >Yeah, the big problem about a complex specification is to implement it >correctly
Yup. Another big problem with a complex specification is that it is hard to know whether you got the spec right (let alone the implementation of that spec).
Alan wrote: > I've seen a couple of articles [...] > http://www.wired.com/news/infostructure/0,1377,66324,00.html?tw=wn_tophead_4 [...]
> Anyway, I'd love to hear comments. Do they get kudos, or the doghouse?
We can reasonably disagree with some design decisions, note forms of attack against which it cannot defend, and doubt its potential for wide adoptions. Nevertheless, it's kudos. Definitely kudos.
> But I wonder whether important tradeoffs have been made to achieve > this.
The key is stored at the server, you must fully trust the server in any phase of key handling, it's vulnerable against MITM and it's completely incompatible with OpenPGP/MIM and S/MIME. -- Dieser Schrieb stellt eine private Meinungsäußerung des Verfassers im Sinne der gesetzlich garantierten Meinungsfreiheit dar. Wem das nicht passt, der wende sich an das Bundesverfassungsgericht. Viel Erfolg! Key: 0xA0E28D18 FP: 83AE 1136 1E2B 9767 8FB2 7594 4128 1A9E A0E2 8D18
> If I read their stuff correctly, the private keys are not held at the > server. How would you do an MITM?
Put the keyserver address in the hosts-file with a wrong IP, put a fake keyserver at that IP, intercept the request for other public keys and replace them with keys you own, then intercept the outbound messages, decrypt, store, reencrypt with the real public keys.
Just like with PGP, really, but with the added twist that the user cannot choose a different keyserver and has limited ability (and knowledge) on checking wether the public key is genuine.
Juergen Nieveler -- Can you import the garbage. He will die next week which means CIO will be caught in the rain.
"Juergen Nieveler" wrote in message news:Xns95E5A9F75C4FAjuergennieveler@nieveler.org... Volker Hetzer" wrote: > How would you do an MITM?
And Juergen answered: > Put the keyserver address in the hosts-file with a wrong IP, put a fake > keyserver at that IP, intercept the request for other public keys and > replace them with keys you own, then intercept the outbound messages, > decrypt, store, reencrypt with the real public keys.
I'm not sure that would work, except perhaps in limited circumstances. Somehow the substituted certificate would have to include the intended recipient's email address, but the attacker's public key. All this would have to be signed by a CA whose certificate is signed by the root CA. So only someone trusted by the root CA could do this. So, for example, law enforcement might be able to do this and get away with it. Someone else might be able to do this until caught, after which their CA certificate would likely be revoked.
No, it isn't. Only the public key is stored at the server, the private key is generated and stored locally.
Ciphire is nothing more than a specialised keyserver that allows only one key per email address, and a local proxy application that automatically pulls keys for recipients that it doesn't know already.
About the worst I can say so far about Ciphire is that it's incompatible and thus will split the already confused userbase that acknowledges the need for crypto even more, that it doesn't allow for a firm trust relationship between users (no web-of-trust, no Root CA worth the name), and that the "signature" made with Ciphire is only equivalent to a Class1- certificate in S/MIME or a Key signed by a RobotCA in PGP.
Juergen Nieveler -- If it seems too good to be true, it probably is
"Sebastian Gottschalk" schrieb im Newsbeitrag news:167z5yyuavnny$.dlg@news.individual.de... > Alan wrote: > > > But I wonder whether important tradeoffs have been made to achieve > > this. > > The key is stored at the server, you must fully trust the server in any > phase of key handling, it's vulnerable against MITM and it's completely > incompatible with OpenPGP/MIM and S/MIME. If I read their stuff correctly, the private keys are not held at the server. How would you do an MITM?
> I'm not sure that would work, except perhaps in limited circumstances. > Somehow the substituted certificate would have to include the intended > recipient's email address, but the attacker's public key.
Indeed.
> All this would have to be signed by a CA whose certificate is signed > by > the root CA.
From what I've read on their website, the whole thing relies on the keyserver itself being trustworthy - it's the keyserver that checks the keys, the user himself can't do that.
> So only someone trusted by the root CA could do this. So, for example, > law enforcement might be able to do this and get away with it. > Someone else might be able to do this until caught, after which their > CA certificate would likely be revoked.
How would the user find out? The whole point of Ciphire is to make the user forget about it running in the background. The user gets "protected" from having to learn about stuff like root certificates - which is one of my main criticisms about Ciphire.
It would easily have been possible to implement Ciphire by setting up a plain old x.509-based CA that automatically processes certificate requests via email and retrieves the signed certificate from the CA to store it on the client machine. The proxy application could then sign/encrypt the mail body pretty much like they're doing now.
Upside: It would be compatible to existing S/MIME-capable systems, while still being just as safe as the Ciphire-system (their system is equivalent to Class1-S/MIME).
Downside: You won't make any money doing that - Ciphire intends to earn money by selling corporate mail encryption gateways, but corporate systems already support S/MIME.
So, Kudos for trying to raise awareness to the importance of mail encryption, but no thanks to yet another proprietary standard - care to imagine the flamewar we'd already be seeing if Microsoft had come up with Ciphire? :-)
Juergen Nieveler -- Women are like watches: The finer the movement, the better the time
> From what I've read on their website, the whole thing relies on the > keyserver itself being trustworthy - it's the keyserver that checks the > keys, the user himself can't do that.
That's not what I read.
From section 2.4, page 7, of previously linked design review doc:
"To avoid this complex trust relationship in the Ciphire system, certification actions are publicly auditable. The Ciphire Fingerprint System (see chapter 7 for further details) uses hash values and hash chaining techniques13 to create a log that is easily verified by any Ciphire client. Hash chaining is a method for cryptographically linking data; it ensures that previous log entries cannot be changed without invalidating later ones. In this way, all Ciphire CA actions are open to scrutiny by all Ciphire clients."
And from 7.2.2, page 23:
"All fingerprint data is made available to clients, and the clients use it to authenticate certificates. The client calculates the certificate fingerprint and then compares it with the entry provided by the Ciphire CA. If they match, the certificate is considered valid."
> How would the user find out? The whole point of Ciphire is to make the > user forget about it running in the background. The user gets > "protected" from having to learn about stuff like root certificates - > which is one of my main criticisms about Ciphire.
The "user" doesn't find out but his client software does. Maybe that is an important distinction, or maybe not. Assuming the client source code passes review once it becomes open source, that may be a non-issue.
> It would easily have been possible to implement Ciphire by setting up a > plain old x.509-based CA that automatically processes certificate > requests ..
True. However, section 6.1 discusses the tradeoffs involved. The reviewers believe that the ciphire system has some advantages for their particular design goals.
> Downside: You won't make any money doing that - Ciphire intends to earn > money by selling corporate mail encryption gateways, but corporate > systems already support S/MIME.
I'm not really interested in the corporate side of ciphire (though the authors obviously are), but am more interested in the freeware / personal use possibilities. It seems obvious to me that all the previously existing options for encrypting email are useless for the majority of people due to their complexity. Most of the people to whom I send email will never use PGP or even S/MIME. I would like to have secure communications with them but it just won't happen until something better is introduced. Ciphire lowers the bar. I don't know if it lowers it enough, and I don't know if the tradeoffs are acceptable. But I'm glad to see someone trying to address the problem in a substantial way.
"Sebastian Gottschalk" wrote in message news:167z5yyuavnny$.dlg@news.individual.de... > The key is stored at the server, you must fully trust the server in any > phase of key handling, it's vulnerable against MITM and it's completely > incompatible with OpenPGP/MIM and S/MIME.
Compatibility is an obvious issue...but since virtually nobody is using those products anyway (as a percentage of all email users), that is not an important issue for most people.
Perhaps you must fully trust the key server during the registration process, but the Housley/Ferguson review did not point that out. There are some safeguards. According to the review, the hybrid trust model (hierarchical plus distributed) prevents malicious replacement of the public keys in a certificate (e.g., to allow man-in-the-middle attacks); and Malicious changes to one or more certificate fields, such as the validity dates or email address in the subject of the certificate. (section 7.2.1).
However, an attacker positioned at the mail server (not key server) apparently could register impersonating the victim. Then third parties who use ciphire might believe they are sending encrypted mail to the victim, while the attacker would be decrypting and reading all the mail from his MITM position.
I'm not sure what would happen if the victim subsequently tried to register. With collaboration from the key server, it should be possible to convince the victim that his registration was successful.
> "Sebastian Gottschalk" wrote in message > news:167z5yyuavnny$.dlg@news.individual.de...
Hm... do you know why they call it "attribution line" and not "lines"?
>> The key is stored at the server, you must fully trust the server in any >> phase of key handling, it's vulnerable against MITM and it's completely >> incompatible with OpenPGP/MIM and S/MIME. > > Compatibility is an obvious issue...but since virtually nobody is using > those products anyway (as a percentage of all email users), that is not an > important issue for most people.
Well, we don't need a solution for the masses at all, because the largest part of users are simply unable to protect the key. We would get a massively encryption-enhanced communication where we can't trust anyone because at least half of the world has full access to their private keys.
No, thanks. -- Dieser Schrieb stellt eine private Meinungsäußerung des Verfassers im Sinne der gesetzlich garantierten Meinungsfreiheit dar. Wem das nicht passt, der wende sich an das Bundesverfassungsgericht. Viel Erfolg! Key: 0xA0E28D18 FP: 83AE 1136 1E2B 9767 8FB2 7594 4128 1A9E A0E2 8D18
"Sebastian Gottschalk" wrote: > Well, we don't need a solution for the masses at all, because the largest > part of users are simply unable to protect the key.
In that respect, ciphire is not at all different from PGP etc. How sure are you that nobody can steal (has stolen) your PGP key and passphrase? Is your computer invulnerable to attack? We should take those things into account in the degree of trust we place in encryption, digital signatures etc, regardless of which tool is being used. That doesn't mean there is nothing to be gained from the tool.
>> Well, we don't need a solution for the masses at all, because the largest >> part of users are simply unable to protect the key. > > In that respect, ciphire is not at all different from PGP etc. How sure are > you that nobody can steal (has stolen) your PGP key and passphrase?
I'm pretty sure, that's why the system actually works.
> Is your computer invulnerable to attack?
At least to a very deep level. Well, in case that the secring leaks there would be still a password to break.
> [...] > That doesn't mean there is nothing to be gained from the tool.
It takes the approach to etablish a new standard of mail encryption that is incompatible to anyone who uses encryption seriously. -- Dieser Schrieb stellt eine private Meinungsäußerung des Verfassers im Sinne der gesetzlich garantierten Meinungsfreiheit dar. Wem das nicht passt, der wende sich an das Bundesverfassungsgericht. Viel Erfolg! Key: 0xA0E28D18 FP: 83AE 1136 1E2B 9767 8FB2 7594 4128 1A9E A0E2 8D18
I queried: > How sure are you that nobody can steal (has stolen) your PGP key and passphrase?
And Sebastian replied: > I'm pretty sure, that's why the system actually works.
"Pretty sure"... hmm... Usually cryptographers aspire to a higher level of confidence than that.
I continued querying: > Is your computer invulnerable to attack?
To which Sebastian replied: > At least to a very deep level. Well, in case that the secring leaks there > would be still a password to break.
You say, "a very deep level". But I detect a little little naivete. Given the ability to steal the secring, you must assume that the passphrase is exposed. Couldn't the attacker also install a key logger while they are in your box? Perhaps you are more vulnerable than you think.
The world isn't divided into the knowledgeable secure and the ignorant insecure. It is a continuum of varying degrees of insecurity. Being knowledgeable is an advantage, but it is not a guarantee of security. In fact it might make you a more valuable target, making you less secure.
>> How sure are you that nobody can steal (has stolen) your PGP key and >> passphrase? > > And Sebastian replied: >> I'm pretty sure, that's why the system actually works. > > "Pretty sure"... hmm... Usually cryptographers aspire to a higher level of > confidence than that.
Ahmm... crypto is no magic, it ensures privacy and integrity of data but demands integrity of the key. For every respectably crypto algorithm the key is always the weakest part, and that's neither special nor new. The system raises and falls with the key, and you can't gain any more confidence than that.
> I continued querying: >> Is your computer invulnerable to attack? > > To which Sebastian replied: >> At least to a very deep level. Well, in case that the secring leaks there >> would be still a password to break. > > You say, "a very deep level".
Yes, a very deep level. That means that I have a comparingly deep level insight in and oversight over my system and understanding of operation, including knowledge of typical, logically derivable and theoretical weak points.
> But I detect a little little naivete.
I don't claim to be invulnerable, but finding a vulnerability should go beyond anything reasonably possible.
> Given the ability to steal the secring, you must assume that the passphrase is > exposed.
No. In fact it should be way harder to modify a running system rather than reading some data without any additional tools.
> Couldn't the attacker also install a key logger while they are in your box?
That is a way worse and way less probable case.
> Perhaps you are more vulnerable than you think.
Perhaps, but neither probably nor reasonably assumeable.
> The world isn't divided into the knowledgeable secure and the ignorant > insecure. It is a continuum of varying degrees of insecurity. Being > knowledgeable is an advantage, but it is not a guarantee of security. In > fact it might make you a more valuable target, making you less secure.
According to one specific property security is purely binary -- either you're secure or not, either there is a non-user-interactive way to compromise the system or not. Using Outlook Express means that you are insecure and that you must reasonably assume that your key is compromised as soon as you receive just one mail. ;-) -- Dieser Schrieb stellt eine private Meinungsäußerung des Verfassers im Sinne der gesetzlich garantierten Meinungsfreiheit dar. Wem das nicht passt, der wende sich an das Bundesverfassungsgericht. Viel Erfolg! Key: 0xA0E28D18 FP: 83AE 1136 1E2B 9767 8FB2 7594 4128 1A9E A0E2 8D18
> Well, we don't need a solution for the masses at all, because the > largest part of users are simply unable to protect the key. We would > get a massively encryption-enhanced communication where we can't trust > anyone because at least half of the world has full access to their > private keys.
How would that hurt you? You don't know wether you can trust unsigned mail, so it doesn't really get any worse, does it? You know who you can trust to protect his private key because that person either uses OpenPGP and has signatures on his key, or s/he has at least a Class3 certificate.
But at the very least all the mail traffic would be encrypted, meaning that the really important confidential mails wouldn't stand out as much in traffic analysis anymore - the three-letter-guys wouldn't like that at all :-)
Juergen Nieveler -- Incoming fire has the right of way.
> Compatibility is an obvious issue...but since virtually nobody is > using those products anyway (as a percentage of all email users), that > is not an important issue for most people.
Not many people use Crypto, but the vast majority of users actually HAVE the necessary tools already installed: Most modern clients support S/MIME.
All the user needs to do is get a free certificate (CACert, Thawte, Trustcenter.de), and send a signed mail to all his friends. Without any mentionable effort he has now the ability of signing and encrypting his mail with at least the same degree of security and confidence in his signature as is provided by Ciphire.
Juergen Nieveler -- Multitasking: screw up several things at once
