How to sign a large file for random-access reading? I need to write an "Authoring" application which produces large files. These files must be signed so that the "Consuming" application knows that it was authored with a matching key.
The consuming application must access the signed files read-only, with random access. This means it will not read the full file but still must check that the read bytes are signed.

I have thought cutting the data into 64k blocks and sign these blocks individually using a RSA private key with Crypto++.


Is there a RSA scheme which produces fixed size signatures?
The last block can be as small as 1 byte. Is there any cryptographical risk doing this?
Is this globally a good idea?
Is there a RSA scheme which produces fixed size signatures?
  


Normally RSA signatures are fixed size. Depending on encoding and the details included, the length may vary by at least a few bytes, though. There is usually a known maximum at least.


  
  The last block can be as small as 1 byte. Is there any cryptographical risk doing this?
  


No. As long as a good signature scheme (including a secure hash and proper padding in the case of RSA) is used the length of the data signed does not matter.


  
  Is this globally a good idea?
  


Firstly, signing each block individually does not allow verifying that their order is correct – an attacker could reorder the blocks and the corresponding signatures. You would need to add at least an index of the block to the signed data to verify that. (You likely also need to sign the file identity and length to prevent moving blocks between files or leaving data off the end.)

It also seems somewhat inefficient — RSA signatures are quite long and computing them is relatively time-consuming. But you know best whether the performance is sufficient or the space usage a problem in your use case.

Signing a hash list or hash tree of the data would allow storing a shorter signature and verifying blocks faster — you only need to verify a signature of the hashes once, then it suffices to check that each block hashes to the correct value. It would also take care of verifying the ordering. However, it would require reading and verifying a length-dependent list/tree of hashes before reading the actual data, which may be a problem.