EthAddressAttestation and EthAddressLinkageAttestation

[SmartLayer]

Note that in making schema for these 2, the first attestation's subjectPubKey is an RSA key, and the 2nd attestation is signed by an RSA key.

Given the cost of a transaction of 68 gas per byte†, it's quite punishing to use RSA. Suppose 4k RSA is used, it means 512 bytes in SubjectPublicKey of the NFTOwnershipAttestation and another 512 bytes in the signature of EthAddressLinkageAttestation, 8 times the size of secp256k1. Also the signature verification costs 5580 or 89292 gas‡ (equivalent of 82 to 1313 bytes), while secp256k1 costs 3000 gas.

† https://medium.com/coinmonks/on-efficient-ethereum-addresses-3fef0596e263
‡ https://ethereum.stackexchange.com/questions/71728/after-eip-198-introduction-how-much-gas-is-required-for-rsa-signature-verificat

That is 26112 additional gas cost per transaction, ignoring verification cost.

What would be the consequence if we go down to 2k RSA? Note that the 2nd attestation has very short expiry, it was created for a transaction and only need to stay valid till it is embedded in the blockchain, so reducing security doesn't expose too much attack surface (I hope.)

[jot2re]

2048 bit RSA should be sufficient here. In particular, as you mention, the expiry of the RSA signing key is very short. So as long as the signing key of the first attestation (i.e. the signing key that signs the public RSA key) is either a secp256k1 or 3096 bit RSA key, things should be fine for our purpose.

[jot2re]

I would even say, that if the expiry of the public RSA key is less than a day, we could go down to 1024 bits. Since even that would realistically take a year to crack with a huge cluster.

[SmartLayer]

I would even say, that if the expiry of the public RSA key is less than a day, we could go down to 1024 bits. Since even that would realistically take a year to crack with a huge cluster.

Yes we can make the RSA key expire in 1 day. Let's go with 1024 bits, since the gas cost is very sensitive in today's environment...

[micwallace]

Hey both,

I made some progress on Friday and today in regards to the safe connect flow:
https://github.com/TokenScript/safe-connect-demo/blob/attestation-method/example/src/attestation.ts
You can see a simple simulation here that demonstrates the process. I've also started integrating this process into the safe connect demo and direct integration example.

Looking for feedback in regards to the schemas of each attestation.

I think the main thing I will need help with is the smart contract validation. But first we need to lock in the schemas.

[jot2re]

@micwallace thanks for the good work!
I think that both of them still need a notBefore and notAfter timestamp. I think the NFT attestation also needs some context variabel, to allow use to associate different aspects to what is certified. E.g. if the NFT ID is the real one or a pseudonym

[micwallace]

@jot2re please explain to a noob why the notBefore timestamp is needed if the server is setting the expiry variable? 😂

For the context variable, maybe we can put a free-form field where the website can set any string they want in the initial request to safe connect. That will make it super flexible.

I'm not sure if we will be sharing NFT attestations across different third party websites, so the need to know if a tokenId is the real one or a pseudonym might be redundant since the website that requested the attestation should already know what was requested. But if you don't think so we should have a boolean or small integer value to indicate this.

[jot2re]

notBefore is not strictly needed if the server is guaranteed to be honest and always have a correct clock set. It is more an issue if the server the issuer can be untrusted. However, it also is used to protect against misconfigurations (i.e. wrong time set).
It can also be used to make non-repudiation better, since now the signed attestation uniquely defined how long time it will be valid.
So it is strictly needed for the Ethereum Key Linking Attestation, but not for the NFT Ownership Attestation (although it would still be best-practice to have have it there as well).

About the context variable; I was also thinking some sort of free-form variable. I was also imagining that this variable will contain any information about the NFT ID if needed. So no need to add a separate variable about this.

[jot2re]

One more thing; We might want to include a algorithmIdentifier to allow for usage of different types of signing keys.

[SmartLayer]

different type of signing keys.

Yes.

[micwallace]

Hey @jot2re

I've added the new schemas into my simulation and it's working well.

I have a few suggestions:

1. Re. issue Remove legacy use of GeneralizedTime #249 - since this is a brand new schema I suggest we take this opportunity to remove any redundant fields such as the generalized time fields.
2. The legacy NFTAttestation allows attesting ownership of multiple tokens. I don't think there's much of a size penalty for doing this, so maybe we should go with the same to make it more flexible. I suspect this is a feature that will be needed in the near future.
3. Asn schema javascript library had some issues serializing the attestations when the optional context field was at the top. It might be a library (or developer) specific bug but I have moved these optional fields to the end of the schema which fixed the issue.

Thoughts?

[jot2re]

1. Yes, definitely! The code I am writing for this does not even know of the existence of GeneralizedTime ;)
2. Good idea! Let us keep things as general as possible and reuse as much code as possible.
3. Hmm, that is weird. There can be issues when having multiple optional elements of same type following each other. But that is not the case here. Anyway, try to switch its position with the address element and see if it helps.

[SmartLayer]

1. Yes, definitely! The code I am writing for this does not even know of the existence of GeneralizedTime ;)

Tore refers to https://github.com/TokenScript/attestation/tree/270-safeconnect

[SmartLayer]

@jot2re can you comment on the exponent (3 or 65537)? The gas implication is considerable.

[jot2re]

65537 is the safest. If we use a proper padding scheme for signing then 3 should also be ok