Something like this could work, except that not everyone uses RSA and passing arbitrary strings (e.g. hash of Verification-String) into decryption function looks dangerous. We normally don’t have access to such low-level operations as decrypting a string without integrity checks and if someone does this it’s better that this is properly documented and some cryptographers look at the construction.
One obvious mistake is that Verification-String is constructed insecurely, i.e. Admin-ID=alice@example.com with Admin-Authentication-String=puterfoobar gives the same Verification-String as Admin-ID=alice@example.computer and Admin-Authentication-String=foobar.
See “YOLO” is not a valid hash construction | Trail of Bits Blog
This also does not protect against replay attacks in any form. If we now assume that malicious members are part of the group, some of them may be able to replay administrator messages if the servers do not protect against it.
I agree that it should definitely be reviewed by some experts.
I see the point that there need to be some restrictions regarding generation of the Verification-String . But that is possible, isn’t it?
But I don’t see why it does not protect against replay attacks? If malicious members fake the Admin-Authentication-String, they also need to change the Group-ID, otherwise the verification process does not work. And if the Group-ID changes, the client knows that something gone wrong.
But there may be complex attacks where the right Group-ID has never been send to some group members, hm.
If admin removes someone from the group, attacker can record this message. Then when admin adds this member back to the group, attacker can replay the “member removed” message as is to remove the member again.
For this attack, the member needs to be able to fake the sender address (DKIM) or have access to the smtp server of the group admin. In general, there are technics to prevent this attack. I agree that my approach is not a complete and secure protocol. I just want to show that it is possible to find a protocol to solve the group administrator problem. It may work similiar to what I wrote or perhaps completely different The question is, if this is something delta chat wants to do or if groups should stay as they are.
I would really like to have some simpler solution to deal with user mistakes. E.g. if someone joins the group and removes half of the members, it would be nice to switch to “time machine” mode, scroll to the date before the user joined and click “restore this state”, then maybe add some users who joined later manually.
Adding admins seems like an easy solution, but it feels like adding confirmation dialogs instead of adding undo or adding yet another option (group type) instead of choosing better defaults. Users then need to know in advance when they need admins before someone destroys their group, and it is not possible to know before this happens.
The question is, if this is something delta chat wants to do or if groups should stay as they are.