"Ubiquity Encryption"

[chpio]

Hi,

is encryption a planned feature?
https://en.wikipedia.org/wiki/MaidSafe#Self-Encrypted_Data

[whyrusleeping]

Encryption is very much a planned feature! I have an open spec where I am working out how exactly we will accomplish this here: https://github.com/ipfs/specs/tree/master/keystore

If you have any questions or comments, the issue for that is here: ipfs/specs#3

Note, the spec is still WIP and is nothing yet is 'set in stone'

[jbenet]

also, keystore will handle how we store + manage keys, and how we use them to do crypto operations. it does not say anything about the actual encryption schemes. We'll be supporting most well-known encryption schemes with significant cryptanalysis behind them.

[chpio]

ok, but there is no ubiquity encryption (as showed in the diagram)?

the (simplified) approach:

h1 = hashFunction(data)
dataEnc = encrypt(h1, data) // encrypt data; use h1 as the encryption key
h2 = hashFunction(dataEnc)
publish(h2, dataEnc) // publish encrypted data; use h2 as identifier

that way the content keeps content addressable

[jbenet]

@t128 that diagram is hardly enough to glean exactly what the authors propose. Depending on the definition of the #Cn-y term, It could be either a CBC-like or CTR-like scheme. Since CBC is considered to be much weaker than CTR, the difference matters. Happy to take another look at a better link. Also, AFAICT, that encryption scheme is custom. to my knowledge, it has not been subjected to proper cryptanalysis.

As a policy, we will not implement encryption schemes into the client by default unless they have been subjected to deep cryptanalysis by the cryptography community to warrant trusting them. That said, encryption (like everything else in ipfs) will be pluggable, so a variety of modules will be available. That way, nodes who would risk unproven schemes can do so at their own risk, without requiring nodes who would be more prudent to change (or accept) anything.

So to answer to your question "there is no ubiquity encryption (as showed in the diagram)?" is: It's your decision.

[chpio]

So to answer to your question "there is no ubiquity encryption (as showed in the diagram)?" is: It's your decision.

no, it's a clear no, as it's not enabled by default

[jbenet]

@t128 do you consider your browser to have every website preloaded by default?

[chpio]

no, but i prefer my browser to use https by default

[jbenet]

@t128 i dont think you're understanding me-- you made a strong claim about what I said:

So to answer to your question "there is no ubiquity encryption (as showed in the diagram)?" is: It's your decision.

no, it's a clear no, as it not enabled by default

I'm attempting to illustrate that that is an incorrect claim, as UX things such as the ease of installing modules greatly changes how a system's capabilities are perceived. The reference to browsers points to an example of a system in which it is trivially easy to use ("install and run") arbitrary code. (Users download and run code every time they click a link). Does that clear things up a bit? 😄

[chpio]

Users download and run code every time they click a link

so in your example, the data behind that link would be unencrypted. But the JS on that page could decide to use encryption for the "postloaded"/"ajaxed" content?

if you want a fully pluggable system? why do you "waste" time building a keystore? as any software willing to use encryption could build it by its own.

[jbenet]

so in your example, the data behind that link would be unencrypted. But the JS on that page could decide to use encryption for the "postloaded"/"ajaxed" content?

No, my example just points to "a" (another) system that loads modules trivially easy. It is not implying ipfs will use the browser model. Only stating that it may be easy to install encryption modules for those who explicitly wish to. (browser extensions may be another good example).

I think there are too many perspectives to sync up individually to have much progress in this medium, suggest you swing by #ipfs on irc.

if you want a fully pluggable system? why do you "waste" time building a keystore?

I don't understand what you're getting at.

[chpio]

Ok, i think every "endproduct" should implement encryption by default. i just dont really know if IPFS is an "endproduct" (ipfs get & mounting) or just a library.

[jbenet]

@t128 you're not understanding. there will be encryption by default. the encryption scheme you suggested is not standard and not subject to independent and reputable cryptanalysis so it will not be shipped by default, but anyone will be able to trivially add it.

i just dont really know if IPFS is an "endproduct" (ipfs get & mounting) or just a library.

it's both. try it and see for yourself

[chpio]

it's both. try it and see for yourself

that's what i mean. As an "endproduct" everything you drop eg. in the mounted directory, will get published unencrypted.

[jbenet]

there will be encryption (it is not yet implemented). ipfs is currently at alpha, lots of things are still to be implemented. all this information is readily available. perhaps you might want to search before asking.

[chpio]

ok, i maybe miss understood you. i thought every user (of the IPFS library) have to implement encryption by its own (your example with the browser and JS).

[jmgurney]

@t128 one issue w/ publishing the plaintext hash is that if the hash ever leaks, then anyone in the world can get it, where if only the encrypted version is published, requiring a key to decrypt, then it can never leak.

[flyingzumwalt]

This issue was moved to https://discuss.ipfs.io/t/ubiquity-encryption/355