The problem that will have to be investigated is just how robust such a large HTTP header is in practice. For it to be a relatively “simple” fit, I’d like to continue using basic authentication, and this entails sending the password in a HTTP header.
Last time I checked I recall sure the default for IIS being 16k (maximum of 64k) – I’m referring to the sum total, i.e. everything.
At an average of 4k-5k for a miniature AxCrypt file I think that the default IIS configuration would leave you with enough to play with. Setting the parameter to high risks encoding and traversal attacks and would be unecessary.
I foresee no reason why it wouldn’t be robust enough as it’s not a huge amount of data and it’s transmitted over TLS. If anything it could be a metric of detection – if somebody is having problems connecting it could potentially indicate compromise of the channel.
I’ve received your email response, thanks. I’ll try to respond to you sometime tomorrow.
The digital signing of the licence file is what I had in mind, very easily integrated and sufficiently robust to dissuade casual individuals.
A basic ASCII text file and maybe a QR code would help those with air-gapped systems. Some have more curtailments (data diodes, sluices etc.) and even no external media device (USB, CD, SD, floppy) but allow input into a sanitised, sandboxed environment which is where the QR code would come handy. Failing that it would have to be inputted by hand.
I’m not suggesting you build a QR scanner into AxCrypt as some air-gapped systems in high security environments have their own data input units (barcode, QR etc.)
