90 bytes is not too long. But the longer the packet, the greater chance the data is corrupted (interference, other factors causing bits to be flipped).
You will have to consult the
datasheet for exact mechanisms of encryption, CRC and packet handling if you want to customize the library to your needs.
CRC is done by the packet handler regardless of whether you have encryption enabled.
See
this blog for the latest packet structure of the RFM69 library. It shows which parts of the payload get encrypted and which are CRC checked.
Encryption just scrambles the data so an attacker would not be able to read it.
CRC ensures that the received payload bytes add up to a certain 2 byte checksum. It is possible (in fact it happens often!) that this checksum passes with received noise (frequency depends on how often noise actually triggers reception - this is based on radio settings). When that happens, the packet handler simply decrypts the gibberish payload - to unencrypted gibberish.
Ultimately it is up to the application layer (your code/implementation) to decide if a packet is valid or not.