Yes, this is possible. It will require backing up all the data on the drive, re-partitioning and reformatting it, and then restoring the data.
Doing this is a good idea anyway even without encryption because NTFS is not a native linux filesystem and support for it is not great - "barely adequate, mostly works" would be a reasonable summary. If you don't need to directly use the drive with Windows & Linux systems (e.g. Dual Booting, or an external USB drive that is swapped between systems), then don't use NTFS on Linux. i.e. if you're sharing the drive over the network with the Linux machine acting as the file server (e.g. with Samba or NFS) then use a native Linux filesystem.
As for "where to start", the two obvious choices are block-level encryption (e.g. LUKS) which encrypts entire disks or partitions, or filesystem-level encryption (e.g. ZFS - quick-start guide to ZFS encryption) which encrypts as much or as little of the filesystem as you want.
With LUKS, you will need to partition the drive, optionally use LVM as well to create and manage volume groups (VGs) and logical volumes (LVs), configure LUKS for the partition(s) or LVs you want to encrypt, and then format those encrypted partitions with a filesystem, e.g. ext4. You will need to decide in advance how much space you want to allocate to each partition (e.g. encrypted and un-encrypted partitions).
With ZFS, you create a pool using one or more partitions or drives, then create datasets as you need them - a dataset is kind of like a separate mounted filesystem that uses the space available in the pool. By default it can use any amount of the pool so you don't need to decide in advance how much to allocate to each purpose, but quotas and reservations can be set to limit that (and can be changed at any time without repartitioning or reformatting).
The advantage of datasets over directories is that they can each have their own properties, like compression, encryption, record size, etc (e.g. you might want to disable compression on pre-compressed data like video or audio files, or use a recordsize tuned for a database like mysql or postgresql. See man zfsprops for details, including details about encryption properties...BTW, you will see mention of a dedup property. Sounds amazingly useful, but ignore it. It requires far too much RAM to be worth it in any but very specialised use-cases).
The disadvantage is that, like any other separately mounted filesystem, mv-ing a file to another dataset or fs is not a quick rename, it's a a copy-and-delete operation.
Other than that, a dataset works like any other directory. And any individual dataset can be optionally encrypted.
Note that if you use only a single drive or partition with ZFS, it will still be able to detect errors but won't be able to correct them automatically. All other features of ZFS (including transparent compression, snapshots, etc) will still be available. ZFS is easier to set up and administer than LUKS and provides many more features.
Actually, you can get redundancy with the copies=1|2|3 dataset property but at cost of a lot of your storage space (so best to use it only sparingly for small amounts of very important data) and while copies= can correct errors due to bit-rot or read errors, i.e. random file corruption, it won't help if the drive dies. Also worth noting: if you use encryption on a dataset, you can only use copies=1 (the default) or copies=2. And, as always, RAID and raid-like filesystems such as ZFS are not a substitute for regular backups.
One of the reasons I mention both ZFS and ext4 here is that both of them support case-insensitive filenames for some or all of the filesystem, which is useful if you need to share files with both Linux and Windows.
For ext4, you can enable "case folding" on a directory with chattr +F directory/.
For ZFS, you can enable case-insensitivity on a dataset with zfs set casesensitivity=insensitive pool/dataset (I use this on the datasets I created for my Steam + Proton games because windows game devs aren't always consistent with upper and lower case in filenames because it doesn't matter in Windows).
BTW, if you configure either LUKS or ZFS to load the encryption key(s) from, say, a USB flash drive then that is likely to be stolen along with the system if you leave it plugged in for convenience. So, get into the habit of only bringing out the key when you reboot, and store it somewhere safe at all other times. Preferably keep several copies of the keys in different secure locations (e.g. with trusted friends or family. or stored securely by your bank or lawyer), because if you lose that key, you lose all the encrypted data.
Or just use an easily-remembered passphrase that you type in at boot. Store a written copy in a safe or something in case you forget it.
