“Making frequency analysis ineffective”
Oh boy, let’s hope nobody uses it for large plain texts. If x maps to k1,K2,… then one simply needs enough instances of x to reconstruct the key. It must at the very minimum need multiple symbols to map to the same strings to achieve ambiguity.
The cryptographic claims seem laughable.
It must at the very minimum need multiple symbols to map to the same strings to achieve ambiguity.
It does this.
The only conventional cryptography is the shuffle function which takes entropy from the OS.
What motivated you to write this program?
Your choice of “codebook”, is an immediate red flag and reeks of pop-crypto. There is a reason why this approach was abandoned some 100+ years ago, even properly implemented they have severe shortcomings.
What motivated you to write this program?
Just for fun basically.
I’ve had the idea for awhile but the problem is was always a huge amount of grunt work to get the initial database created. With the use of LLM I basically mined all the unique entries, common phrases.
I’m not claiming it’s the best or anything at all. But for codebook standards…I tried to implement all the things that would make a good code book.
- Ability to say the same thing over and over and make it look different for mitigation against frequency analysis.
- Easy, secure, shuffling
- customizable
- Assisted composing
- Exportable
- Long term rotating key schema
- Conclusive and established database
- Portable
Why did you use an LLM for the frequency tables? The “most common words used” is very useful data and as such there are many already existing compilations, used by things like spell checkers. The Linux system dictionaries are one example.
The fact that you completely ignore that simply using a larger RSA key would both be faster and more secure than your approach, doesn’t inspire confidence either.
(It’s also in python which is basically unusable. )