reading your question several times and the discussion in the comments i did not understand what you're trying to get/obtain, so i will be answering to parts that i think that are relevant according to the problems you posed. maybe other and more experienced people here would help elaborate and improve:
if you're trying to "reverse" an interpreted code, .net in this case, i think the best way to do so is using dnspy, as it gives you pretty much all that you need to understand the logic, patch and change things accordingly and deal with obfuscation and similar operations.
now you said you're struggling with obfuscation, but obfuscation is just a way to mislead the user doing the reversing. meaning you can, sometimes with great effort, to understand what's going on behind the scenes, change variable names and function names accordingly, to make it more "logical" to you. using a decompiler can also help you see the bigger image, but it's mostly about filling the gaps, bit and bit. what i usually do in situations like that, i try to find the calling functions and trying to understand what they do, the logic behind them, what parameters they use and why, and i go with the simplest path, meaning: sometimes if function contains a lot misleading paths, but it's easier to infer the logic from the variables, you can understand what the function does, name the variables correctly, and then go over to understand the function and its implementation to avoid wasting time on dead paths(though you can check coverage to understand what parts of the code are usually used). sometimes it's just the other way around, going with the function, understanding a bit of it's logic, understanding the parameters, and then fixing the parameters and the function, but it's mostly goes down to experience with similar tasks and going with your gut, but understanding it can be wrong(hard part is knowing when to stop before going too deeply in the wrong path).
in regards to encryption or coding, sometimes going dynamically debugging might help you a lot with understand how it translates and checks your input, or the mechanism behind the encryption. but usually it goes down to many basic encryption/coding algorithms or custom implementation of them, that can be spotted with some experience, and then it's easier. if you coded the application and it's not a malware(though you should have snapshots), then there's nothing wrong if you do "bad things", just to understand which functions the program is calling, how it handles information, common program paths, apis, obfuscation and finally dealing with the encryption scheme you're facing. sometimes you don't need to face the encryption if it's not done correctly, you can, at times, just avoid it.
you said you wanted to crack the application, so i don't understand what you mean by that, i thought you meant like a crackme kind of task. if you really want to "crack" applications, you should know that there are lot of other defensive mechanisms such as checksums, different signatures, sometimes server verification and similar, but it all goes down to understand the logic behind what's happening. though i really don't think "cracking" is not a good path to walk at, i think that you should find better ways to use your skills for good, for instance malware analysis or hardening software/binaries by identifying weak implementations and similar.
anyways, since you did not provide a problem but a general issue, my best answer is to go with your guts, fail, and then learn why you failed to try it again and again until you understand how it works. it will help you understand and develop "hunch". then it's easier to understand how to defeat obfuscation and encryption and similar mechanisms.
bottom line is simple, ask yourself simple question, what does it do? is it obfuscated? is it encrypted? why is it encrypted? how does it encrypt? what does it encrypt? how does it check what is correct/wrong? does it matter if i input the correct information or can i bypass it somehow? but the easiest way is just understanding the goal, and going backwards, and thus tackling only what actually interferes with your progress, and not meaningless things that you solved, but could have avoided.
this answer would introduce some tools for debugging C# application
hope i helped a bit and good luck