Signature scheme is broken

The [signature scheme](https://github.com/covert-encryption/covert/blob/a69437b24c391fe14e355501828c6e41ddb19b32/docs/Specification.md#signatures) (which is based on signing the Poly1305 tags) is broken: When a file has multiple recipients, one recipient can carefully edit the blocks in a way that leaves the Poly1305 tags unchanged. Other recipients will not be able to detect the modification.

This is because Poly1305 is not a cryptographic hash function. Knowledge of the key allows an attacker to construct almost-arbitrary plaintexts that have a desired Poly1305 tag.

I don't have a proof-of-concept, but I think this is apparent from the [definition of Poly1305](https://en.wikipedia.org/wiki/Poly1305#Definition_of_Poly1305). I can probably construct an example if requested.

**Suggestion:** Compute a cryptographic hash of the plaintext data, then sign that hash (and encrypt the signature). Some suggestions for hash functions:

- SHA-512 (which is also used internally by Ed25519)
- BLAKE2 (which may be faster than SHA-512).

It will probably be a little slower than Poly1305, but that can't be helped.

---

Also, the scheme used to encrypt the signature is very suspect. It uses `filehash[:32]` as the encryption key and `hash(filehash + recipient_public_key)[:12]` as the nonce. But `filehash` is public (it is a SHA-512 hash of the Poly1305 tags, which are appended to the ciphertext and are therefore public). So if an attacker knows the recipient's public key, the attacker can decrypt the signature block. And if the attacker doesn't know who the recipient is, they can use the signature block to test known public keys and determine if they are the recipient.

**Suggestion:** Encrypt the signature using a secret key.

---

Finally, a minor comment (which may soon be irrelevant): The scheme for calculating `filehash` repeatedly calls `sha512`, but there is no apparent reason for doing so. It would be faster to just compute the SHA-512 of the concatenation of all the values to be hashed.

Start with the Signatures section of docs/Specification.md and trace the implementation of the Poly1305-based filehash and signature encryption; the payload names no source file or test. Validate the reported recipient-modification and signature-disclosure risks, then define completion as an agreed replacement scheme reflected consistently in the specification and implementation.

Written by the indexing model from the issue text.