ccrypt appears to use AES in CFB (Cipher Feedback) mode. While this provides privacy, it doesn't provide integrity, so somebody could tamper with the data and as a result, you could end up decrypting something that you didn't expect. While this is detectable with plaintext, it may not be with something like a PDF where the modified data can be hidden away.
Because of patent concerns support for MDC-2 has been disabled in OpenSSL on most Linux distributions and is not implemented by many other cryptographic libraries.
The algorithm itself is available in OpenSSL, but it is not compiled in. If you really want to use it, download the source package, modify the debian/rules file so that this ...
I don't get why you would want to echo to a file with the > operator, since this completely overwrites it, but if you want to set a file to read-only, you should take away the write permissions.
In this case it's
chmod -w file.gpg.
If you want to change the encrypted file, you should append to/change the original file and then reencrypt it.
Another possible solution would be to debug some code down to the syscall level to find where it interfaces with the kernel, since it seems as though the kernel reads from a buffer to perform crypto system calls.
I have tested stenc as suggested by sendmoreinfo and it worked well with the LTO-6 drive.
Insert a tape and ask the tape drive about its settings:
# stenc -f /dev/nst0 --detail
Generate your 256 bit key and store it:
# stenc -g 256 -k /root/myaes.key -kd Bobs_month_key
Load the key in the LTO tape drive. With --ckod it will forget the key after ...
As far as I know there are two simple ways to add entries to the Nautilus context menu :
nautilus-actions package, which, depending on your distribution might be depreciated.
I'm running on Debian Bullseye/sid where nautilus-actions is not available so I will present the way using Nautilus script. To learn more about this Nautilus ...
Yes, the clones will be encrypted. And yes, there is a hidden downside besides all of them sharing the login passphrase (the one you usually type when you log in, and which you can change): they'll also share the mount passphrase (i.e., the encryption master key, which you don't normally see or interact with yourself, and that you can't change without re-...
There are lots of options. Pretty much they all require you to maintain the root password as a secret (and don't allow users to su or sudo to get root privileges).
Here are two suggestions for a starting point
Use ordinary UNIX/Linux permissions so that others can't access your home directory
Lock your other users into a chroot jail
If your goal is to ...