rcloud.encrypt and rcloud.decrypt are great, but require explicit supply of the key.
It would be nice if rcloud.decrypt could handle decryption of the types that are supported by RCloud such as user-key encryption and group-hash encryption. It already has all it needs and we do already all the work in .gist.binary.process.incoming so it could simply shift to rcloud.decrypt since it requires no user arguments.
rcloud.encrypt could be enhanced for symmetry to allow specification of the group or an argument to use the user key (the latter is trivial, but currently wouldn't flag the result with the key type metadata).
(As a convenience wrapper it it would be nice to have corresponding readRDS and saveRDS versions for storing intermediate results in encrypted form)
rcloud.encryptandrcloud.decryptare great, but require explicit supply of the key.It would be nice if
rcloud.decryptcould handle decryption of the types that are supported by RCloud such as user-key encryption and group-hash encryption. It already has all it needs and we do already all the work in.gist.binary.process.incomingso it could simply shift torcloud.decryptsince it requires no user arguments.rcloud.encryptcould be enhanced for symmetry to allow specification of the group or an argument to use the user key (the latter is trivial, but currently wouldn't flag the result with the key type metadata).(As a convenience wrapper it it would be nice to have corresponding
readRDSandsaveRDSversions for storing intermediate results in encrypted form)