I am using manjaro with full disk encrypt, however, the wait time at boot for decrypt is very long ( i assume because of a high difficulty setting) . How can I change encryption difficulty/ wait time of the encryption setup during install?

Too much passphrase hashing?

If it's only slow because you're waiting for a lot of passphrase hashing iterations, you could add a new passphrase with a quicker --iter-time, but that could reduce security & allow faster guessing of passphrases. If you wanted to wait 1 second (1000ms) then use a command like:

cryptsetup -v luksAddKey --iter-time 1000 <device>

You might then have to delete the old slow passphrase (with luksKillSlot), unless it's key slot is after the new quick one (they're apparently tested in order, so might have to wait for the first slow slot to be tested before the later quick one). Or change your initial open command to specify the new quicker --key-slot number.

The luksChangeKey command can combine the two steps, adding a new key then deleting the old key (even though the v1.7 man page doesn't specifically say it can use --iter-time, apparently it can):

cryptsetup -v luksAddKey --iter-time 1000 <device>

How slow is it now?

Test how long it takes to decrypt / open your device with:

cryptsetup -v luksOpen --test-passphrase <device>

Or test a specific key slot with the --key-slot option:

cryptsetup -v luksOpen --test-passphrase --key-slot N <device>

Using the time command might help, but also count your typing speed.

You can use the luksDump command to see what the current key slot Iterations: are, this is an example of a very slow slot 0 and a very quick slot 1:

Key Slot 0: ENABLED
 Iterations: 4663017
 Salt: ......
 Key material offset: 8
 AF stripes: 4000
Key Slot 1: ENABLED
 Iterations: 1000
 Salt: ......
 Key material offset: 264
 AF stripes: 4000

From man cryptsetup:

• 
  

  --iter-time, -i

  
  
  

  The number of milliseconds to spend with PBKDF2 passphrase processing. This
  option is only relevant for LUKS operations that set or change passphrases, such
  as luksFormat or luksAddKey. Specifying 0 as parameter selects the compiled-in
  default.

  
  


• 
  

  luksChangeKey <device> [<new key file>]

  
  
  

  Changes an existing passphrase. The passphrase to be changed must be supplied
  interactively or via --key-file. The new passphrase can be supplied interactively
  or in a file given as positional argument.

  
  
  

  If a key-slot is specified (via --key-slot), the passphrase for that key-slot must
  be given and the new passphrase will overwrite the specified key-slot. If no key-
  slot is specified and there is still a free key-slot, then the new passphrase will
  be put into a free key-slot before the key-slot containing the old passphrase is
  purged. If there is no free key-slot, then the key-slot with the old passphrase is
  overwritten directly.

  
  
  

  WARNING: If a key-slot is overwritten, a media failure during this operation can
  cause the overwrite to fail after the old passphrase has been wiped and make the
  LUKS container inaccessible.

  
  

It's not the passphrase hashing?

• There's lots of reasons for a slow boot time, maybe it's unrelated to the encryption.

Or if the actual encryption/decryption itself is too slow, then changing the algorithm or key size might be required, and that would require decrypting and re-encrypting everything. There are programs (or commands in newer versions) that can do it in-place, hopefully without losing anything, but having a backup would be more than an excellent idea.

But in that case, it wouldn't just be a long initial wait but all reads & writes would be a little slower.

You can use the cryptsetup -v benchmark command to see some speed tests, but "NOTE: This benchmark is using memory only and is only informative. You cannot
directly predict real storage encryption speed from it."