For security reason, it should not be possible to sign a transaction in a group individually

General
1

Hello,
If we have a group transaction with N transactions, it is currently possible to send each of the N transactions alone to its respective signer to sign it.
This is really not secure because when signing the signer does not have full knowledge of the other transactions in the group (rather full knowledge is not enforced by the protocol) and thus he is never sure of which transactions will be really part of the group.
Let’s take an example :
Alice and Bob want to make an atomic transfer with those 2 transactions :
Tx1 : Alice sends X to Bob
Tx2 : Bob sends Y to Alice

Let’s say Bob is malicious and responsible for creating the transactions, he could create those 2 transactions instead :
Tx1 : Alice sends X to Bob
Tx2 : Bob sends Z to Alice (Bob changed Y to Z)
and we would compute and set the group id for both Tx1 and Tx2, sign his modified transaction Tx2 and send Tx1 to Alice for her to sign it.

When Alice receive Tx1 it is totally possible for her to sign it despite not seeing that Tx2 is no more the transaction they agreed on. This is because it is possible to sign Tx1 without seeing Tx2.

It would be fare more secure if the protocol would enforce to have all transactions in the group to be able to sign anything.

For example a solution could be to force all parties to sequentially sign the concatenation of all the transactions in the group instead of just an isolated transaction. That way we are sure each signer had all the transactions of the group available to him when he signed and so that everybody agreed on the same sequence of transactions.

The suggested protocol would be like so :

  1. Bob signs Tx1|Tx2 -> Sb(Tx1|Tx2)
  2. Bob sends the tuple ( Tx1, Tx2, Sb(Tx1|Tx2) ) to Alice
  3. Alice checks that Sb(Tx1|Tx2) is indeed Bob’s signature of Tx1|Tx2
  4. Alice signs Sb(Tx1|Tx2) -> Sa(Sb(Tx1|Tx2))
  5. The tuple ( Tx1, Tx2, Sa(Sb(Tx1|Tx2)) ) can be sent to the network

Of course this protocol generalizes to N transactions in group and to N signers.

2

That’s not true. A transaction in a group contains a group hash that is being signed upon.
It’s true that having this hash doesn’t let the signer know what the other transactions are, but the signer can avoid signing the transaction if it’s unable to verify the group hash against the reminder of the transactions in the group.

2 Likes
3

Thanks for your reply @tsachi. I know about the group id which is the hash of all transactions of the group.
My point is that the current way of doing it does not enforce seeing all transactions at signing time.
Practically speaking, the signing software won’t be able to show all the transactions to Alice so that she can decide to sign or not.

I mean currently it is possible for a malicious Bob to trap Alice which is relying only on the signing software, and make her sign only her transaction.

If all transactions must be shown and signed together it would secure the usage of group transaction even for the average user which is relying only on what the signing software show to them.

In short, having all the transactions before signing should be enforced somewhere, either in the protocol or at least in the signing software (on which the majority of users will rely).

I don’t know if current signing softwares (like MyAlgoWallet) already force to give all transactions as input to be able to check the group hash.

4

Yes, I agree that the signing software should give the end user to view all the transactions.
In fact, it should highlight any request for signing of a transaction that contains the grouphash without showing and verifying the entire group. ( i.e. conducting the test to ensure that the hash of the entire group is equal to the group hash specified in the unsigned transaction ).

I think that the protocol level approach taken in this case is perfectly legit : it gives the flexibility for the application developer to construct the application in the best way possible.

5

ARC-1 which is the standard for signing function for wallets for dApps indeed require this:

Some wallets may still allow to sign individual transaction because of the existence of apps using deprecated API but hopefully this will soon disappear.

1 Like
6

Yes thanks for the detail. I just tested and I confim that MyAlgoWallet (with latest version) allows to sign transactions of same group individually. I hope they will fix this in the future.