CfB
Architecture question.
All nodes run the same software, each maintaining synchronized copy of blockchain
Your reflex objection to any secondary authentication is that it can only be implemented using some sort of centralized method, defeating the robustness gained from the distributed nature.
I have been thinking about this at a high level this afternoon, so I am sure not all the details are right, but conceptually if we can implement a "centralized" type of action when all the nodes are running the same software and replicating the same dataset, then authentication could be implemented in a distributed context.
Correct or incorrect?
James
Maybe. Do u have an example of an authentication flow? The description is quite vague.
"Maybe"!!! There is hope, I am glad it wasn't the usual "impossible" response.
Forgive me if I am getting the details wrong as I have not studied the source code yet, but presumably we can guard sending of NXT with an optional authentication step. This would have to be made at the core level as hackers wouldn't be using the secure clients. Each account that wants to enable authentication would need to have an alias that relates <acct#> and <public key>, this way all nodes can do public private key so whichever node forges a block, would have access to all public keys.
There would be many possibilities if we can have a "centralized" processing done by the forging node to implement authentication. One way would be for the transaction details to be signed using a client generated private key independent from the account's passphrase and submitting the blob of bits and account# as the method for sending NXT.
The forging node would process all the encrypted blobs by retrieving the public key alias and decrypting the encrypted blob of bits
Using this approach, only a single change needs to be made to the core, namely support for accepting the authentication encrypted send NXT commands. Also some client changes, but mostly just generating high entropy private keys. A hacker could stumble upon the passphrase for a NXT account but all he gets then is a chance to crack a public/private key that is unique to each account. Since parallel mining goes out the door and the odds of cracking two independent keys for a single account would make it so nobody would even bother.
I also think we could then make the bold (but true) claim that NXT is the most secure crypto (by far). If something, anything, like this can be done, it would go straight to the top of the requested features list. By far. I know it is probably overkill, but that is what people will want. Overkill amount of security.
Crazy or not so crazy?
James
P.S. For the truly paranoid, they can dynamically change their public key alias (say to match google authenticator) within the client software before submitting sending NXT. After sending, they can change their alias to an invalid key so no sending is possible. Of course this now opens the door for requiring securely updating aliases, but I haven't had my coffee yet and about to go offline.
