Just sharing a bit of info on my project. (my first with FreeBasic)
I'm developing a proprietary symmetric-key stream-cipher encryption algorithm, wrapped in a win32 command line utility package. It serves as a mechanism to encrypt / decrypt files for storage or transmission.
One unique aspect of the project is use of a pre-shared pool of 8 bit integers as underlying mechanism for random number generation. By using this 'Entropy Pool' as bit source for RNG, and by establishing it as a pre-shared secret between communicating parties, the normal brute force key guessing attacks are rendered ineffective.
I think the algorithm could end up being extremely secure, providing that source and destination systems are not compromised.
I'm having a blast with FreeBASIC! I've been a PDS 7.1 user since the early 90s, and BASIC itself since the 70s. I am most thoroughly impressed with functionality and performance. It's like someone wrote my dream language. *** APPLAUSE ***
My Stream-Cipher Encryption Algorithm Project
Re: My Stream-Cipher Encryption Algorithm Project
Hello KenFisher, welcome at the forum.
Your project sounds interesting. What exactly is the difference between your mechanism and PGP?
Your project sounds interesting. What exactly is the difference between your mechanism and PGP?
Re: My Stream-Cipher Encryption Algorithm Project
What I'm doing is much more low-tech than modern cryptography. Mine is an adaptation of the old encryption technique used by spies prior to world-war 2, where they used a pre-printed tablet with codes and converted cipher to plain text on paper. Supposedly it's quit difficult to break.
It's a fun learning project. I've wanted to try my hand at this for a while now.
It's a fun learning project. I've wanted to try my hand at this for a while now.
Re: My Stream-Cipher Encryption Algorithm Project
Would that be Playfair?
http://en.wikipedia.org/wiki/Playfair_cipher
The cipher was apparently quite good for the time, but
"modern computers could easily break the cipher within seconds"
I wouldn't make anything like this proprietary. Seriously. (If it protects something important ... there's a good chance it will be reverse engineered.)
Even a crypto guru such as Bruce Schneier had his latest cipher/hash (at the time) broken during the conference at which he announced it.
http://en.wikipedia.org/wiki/Playfair_cipher
The cipher was apparently quite good for the time, but
"modern computers could easily break the cipher within seconds"
I believe that, generally, you would want a block cipher for file storage and a stream cipher for data transmission, with frequently changed keys. If you collect enough encrypted data from a stream cipher, you can start on cracking the key (one byte encrypted at a time, unlike block ciphers).symmetric-key stream-cipher
I wouldn't make anything like this proprietary. Seriously. (If it protects something important ... there's a good chance it will be reverse engineered.)
The only way you can make it truly secure / dependable is with expert peer review (see Microsoft LM, Zip Crypto and others for those who didn't bother). The strongest ciphers are those which have been comprehensively analyzed by the security community e.g. AES, Serpent, and have been unbroken for over 10 years.I think the algorithm could end up being extremely secure...
Even a crypto guru such as Bruce Schneier had his latest cipher/hash (at the time) broken during the conference at which he announced it.
Re: My Stream-Cipher Encryption Algorithm Project
I have a bunch to learn on how the Cryptography Community operates regarding peer review.
I strongly agree that review (public or private) is essential. I'm just not sure how to make it happen.
I don't want to establish i58 as an open standard. I'm writing the algorithm for my own use, with intent on producing a small reliable specialty encryption application for home and small business use. Others using the algorithm is not appealing.
So I think I'm in a catch-22. I would greatly prefer to stay proprietary, but my guess at this point is that I may be forced to publish as a standard.
You're welcome to take a look at the description and documentation if curious.
http://www.i58.com
I strongly agree that review (public or private) is essential. I'm just not sure how to make it happen.
I don't want to establish i58 as an open standard. I'm writing the algorithm for my own use, with intent on producing a small reliable specialty encryption application for home and small business use. Others using the algorithm is not appealing.
So I think I'm in a catch-22. I would greatly prefer to stay proprietary, but my guess at this point is that I may be forced to publish as a standard.
You're welcome to take a look at the description and documentation if curious.
http://www.i58.com
Re: My Stream-Cipher Encryption Algorithm Project
Your site documentation is clear and neat.
The Standard Version's key size of 64-bits would bother me (re: DES cipher).
But looking at a contemporary stream cipher, Achterbahn, its lower version is only 80-bit (http://en.wikipedia.org/wiki/Achterbahn).
The Standard Version's key size of 64-bits would bother me (re: DES cipher).
But looking at a contemporary stream cipher, Achterbahn, its lower version is only 80-bit (http://en.wikipedia.org/wiki/Achterbahn).
Re: My Stream-Cipher Encryption Algorithm Project
I'm dancing around US Export restrictions. At 64 bits, it's considered weak enough that I don't even have to register it with the government.
On the other side, my dirty little secret is that even at 64 bits, this (assuming it's not flawed) is going to be quite difficult to guess 'brute force' keys.
Each key guess requires the randomization functions to fully initialize (they're key specific, so there's no pre-loading a cheat) before the key can be tested.
Why a big deal? It's intentionally computationally intensive. On medium hardware takes 4 minutes.
This means no brute forcing 100,000 keys a minute. Even on ripping fast hardware it's more like 240 per hour.
2^64 possibilities, running 24-7 at 240 guesses per hour works out to: 8,774,136,260,326 years. That's 8 trillion years, or 1 year on 8 trillion computers. Feel free to check my math. Even a one in a million lucky guess and it's still 87,741,362 (87 million years).
*grin*
Of course this is all completely unproven. I just write it. I'm hoping the crypto-nerds will review it. I'm curious to see.
Oh, and thanks for the info on Achterbahn! That's not one I've heard of.
On the other side, my dirty little secret is that even at 64 bits, this (assuming it's not flawed) is going to be quite difficult to guess 'brute force' keys.
Each key guess requires the randomization functions to fully initialize (they're key specific, so there's no pre-loading a cheat) before the key can be tested.
Why a big deal? It's intentionally computationally intensive. On medium hardware takes 4 minutes.
This means no brute forcing 100,000 keys a minute. Even on ripping fast hardware it's more like 240 per hour.
2^64 possibilities, running 24-7 at 240 guesses per hour works out to: 8,774,136,260,326 years. That's 8 trillion years, or 1 year on 8 trillion computers. Feel free to check my math. Even a one in a million lucky guess and it's still 87,741,362 (87 million years).
*grin*
Of course this is all completely unproven. I just write it. I'm hoping the crypto-nerds will review it. I'm curious to see.
Oh, and thanks for the info on Achterbahn! That's not one I've heard of.
Re: My Stream-Cipher Encryption Algorithm Project
Sometimes you know so little about a subject you don't even know what you don't know. I've been in that situation a few times. It tends to end up a bit embarrassing.