stabilize API for different obfuscation modes

[orph3usLyre]

context

• this library currently provides 2 primary "modes" for obfuscation functionality:
• 1) the "embedded" mode, which places the deobfuscation key inside the user's binary
  • less secure since the key is part of the binary
  • does not require any user interaction for the user binary to work
• 2) the "env" mode, which requires the user to provide the deobfuscation key at runtime
  • slightly more secure since the key needs to be discovered first/brute forced
  • requires user interaction at runtime for the binary to run

todo:

1) I would like to stabilize the API of the different library "modes" since I'm not currently happy with the muddy_init("embed") / muddy_init!("env") solution. Additionally, setting a user's custom env variable identifier is not extremely clear. 2) I would also like to begin thinking about if this library should offer different types of encryption. Currently, we use the ChaCha20-Poly1305 cipher implementation. Should this library offer other encryption methods for its strings or simply an opinionated decision of the cipher that should be used? Is it even useful to have other types of encryption?

[xuxiaocheng0201]

I would also like to begin thinking about if this library should offer different types of encryption. Currently, we use the ChaCha20-Poly1305 cipher implementation.

In my personal implementation, I use base64 with random alphabet character sets. It's more simple and fast.