It doesn't really answer your question "how", but should give you a bit of insight - and it's too long for a comment.

First of all, you can't boot of an encrypted partition. Simply because a the boot chain does understand encryption only fairly late in the process:

1. hardware loads firmware - typically BIOS of UEFI (on x86 platform). The hardware as such is completely data agnostic - it just loads whatever it finds in some persistent storage (on a predefined address).

2. Firmware loads boot loader or directly the kernel. As with the CPU, it hasn't got any idea about possible encryption modes (not that it couldn't, but it just usually doesn't).

3. If bootloader is involved, it loads the kernel (or a chained bootloader as for example when booting Windows) and more often than not also an initial ramdisk (which can be either in a standalone file or embedded in the kernel image). Here it gets more interesting, since for example GRUB2 should be able to boot from a LUKS device, but the documentation seems to be rather scarce.

4. The kernel mounts the root filesystem and runs init (System V init, systemd, OpenRC, upstart... choices are plentiful).

5. If booting with initial ramdisk, it is first expanded into memory, then mounted and the init system is run from there. The initramfs shuold contain everything needed to mount the proper root file system - typically it contains every available driver (for example RAID drivers that are necessary when the final rootfs is on a RAID device), graphical boot infrastructure - which often means a minimal (or not-so-minimal) X11 stack - and often also tools for mounting encrypted partitions. After all is set up, and the final rootfs mounted the init system run from the initramfs does pivot_root() (see the pivot_root(8) and pivot_root(2) man pages for more details), thus switching the / to the proper file system.

Now, typically the easiest way of booting off an encrypted volume is doing the cryptography setup in step 5 - mostly because it is done by the kernel that is going to run and it can use the infrastructure offered by any decent recent distribution.

Thus you probably want to look into how exactly Fedora and Mint boot from encrypted volume. The solution to your problem might be for example creating an appropriate initramfs image for the Mint kernel. You might even be able to use one initramfs for both kernels, provided you make sure there is a conditional mounting of the right rootfs depending on the kernel booted, although I wouldn't recommend that.

That said you might also want to consider whether you really want to have two installations side-by-side - it might be more convenient to run one virtualised.

It doesn't really answer your question "how", but should give you a bit of insight - and it's too long for a comment.

First of all, you can't boot of an encrypted partition. Simply because a the boot chain does understand encryption only fairly late in the process:

1. hardware loads firmware - typically BIOS of UEFI (on x86 platform). The hardware as such is completely data agnostic - it just loads whatever it finds in some persistent storage (on a predefined address).

2. Firmware loads boot loader or directly the kernel. As with the CPU, it hasn't got any idea about possible encryption modes (not that it couldn't, but it just usually doesn't).

3. If bootloader is involved, it loads the kernel (or a chained bootloader as for example when booting Windows) and more often than not also an initial ramdisk (which can be either in a standalone file or embedded in the kernel image). Here it gets more interesting, since for example GRUB2 should be able to boot from a LUKS device, but the documentation seems to be rather scarce.

4. The kernel mounts the root filesystem and runs init (System V init, systemd, OpenRC, upstart... choices are plentiful).

5. If booting with initial ramdisk, it is first expanded into memory, then mounted and the init system is run from there. The initramfs shuold contain everything needed to mount the proper root file system - typically it contains every available driver (for example RAID drivers that are necessary when the final rootfs is on a RAID device), graphical boot infrastructure - which often means a minimal (or not-so-minimal) X11 stack - and often also tools for mounting encrypted partitions. After all is set up, and the final rootfs mounted the init system run from the initramfs does pivot_root() (see the pivot_root(8) and pivot_root(2) man pages for more details), thus switching the / to the proper file system.

Now, typically the easiest way of booting off an encrypted volume is doing the cryptography setup in step 5 - mostly because it is done by the kernel that is going to run and it can use the infrastructure offered by any decent recent distribution.

Thus you probably want to look into how exactly Fedora and Mint boot from encrypted volume. The solution to your problem might be for example creating an appropriate initramfs image for the Mint kernel. You might even be able to use one initramfs for both kernels, provided you make sure there is a conditional mounting of the right rootfs depending on the kernel booted, although I wouldn't recommend that, especially if you decided to use different (e.g. stock) kernel for each distribution.

That said you might also want to consider whether you really want to have two installations side-by-side - it might be more convenient to run one virtualised.