MacOS Extended (Journaled, Encrypted) uses h/w encryption

Yes - it's the same whole disk encryption. In both instances you end up with a volume wrapper and key storage to unlocks the encrypted file system where the data is safely stored. Disk Utility is a bit of a chore to set up encryption of an external drive, so I usually just wipe the drive and set it for Backups and then tell Time Machine to encrypt the drive. It handles the formatting, generating the crypto keys and lets you choose a passphrase to unlock the keys.

You can use diskutil cs list from the command line (in terminal.app) to show the encryption status and details. There's nothing wrong with disk utility other than the steps involved to reach an equivalent drive setup.

Here is what a fully encrypted and locked USB drive looks like when you set up Time Machine and instruct it to encrypt backups to an external drive:

Air:~ bmike$ diskutil cs list
CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 6FD6879D-EFBF-4F33-9FC2-13E32A0F7B28
    =========================================================
    Name:         Backups
    Status:       Online
    Size:         499730309120 B (499.7 GB)
    Free Space:   0 B (0 B)
    |
    +-< Physical Volume 3082BFED-D84E-48FA-AB4F-7FB0197FD653
    |   ----------------------------------------------------
    |   Index:    0
    |   Disk:     disk1s2
    |   Status:   Online
    |   Size:     499730309120 B (499.7 GB)
    |
    +-> Logical Volume Family DFD4DEB4-93A8-4DD5-8F73-6534AB408E4D
        ----------------------------------------------------------
        Encryption Status:       Locked
        Encryption Type:         AES-XTS
        Conversion Status:       Complete
        Conversion Direction:    -none-
        Has Encrypted Extents:   Yes
        Fully Secure:            Yes
        Passphrase Required:     Yes
        |
        +-> Logical Volume E9497C5B-4AAD-46E5-ACEE-4214D1CA11D8
            ---------------------------------------------------
            Disk:               -none-
            Status:             Locked
            Size (Total):       499411537920 B (499.4 GB)
            Size (Converted):   -none-
            Revertible:         Yes (unlock and decryption required)
            LV Name:            Backups
            Content Hint:       Apple_HFS

Under certain circumstances a deleted external HFS+ encrypted volume can be recovered after the disk has been formatted to a FAT32 volume:

• The whole disk has been encrypted (to one volume).
• The whole disk has been formatted to one FAT32 volume. The GUID partition table has not been replaced by an MBR. The disk still has an MBR (instead of a PMBR) though.

• Some internal invisible CoreStorage data structures mustn't be overwritten.
  • the CoreStorage volume header structure at the (previous) volume block 0 (= disk block 409640)
  • a second block at the (previous) volume block 8 (= disk block 409648)
  • an encrypted metadata block starting at the 577456th last block and ending at the 573360th last block (size 4096 blocks)
  • several Disk Label metadata items in the last 16392 blocks of the (previous) volume

If nothing has been written to the FAT32 volume those parts shouldn't be overwritten.

To recover the encrypted volume you have to use Terminal and do some math.

1. Detach any external drive except the mal-formatted one

2. Open Terminal and enter:

   diskutil list
   

   to get an overview and the disk identifier of the external disk. Below I assume the disk identifier is disk1

3. Make a backup of the whole disk with sudo dd if=/dev/disk1 of=/Volumes/BackupVolume_Name/disk1.bin just in case something goes wrong or for a future with advanced recovery tools.

4. Now get the partition table of the disk with:

   sudo gpt -r show /dev/disk1
   

   You should get a similar result as this one:

         start       size  index  contents
             0          1         MBR
             1          1         Pri GPT header
             2         32         Pri GPT table
            34          6         
            40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
        409640       2008         
        411648  133804032      2  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
     134215680       2015         
     134217695         32         Sec GPT table
     134217727          1         Sec GPT header
   

   The first partition is the EFI volume, the second the FAT32 volume of the external disk. Your partition 2 is much larger than the one in the example though.

   Even if you get a different output with no GUID partition table but only an MBR

         start       size index   contents
             0          1         MBR 
             1          1 
             2  134217726     1   MBR part 11
   

   you can continue: encrypting a disk with FileVault requires a GUID partition table - so your disk previously had one. The probability to recover a FAT volume on a disk with a MBR seems to be much lower though. Apparently parts (namely some metadata and volume headers) may be overwritten by FAT32 file system stuff.

   The same disk containing an encrypted external HFS+ volume should look like this:

         start       size  index  contents
             0          1         PMBR
             1          1         Pri GPT header
             2         32         Pri GPT table
            34          6         
            40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
        409640  133545904      2  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
     133955544     262144      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
     134217688          7         
     134217695         32         Sec GPT table
     134217727          1         Sec GPT header
   

   The first partition is the EFI partition with a fixed size and start block, the third one is an Apple_Boot partition with a fixed size and start block relative to the last block of the disk and the remaining disk space allocated to the encrypted Core Storage Logical Group. All partitions are aligned to the physical block size of the disk (4096 Bytes).

5. To restore the old partition table you have to unmount the disk, delete the actual partition table and do some math to create a new one:

   diskutil umountDisk /dev/disk1
   sudo gpt destroy /dev/disk1
   diskutil umountDisk /dev/disk1
   sudo gpt create -f /dev/disk1
   gpt add -b 40 -i 1 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B disk1
   

6. Now get the last block number of your disk (in my example that's 134217727) and substract 262183: LastBlockNumber-262183 is the start block of the 3rd partition (Apple_Boot). Add this partition with:

   gpt add -b LastBlockNumber-262183 -i 3 -s 262144 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk1
   

7. Check the size of the unallocated disk space between partition 1 and partition 3 with:

   sudo gpt -r show /dev/disk1
   

8. The size of unallocated disk space (UnAlloc) between index 1 and index 3 is probably the size of the old encrypted volume. The size has to be divisible by 8 - please check this! Add this as a partition with:

   gpt add -b 409640 -i 2 -s UnAlloc -t 53746F72-6167-11AA-AA11-00306543ECAC disk1 #with UnAlloc= size of unallocated disk space found above
   

9. After entering the last command you should be asked for password of the encrypted disk. if not then try:

   diskutil cs list
   

   to get a list of CoreStorage items. Try to mount the encrypted volume with:

   diskutil cs unlockVolume LVUUID
   

   with LVUUID: the UUID of the encrypted Logical Volume (usually the last one listed). If your main volume is also encrypted choose the proper LVUUID!

   If the volume mounts successfully save the most important files and folders to an external volume because mounting the encrypted volume doesn' t necessarily mean that the volume isn't corrupted.

   Unmount the volume and run diskutil verifyDisk /dev/disk1 and diskutil repairDisk /dev/disk1. The last command may completely corrupt the disk!

This might still fail. The encrypted volume may still be recoverable though. But then I need more information, because special (invisible) non-file system items have to been read directly from disk with a HexEditor and then restored/replaced.