Since the uCoin protocol changed deeply during these last months (thanks @cgeek ;-)), I wanted to start adapting the python version of the uCoin clients already existing but not working anymore. I think we get a strong basis regarding the WoT guidelines that should not change before a while. The goal of this topic is to deal with this task and bring back any issues I can encounter during the process. You could find both the projects I have intended to update below:
There is no encryption anywhere, and I don’t remember we had once.
About Scrypt & keys in general, I guess you understand that we generate keys out of thin air (well, out of salt + password). I know this is really useful if we don’t want to store the key, but what if we would like? Do you plan a way of storing the key using encryption with a passphrase?
Yes we had, but like a signature and thanks to the node PGP public key, each time the client got a message the message was verified using both clean and signed texts.
Regarding the salt + password usage I know it but I have not thought about any solutions saving these data yet, but you are right asking the question since the problem did not exist with PGP. I guess I will not store anything and ask to the user to pass them to the functions, same thing occurs for webclient but it should be a feature suggesting users to save or not these data.
Ok, you were talking about multipart/signed, weren’t you? If yes, indeed there is no more such feature. We do it at the application layer, where every message has a signature in it (see UCP, every message should be authentified).
Yes, I personnally would like to save my key somewhere, encrypted of course, with the ability to change the passphrase. Thanks @canercandan
Ok I just remembered it was specific to the uCoin-web client auth mode usage where we wanted to ensure every messages were well coming from their owner. Question still remind is any auth mode still needed ?
Before, you had a 2 step authentication: 1 was the multipart/signed where we verified the message did come from the server (the HTTP response), but we also had another signature for the document. The HTTP signature was made on-the-fly, while the document signature was made by its author when he emitted the document.
BTW, I hesitated a lot regarding the version number, since we changed everything on the protocol, does the major number be incremented or not, but I finally chose to not use this way since we are still in a brainstorming step. The major number will be incremented only when we declare protocol are mature enough to be used.
Dunno if it is wisheable, since each pubkey is ~32 bytes, meaning a 100k members WoT would require a 3.2 Mb response, which is rather big It is probably better for clients to sync with the blockchain for blocks <= 1 year old. This way, the whole WoT can be computed.
But the API is not fixed, we can add several methods. If you have any idea, with the data volume issue in mind, do not hesitate to propose some!