I have an idea for a public crypto chat for the SAFE network. So, why the need for encryption on an already encrypted network? I read that there are private shares and public shares on the network. And I take it that the public information is accessible in plain unencrypted text for everyone. The purpose of the crypto chat is to make even the public information encrypted.
Or is this function, encryption of public data, already provided by the network?
Check our messenger API in the next couple of weeks. The Network Fileyststem API will follow soon after. Design review again tomorrow so I will post the discussion doc location for you to see. In essence public data is unencrypted (well it’s encrypted but the decryption keys are public). I am not 100% sure what you are looking for so I hope this helps a little
Ok, so the keys for the public data are available to anyone. If someone snoops on the network traffic, then they can read all the public data in plain text I imagine. The purpose of the crypto chat is to have the public data encrypted with keys that are private to individual groups of users.
Ah this is private shares which will be available, but after safecoin is introduced. There will be an API for this so you can use this. The group chat part is client side though I imagine so it could be a neat fit. Sounds like a good project, we will help as much as we can and your welcome to watch the design docs and jira tasks being done to make this happen (at least the chat parts for now).
Has this started to take place on Jira?
Some tasks in place but sprint planning tomorrow.
Looking forward to this;
What kind of encryption algorithm should I use for the crypto chat? AES? I don’t think so! Even without backdoors (I wouldn’t be too sure about that) we have:
"As for the security of encryption, people keep saying a massive supercomputer would have trouble cracking AES256 even if it ran nearly forever. That’s a comparison which makes no sense in this context. Specifically designed hardware can do specific tasks orders of magnitude faster than a general purpose computer. The NSA has its own custom built equipment which was designed entirely with one purpose - cracking encryption. Their equipment is several orders of magnitude ahead of anything else in existence. The second bad assumption is that they would use a brute force attack. They have some of the most brilliant cryptographers ever to live. Why would they resort to brute force? Think about it, if you’re one of the best cryptographers in the world, where would you want to work?
The bottom line? No current encryption scheme is immune to NSA monitoring." – Has the NSA broken SSL? TLS? AES? | ZDNET
My question is rhetorical. I already have an encryption algorithm that will make the NSA totally frustrated. 
Hopefully. More seriously though I’m a bit worried about the encryption being too good. Could be dangerous in the hands of terrorists.
Sounds intriguing, we mix schemes and I am watching lattice based research, it’s very good and likely quantum secure. Don’t worry about being too good, we aim for as strong as possible and even to teh extent of attempting perfect secrecy (OTP) and similar schemes. Anything that protects people will protect all people, so don’t every worry about that. You need to protect everyone, The terrorist thing is really honestly blown out of proportion, more people are killed by bee stings or police officers. Go for protecting all individuals at all times, anything less is never going to work. Upholding laws is for society and not technology, that is my opinion anyway.
Great! My encryption idea is to use a random oracle to hash a salt that is generated for each chat message. A private 256-bit key is xor:ed with the 256-bit hashed salt. The salt and the private key are then hashed again with the random oracle repeated times, enough for all the bytes in the message (the message is padded to max length). The resulting encryption is the xor of the repeatedly hashed salt and the plain text message bytes.
Decryption is done by having the private key which then allows unfolding of the encrypted message.
Here is the random oracle I will use in the crypto chat: Edit fiddle - JSFiddle - Code Playground
Of course, a random oracle is just a theoretical ideal:
“In cryptography, a random oracle is an oracle (a theoretical black box) that responds to every unique query with a (truly) random response chosen uniformly from its output domain. If a query is repeated it responds the same way every time that query is submitted.” – Random oracle - Wikipedia
Still, the algorithm is based on the Rule 30 cellular automaton which produces highly random sequences (when certain cell values are picked). I think it will be good enough.
Some may think that the random oracle in my previous post can easily be analyzed to find a message that produces the hash value. It’s actually likely a difficult task as shown by Stephen Wolfram:
“So can such rules be used for cryptography? I strongly suspect that they can, and that in fact they allow one to construct systems that are at least as secure to cryptanalysis as any that are known. … The picture below shows evidence for this. The cells marked by dots have colors that are taken as given, and then the colors of other cells are filled in according to the average that is obtained by starting from all possible initial conditions.” – Stephen Wolfram, A New Kind of Science, pp. 603, 605.
Have you formed the method to decrypt the hash?
Only the hash for the salt (hs) needs to be calculated.
hs = hash(salt)
header = hs XOR pk
c0 = hash(hs) XOR hash(pk)
ci = hash(ci-1 XOR pk)
i = 1, 2, 3…
Where pk is the private key and ci are the encryption values to be xor:ed with the message.
When having the private key hs is calculated by xor:ing the header with the private key. And with hs the ci values are calculated. The decrypted message is the encrypted text xor the ci values.
(This is just a first draft and I may have missed something but something like that anyway.)
It is worth checking out PBKDF2, we use this and it’s coed and in the common library (crypto.cc). It’s not a duplicate of what you are doing, but another thing to consider really (random rehashing based on salt) it may help when you are in brainstorming mode anyway. We also use common leading bits smoothing to ensure even more even distribution of random info (node addresses in our case) to add to the desired shape of the output of a random oracle type mechanism (which is really what the secure part of the hash is attempting to create).
As I say brainstorming mode, may help, may hinder but always worth a peek.
@Anders what you’re describing is a stream cipher. Yours happens to be built out of a hash function and I can’t find an immediate problem with it. Other stream ciphers can be made out of things like AES (in fact I even think there is a block cipher mode that does just that).
At the end of the day, though, you’re still relying on some crypto primitive – in your case a hash function. Why would it be more secure than a block cipher like AES?
Ok, a stream cipher. I’m not an expert on cryptography. I have learned that xor:ing a plain text message with totally random data is the most secure encryption, especially if done with a one time pad.
I don’t trust AES because NIST can have chosen it as a standard precisely because they can break it which is important for national security reasons. Also, algorithms based on complicated calculations seem shaky to me. Someone could come up with techniques which shortcut the calculations.
The Rule 30 automaton that I have used as a hash function is different. Free from mathematical formulas except the minimal 1-dimensional cellular automaton rule and considered to be computationally irreducible which means that there are no calculation shortcuts possible.
It’s important how the cell values in Rule 30 are picked. For highly random values the cells in the center column are chosen. This is how the pseudorandom generator in Mathematica works, except it uses a truncated version of Rule 30 for speed. In my hash function I use the full cellular automaton to make the period infinite instead of finite as in Mathematica.
The values must also be chosen sparsely to prevent cryptanalysis as explained in a previous post with the quote from Stephen Wolfram. And there is a worst case scenario when the message has the repeated form 01010101010101… and the picture below shows how 7 times the number bits in the message need to be generated before the worst case scenario initial condition becomes fully influenced to make the hash value (pseudo)random. The initial condition is the bits in the message which are set as cell values in the cellular automation before the generations are calculated.
Wow @Anders a whole lot of techtalk.
I’m just a regurlar consumer so I won’t even go there. Maybe you also want to check out crypto.cat
Beside making money through Safecoins, you could further monetize your crypto chat, by offering it like, Zopim.com and Olark.com. (you know a direct chat for companies on their website). I gave the crypto.cat dev te same advice, but it probably wasn’t valuable to him. Because he’s only selling T-shirt and Stickers.
Goodluck
Thanks. I intend to first develop the crypto chat for the SAFE network. I don’t think the chat would work well for ordinary websites or mobile apps since the private keys have to be passed securely between users. Not many people use PGP etc. On the SAFE network passing information securely is the default so that’s a much better use case.