From @chpio on Mon Apr 06 2015 10:11:54 GMT+0000 (UTC)
Hi,
is encryption a planned feature?
https://en.wikipedia.org/wiki/MaidSafe#Self-Encrypted_Data
Copied from original issue: https://github.com/ipfs/faq/issues/6
From @whyrusleeping on Mon Apr 06 2015 18:29:33 GMT+0000 (UTC)
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: https://github.com/ipfs/specs/issues/3
Note, the spec is still WIP and is nothing yet is âset in stoneâ
1 Like
From @jbenet on Mon Apr 06 2015 20:04:31 GMT+0000 (UTC)
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.
From @chpio on Tue Apr 07 2015 10:54:45 GMT+0000 (UTC)
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
From @jbenet on Tue Apr 07 2015 11:11:51 GMT+0000 (UTC)
@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.
From @chpio on Tue Apr 07 2015 11:15:33 GMT+0000 (UTC)
> 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
From @jbenet on Tue Apr 07 2015 11:17:20 GMT+0000 (UTC)
@t128 do you consider your browser to have every website preloaded by default?
From @chpio on Tue Apr 07 2015 11:18:45 GMT+0000 (UTC)
no, but i prefer my browser to use https by default
From @jbenet on Tue Apr 07 2015 11:23:25 GMT+0000 (UTC)
@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? 
From @chpio on Tue Apr 07 2015 11:36:15 GMT+0000 (UTC)
> 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.
From @jbenet on Tue Apr 07 2015 11:40:21 GMT+0000 (UTC)
> 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.
From @chpio on Tue Apr 07 2015 14:17:41 GMT+0000 (UTC)
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.
From @jbenet on Tue Apr 07 2015 14:23:05 GMT+0000 (UTC)
@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
From @chpio on Tue Apr 07 2015 14:36:16 GMT+0000 (UTC)
> 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.
From @jbenet on Tue Apr 07 2015 14:44:36 GMT+0000 (UTC)
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.
From @chpio on Tue Apr 07 2015 14:50:50 GMT+0000 (UTC)
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).
From @jmgurney on Wed Sep 30 2015 05:58:59 GMT+0000 (UTC)
@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.
Why not to define a new hashing instead of creating a new layer for encryption? this wouldânt need to develop and maintain an additional ecryption database.
I mean, if the hash of the file includes the location hash and the encryption hash, then the file can be managed with the current API. Only the ones who know the complete hash would be able to access it. But the ones who try to access the repository by other means would not be able to see anything.
I don´t know if you take it into account:
1 - ideally it should be at least optional to guarantee that nobody should be able to inspect anything in his local (or remote) IPFS storage unless he provides the IPFS address.
2- This means that the content could be encrypted by default. Otherwise privacy will be compromised.
3- encryption/decryption of the content in the storage, that addresses the previous points can be done transparently using an optional IPFS hashing which could provide symetrical transparent encryption/decription without breaking compatibility with previous versions of IPFS. IPFS admits diffenent hashigs. It is a matter of adding a new one. This hash would have a double role: for addressing and for symetric encryption/decryption
I think that hashing can/should be used no only for content addressing but also for privacy, since only the ones who know the IPFS address should be able to access it.
Am I right? can be done? is it done already?