2

I was reading this post: https://medium.com/@alexberegszaszi/lets-bring-the-70s-to-ethereum-48daa16a4b51 and i'm a bit unclear about some of the details. I was hoping someone can shed some more light on this!

He lists 3 use cases for being able to verify RSA signatures which i'm not entirely clear on how that would actually work (bear with me).

Using an RSA key to sign transaction with a contract. This includes your encryption device as well government ID cards.

I'm not sure what is actually meant here. Would I sign a transaction or document using my RSA key and then create a regular ethereum transaction as the payload allowing the contract to identify my RSA real world identity with my ethereum digital identity? Or do I actually sign an ethereum transaction with my RSA key, send it to a contract and have it verify my signature? That's not possible right? And it would also need some lookup table to match the identities.

Verifying certificate structures in smart contracts

Is this suggesting that you could build some PKI infrastructure managed by a smart contract?

Using government ID cards to prove individuality

I'm guessing this works because they can verify that a signed transaction validates against my public RSA key, but that doesn't link it to my ethereum (or uPort) account yet.

Pls hlp.

| improve this question | |
2

Using an RSA key to sign transaction with a contract. This includes your encryption device as well government ID cards.

The main government ID use-case would be to send a signature as data to a contract to prove that you're acting on behalf of the person with that ID. You don't necessarily need to associate an Ethereum address with it - for example, "I, Edmund Edgar with Japanese government ID 12345, am making a formal offer to buy your house for 30 million yen that you can hold me to in a Japanese court" doesn't need to involve an Ethereum address (although I used one to pay for gas) but associating an Ethereum address for future transactions is certainly something you might want to do. Not all use-cases will required the contract to already hold a whitelist of known or approved government identities, although some, like KYC, may well do.

Using government ID cards to prove individuality is as you suggest. Again, you don't necessarily need to associate an Ethereum address, but it may be a useful thing to do.

Verifying certificate structures in smart contracts

As you suggest one of the things you could do is a full PKI implementation, with a list of root certificate authority certificates in the contract. In particular this is useful for things like TLS Notary proofs where you want to check that some data was really published on a particular web page.

| improve this answer | |
  • Thanks, the helped! In the first use case, wouldn't it be possible to replay that transaction? – Syg Aug 15 '17 at 5:10
  • Yes, if you're sending signed data whose meaning varies depending when it is sent (eg I make an offer to buy your house today, you turn it down, then change the price, and the offer has the same ID in the system) then the signed data could potentially be reused in a way that the sender didn't intend. You have to design your contract so this doesn't happen unless it should - for example either the offer expires once taken and making a new offer needs a new ID, or the signed data includes a nonce or an expiry date, or any other material data. – Edmund Edgar Aug 15 '17 at 6:24
  • Yeah, that makes sense. I could replay it on an entirely different contract though, I'm not sure what the implications of that would be, but it might be something to consider – Syg Aug 16 '17 at 10:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.