bool values are not encrypted adequately

I realise there's not many people out there using bools as secrets, but...

input:

example_booleans:
    - true
    - false
    - true
    - false
    - true

output:

example_booleans:
    - ENC[AES256_GCM,data:g/Obfg==, ... ,type:bool]
    - ENC[AES256_GCM,data:NMMyM14=, ... ,type:bool]
    - ENC[AES256_GCM,data:g/Obfg==, ... ,type:bool]
    - ENC[AES256_GCM,data:NMMyM14=, ... ,type:bool]
    - ENC[AES256_GCM,data:g/Obfg==, ... ,type:bool]

It's obvious by the amount of = padding in the data field which values are true and which are false.

Applying padding to the end of what's being encrypted (maybe just a null then repetition of input data so it's deterministic) up to e.g. the next 16 byte boundary would help conceal the exact length of the data being encrypted (which is a dead giveaway for bools, and also not ideal for other types).

Actually I might be over-complicating that, null padding is likely good enough.

Also, I notice from above that repeated occurrences of the same value in the same array seems to result in the same encrypted data. This issue also afflicts strings, e.g.

input:

some_identical_secrets:
    - ghewkjgewhjgew
    - blbooefef
    - ghewkjgewhjgew

output:

some_identical_secrets:
    - ENC[AES256_GCM,data:fDHnMO6reuPTRWT4lZE=, ... ,type:str]
    - ENC[AES256_GCM,data:6ePlJfxUkPEN, ... type:str]
    - ENC[AES256_GCM,data:fDHnMO6reuPTRWT4lZE=, ... ,type:str]```

so I wonder whether the position in the array could also be used as input to the encryption to avoid this.

The issue names no files or tests. Start by reproducing the boolean and repeated-string examples, then trace the encryption path for YAML scalar values and array elements. Define the required protection against length and repetition leakage, and add regression tests showing that the agreed behavior is met.