Thank you @cryptosharon!
The encryption for the messages is via memo-key, so the same that Steemit uses.
And the encryption for the keys (to save them locally) is via a node crypto library - should be SHA 256 if I'm correct.
Hmmm, will it be able to listen to the blockchain in real time in the future?
It gets every x minutes the updated account history from the blockchain and checks if there are any new ones in there.
I'll have to read the code to learn the specifics then. :) Thank you for answering.
I'm still curious about the second question. Do you think you'll program an automatic listener to the blockchain stream of events to be able to have real-time notifications of incoming messages?
Maybe a cooperation with gina could be implemented ;)
SHA 256 is hash and therefore asymmetric, I guess you encrypt it by some symmetric cypher. You should enforce strong passwords for the encryption because otherwise it might not be very safe.
You are right about the first part. Sha-256 is a hash function, but it's not symmetric encryption.
symmetric encryption dictates a given key
Kcan be used to both transform plain text into cipher text and vice-versa.A hashing function cannot be reversed because it's a large to small key space function, meaning it's only one way, there's no reversing a hash, unless you try all possibilities until you get the result.
There are publica tables on some hashing algos, they are giant covering hashs for the most known combinations.
But, a SHA-256 as the name suggests generates a 256-bit output.
Since one bit can be represented with two distincts values (i.e. 0 and 1)
we have all the possible combinations being
2^256which is a number I not even know the name.about the string password, that a myth that must fall at any cost.
Humans can NEVER produce strong passwords. It's up to the software engineers and cryptographers to move from a low entropy input to a large entropy input while balancing the computational recurrent cost.
:)
Eloquently put ;)