Multiple keyscripts in crypttab

[gw0]

Binary package hint: cryptsetup

I would like to suggest a modification that would allow someone to have multiple keyscript entries in crypttab. In addition there should also be an added keystdout filed and also multiple key fields (for each keyscript one). All the keyscripts would then be executed (if written in "pseudo-bash") in such order:
$keyscript1 $key1 >& $keystdout1 | $keyscript2 $key2 >& $keystdout2 | $keyscript3 $key3 >& $keystdout3 | ... | $keyscriptN $keyN
Where each keyscript could read what any of the previous keyscripts has written to his "stdout" file descriptor.

Something like this would allow chaining of different keyscripts, redirecting their output and using it in other scripts. It would then give the user ability to create more complex and easily changable authentication procedures.
Eg. with Debian/Ubuntu scripts: running askpass to get a hashed passphrase, running passdev to get a keyfile from an USB stick, and then running a script that XORs this two values and outputs the final key used for decryption.

ALTERNATIVE:
Similar functionality could also be implemented in a special keyscript, that would accept as parameters all other keyscripts with arguments it should run and combine their output as described above.

But the reason I am proposing the first solution is because of "arguments-hell" in current crypttab file format. Think about a keyscript that wants to get as an argument another keyscript with its arguments (complication variant: ..with its arguments that also contain other keyscripts with arguments). In currect crypttab format all this arguments should be put in the key field and mustn't contain any whitespaces. How should then the first keyscript recognize and split its arguments? Lets assume it uses a comma to separate its own arguments, but what should then the second script use as its input separator (whitespaces and commas don't appear anymore)?

This then leads to the conclusion that the crypttab file format needs to change to solve this! Altough this would break backward-compatibility I would like to suggest the removal of key field that should be replaced with a type+encryption options (without keyscript) followed by <keyscript> [<arguments_for_keyscript>]* (it could also be done without this changes, but then it just becomes ugly). In this additional (or maybe all) fields " and ' qoutes should be parsed as it is usual in *nix world (this is the important change!).
With all this in mind the example described above would look something like:
sdaX_crypt /dev/sdaX swap,cipher=aes-cbc-essiv:sha256,size=256,hash=ripemd160 /path/to/decrypt_xormix "/path/to/askpass" "" "/path/to/passdev" "/dev/sdZ:/keyfile"
Or in the ugly backward-compatible variant where the keyscript needs to deal with parsing individual arguments from the key field:
sdaX_crypt /dev/sdaX "/path/to/askpass","","/path/to/passdev","/dev/sdZ:/keyfile" swap,cipher=aes-cbc-essiv:sha256,size=256,hash=ripemd160,keyscript=/path/to/decrypt_xormix
And a simple luks entry would just become a little shorter:
sdaX_crypt /dev/sdX luks

And the corresponding conf.d/cryptroot would become:
target=sdX_crypt,source=/dev/sdX,cipher=aes-cbc-essiv:sha256,size=256,hash=ripemd160,keyscript=/path/to/decrypt_xormix,keyarg1="/path/to/askpass",keyarg2="",keyarg3="/path/to/passdev",keyarg4="/dev/sdZ:keyfile"
As a consequence the script that parses cryptroot should become "quote-aware" so that the appearing of commas (,) in quoted strings would be skipped.
In the backward-compatible variant it would then probably look like (note the extra escaped quotes):
target=sdX_crypt,source=/dev/sdX,cipher=aes-cbc-essiv:sha256,size=256,hash=ripemd160,keyscript=/path/to/decrypt_xormix,key="\"/path/to/askpass\",\"\",\"/path/to/passdev\",\"/dev/sdZ:/keyfile\""