In many cases, and especially the situations I'm looking at, the "other end" is not the server. The other end is an individual (or group of individuals). In such cases only these individuals should have access to the cleartext, and the server should just act as a relay between them (optionally storing the ciphertext).domob wrote:Can you please elaborate, why you don't consider HTTPS / TLS to be "end-to-end encryption"? After all, when I visit a website, the "other end" is the website's server. It must always have the ability read the cleartext, and thus your second point is IMHO something which simply can't be avoided with any system. How would it be different if we used another encryption system?
CA alternatives [mysterious magical discussion]
Re: mysterious magical discussion with a terrible title
Re: CA alternatives [mysterious magical discussion]
I'm primarily concerned with communication between humans, we've not yet reached the point where we have to protect sentient machines.
-
- Posts: 541
- Joined: Mon May 20, 2013 12:03 pm
- Contact:
Re: mysterious magical discussion with a terrible title
Yes but this is not a .bit domain specific problem.pmc wrote:
The problem is not one of encryption but of authentication. Once you have authenticated the other side you can set up a secure encrypted channel with PFS.
A compromised CA enables a MITM to authenticate himself as the target domain, and thereby break into the communication. The only way around this is to get rid of CAs.
A slightly better alternative to CAs is DANE/DNSSEC. The problem here is, of course, that you have to trust the DNS root keys, your TLD's keys and your own DNS operator...
As far as I understood exactly this is intended to be solved by Biolizard's convergence. I am not sure how far is this working at the moment but it shouldn't require any centralized CA only self signed certificates where the TLS fingerprints are stored in the blockchain.
The Namecoin blockchain could provide decentralized certificate authority even for non .bit domains.
However it depends of the browser abilities to support it and the domain owners willingness to implement it.
Surely this is a server - user communication because the webpage content is provided to many users.
If you want to use p2p communication then you can use torchat but .bit domains are intended primary to deliver content from server to user so it can be used only a server-user level encryption.sugarpuff wrote: In many cases, and especially the situations I'm looking at, the "other end" is not the server. The other end is an individual (or group of individuals). In such cases only these individuals should have access to the cleartext, and the server should just act as a relay between them (optionally storing the ciphertext).
I am not sure but may be are you meaning that the user even if he was redirected from the domain name to the right IP he cannot be sure that the server with the content was not hijacked.
This is again not a Namecoin specific problem.
However I was thinking about how could Namecoin prevent such attacks.
What about embedding in the domain entry additionally to the TLS fingerprint a content GPG public key, where the corresponding private key wouldn't be on the server but by the person who is redacting the content. Every time the content deliverer is actualizing the content needs to put to a specific place (for ex in the html header in a special tag) the content signature.
The browser (with a special plugin or special browser) would check the content signature against the content and the public key (in the Namecoin blockchain) and could authenticate with 100% security that it comes from the author.
Content hijacking would be never ever possible on the world.
Here would be a content editor - user authentication which would be much secure then server-user authentication. (encryption would remain on server-user, there is no other possibility for unidentified and unregistered users)
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S
Re: mysterious magical discussion with a terrible title
I am not talking about p2p communication specifically, but rather communication in general, whether it's p2p, or a server-client situation. I was also not referring to the content that the server delivers (in the sense of web pages), but rather I was focusing on the communication that servers route between users.virtual_master wrote:If you want to use p2p communication then you can use torchat but .bit domains are intended primary to deliver content from server to user so it can be used only a server-user level encryption.sugarpuff wrote: In many cases, and especially the situations I'm looking at, the "other end" is not the server. The other end is an individual (or group of individuals). In such cases only these individuals should have access to the cleartext, and the server should just act as a relay between them (optionally storing the ciphertext).
I am not sure but may be are you meaning that the user even if he was redirected from the domain name to the right IP he cannot be sure that the server with the content was not hijacked.
This is again not a Namecoin specific problem.
Namecoin + DNS can fix this, which is the project that I'm working on. I hope to post more details soon.
Regarding storing GPG keys in the keychain, there's a discussion about that in this thread:
http://dot-bit.org/forum/viewtopic.php?f=5&t=1163
In there I object on the grounds that storing the entire key is not necessary, and that it would bloat the blockchain for no good reason, which would have an impact on bringing new DNS servers and other NMC clients online.
Storing fingerprints of the public key is totally cool though (and something I'll be relying on).
-
- Posts: 541
- Joined: Mon May 20, 2013 12:03 pm
- Contact:
Re: mysterious magical discussion with a terrible title
That thread is generally about the size of the value field.sugarpuff wrote: Regarding storing GPG keys in the keychain, there's a discussion about that in this thread:
http://dot-bit.org/forum/viewtopic.php?f=5&t=1163
The GPG addressed there was related to the ID. Here I brought a new idea to store the GPG in the domain entry to secure the content and was not related to the value field size.
Your argumentation was based on the worry about the blockchain size in a couple of generations which will be not a problem as I demonstrated.sugarpuff wrote: In there I object on the grounds that storing the entire key is not necessary, and that it would bloat the blockchain for no good reason, which would have an impact on bringing new DNS servers and other NMC clients online.
Storing fingerprints of the public key is totally cool though (and something I'll be relying on).
Namecoin have to solve the issues facing now and not that far in time. If we don't solve the actual problems then there will be no Namecoin in 60 years.
Of course could be stored for every entry only the hash of all but then why we need Namecoin ? The hash can be stored in 80 bits also on the Bitcoin chain. Even this is to much. You need to make a Merkle tree and to store only the root hash and update it. As more complicated you make it as more difficult will be to implement it.
But if you can present a really good solution I am ready to change my mind.
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S
Re: mysterious magical discussion with a terrible title
Of course, but the CAs actually are eliminated if you use TLS with Namecoin (like Convergence for Namecoin is doing). So that's not the question here.pmc wrote:The problem is not one of encryption but of authentication. Once you have authenticated the other side you can set up a secure encrypted channel with PFS.domob wrote:Can you please elaborate, why you don't consider HTTPS / TLS to be "end-to-end encryption"? How would it be different if we used another encryption system?sugarpuff wrote:End-to-end encryption, therefore, is the only reliable solution, and HTTPS does not offer that.
- 3. HTTPS + PFS does not (I don't think) protect against active MITM attacks involving compromised CA certs.
A compromised CA enables a MITM to authenticate himself as the target domain, and thereby break into the communication. The only way around this is to get rid of CAs.
A slightly better alternative to CAs is DANE/DNSSEC. The problem here is, of course, that you have to trust the DNS root keys, your TLD's keys and your own DNS operator...
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: mysterious magical discussion with a terrible title
If you don't trust the HTTP server (and of course you shouldn't), wouldn't something like the WebPG extension be sufficient? https://webpg.org/ Probably wouldn't be hard to get it to work with Namecoin....sugarpuff wrote:I am not talking about p2p communication specifically, but rather communication in general, whether it's p2p, or a server-client situation. I was also not referring to the content that the server delivers (in the sense of web pages), but rather I was focusing on the communication that servers route between users.virtual_master wrote:If you want to use p2p communication then you can use torchat but .bit domains are intended primary to deliver content from server to user so it can be used only a server-user level encryption.sugarpuff wrote: In many cases, and especially the situations I'm looking at, the "other end" is not the server. The other end is an individual (or group of individuals). In such cases only these individuals should have access to the cleartext, and the server should just act as a relay between them (optionally storing the ciphertext).
I am not sure but may be are you meaning that the user even if he was redirected from the domain name to the right IP he cannot be sure that the server with the content was not hijacked.
This is again not a Namecoin specific problem.
Namecoin + DNS can fix this, which is the project that I'm working on. I hope to post more details soon.
Regarding storing GPG keys in the keychain, there's a discussion about that in this thread:
http://dot-bit.org/forum/viewtopic.php?f=5&t=1163
In there I object on the grounds that storing the entire key is not necessary, and that it would bloat the blockchain for no good reason, which would have an impact on bringing new DNS servers and other NMC clients online.
Storing fingerprints of the public key is totally cool though (and something I'll be relying on).
Using the Namecoin blockchain to sign web pages sounds kind of cool too. The proposed hash/ namespace could be used to sign individual resources, and a field in the d/ namespace could be used to specify which keys are authorized to sign via hash/. Just thinking out loud here....
Re: mysterious magical discussion with a terrible title
Sufficient to do what, precisely?biolizard89 wrote:If you don't trust the HTTP server (and of course you shouldn't), wouldn't something like the WebPG extension be sufficient? https://webpg.org/ Probably wouldn't be hard to get it to work with Namecoin....
Maybe I'm misunderstanding something... or are you actually suggesting storing a hash of every webpage on the internet in the blockchain?!?Using the Namecoin blockchain to sign web pages sounds kind of cool too. The proposed hash/ namespace could be used to sign individual resources, and a field in the d/ namespace could be used to specify which keys are authorized to sign via hash/. Just thinking out loud here....
Re: CA alternatives [mysterious magical discussion]
Just to point out, the reason you use perfect forward secrecy, is so if an attacker is recording all the encrypted communication, they will be unable to decrypt it if they manage to get the private key stored on the server.Even if they all supported HTTPS with PFS, it wouldn't matter! Why? Because PFS only protects the data whilst enroute to the server (and away from it). Once it reaches the server, the security is completely undermined because companies will store it in the clear in their databases (or encrypted, but the companies hold the keys, which effectively amounts to plain-text).
Your argument is the same as the fact the server could be recording the ephemeral keys.