The "encrypt phone" feature is based on dmcrypt/LUKS and it is (usually) much more secure as compared to Samsung's algo. I say "usually" because key derivation iterations depend on the hardware the encrypted block device was created on and phone CPUs are slower than most desktop CPUs thus lower iteration count.
That said, I think many people underestimate password security on mobile devices and passwords like 4-digit pins may be common and that is feasible even for bruteforce attacks. Anyway I haven't tried to crack encrypted android volumes yet, so there might be specifics (like you definitely gotta be root in order to dd from the device node). BTW my program has a plugin to crack LUKS volumes on GPU and it's slow (speeds of like 1k-2k c/s are common for volumes created on a desktop system). It also supports only AES-128 and AES-256 block ciphers in CBC-ESSIV mode, while Android may use other scheme. Some time ago someone asked me about cracking encrypted Android volumes and from what I read about Android's FDE implementation, it should already be supported. I asked for a dd dump to test if it works, but still noone sent me one.
That said, I think many people underestimate password security on mobile devices and passwords like 4-digit pins may be common and that is feasible even for bruteforce attacks. Anyway I haven't tried to crack encrypted android volumes yet, so there might be specifics (like you definitely gotta be root in order to dd from the device node). BTW my program has a plugin to crack LUKS volumes on GPU and it's slow (speeds of like 1k-2k c/s are common for volumes created on a desktop system). It also supports only AES-128 and AES-256 block ciphers in CBC-ESSIV mode, while Android may use other scheme. Some time ago someone asked me about cracking encrypted Android volumes and from what I read about Android's FDE implementation, it should already be supported. I asked for a dd dump to test if it works, but still noone sent me one.