A little overengineered about puree

[notfed]

Thank you for your feedback.

If you support slots, is there a reason to not use them?

The truth is, I agree with you: your design is cleaner. The rationale for this, which admittedly was left undocumented, was to allow maximum header compression while still retaining the extensibility benefits of the format. My goal was to make the header small enough so that PUREE could double as a file format: the way it's specified currently allows the header to reduce to a mere 64-bytes of overhead.

In hindsight, I've committed a blatant violation of YAGNI: I attempted to make the format cover more scenarios, without an obvious need to do so. Was it justified here? Do people need to vary their file encryption algorithms as much as they do disk encryption algorithms? No, probably not: (1) it's harder to justify the need for alternative ciphers for files, and (2) there could easily be different specs for disks and files. But PUREE has dared to combine them into one, at the cost of a slight format complication, take it or leave it.

If you want to provide 3 bits of public information, you can encode them in random data.

I think you make a valid point, and really appreciate that you read the paper and put thought into it. What you're suggesting is essentially a time tradeoff: decrypting the header will be faster, but encrypting it will be slower. And since generally encryption will only happen once, this is a reasonable tradeoff to make.

However, consider that, with PUREE's current approach, the time spent deriving the meta-parameters is negligible compared to the time required to derive the password hash---i.e., no observable drop in speed or security. Yet, with your suggestion, the time taken to encrypt the header would take ~8x longer for the same security level.