| |
 |
|
|
Science Forum Index » Cryptography Forum » Idea for algo.
Page 1 of 3 Goto page 1, 2, 3 Next
|
| Author |
Message |
| Peter |
 Posted: Tue Dec 30, 2003 9:51 pm |
|
|
|
Guest
|
Most algos that I've seen involve the use of XORing, addition,
subtraction, rotation & bitshifting in any combination and to various
levelsof complexity. Some just seem to be substitution ciphers.
Following is a proposal that definately does not fall into the first
category, but perhaps into the second one(?).
------------------------------------------------------------------
Create 2 - 256 Byte arrays: a_key() & rb() (reference box)
In the a_key() scramble the numbers from 0 to 255 according to the
password (similar to an RC4 mix)
Create the ref box (rb()) such that it contains the information as to
which Bytes are stored where in the a_key().
eg. a_key()= 5,1,8,0,4,7,9,2,6,3,...
position 0 1 2 3 4 5 6 7 8 9,...
rb()= 3,1,7,9,4,0,8,5,2,6,...
in other words... rb(0) tells us that the '0' is in a_key(3)
so if the plain text is 834, the cipher text would be 294.
The cipher text stores only the references to the locations. No XORing,
adding, subtracting, rotating or shifting is involved.
After each operation the a_key() and rb() are mixed, so that the same
plaint text is not referenced by the same location twice in a row.
Repeating cipher pairs should approach 256^2 for any pair and 256^3 for
any triplets etc.
-------------------------------------------------------------------------
Any serious thoughts? Has something like this been done before?
Peter |
|
|
| Back to top |
|
| Tom St Denis |
| Posted: Tue Dec 30, 2003 9:57 pm |
|
|
|
Guest
|
"Peter" <peter_rabbit@shaw.ca> wrote in message
news:MQqIb.872695$pl3.250677@pd7tw3no...
Quote: Any serious thoughts? Has something like this been done before?
No and here's why. You have to shuffle after every byte you process. And
how do you shuffle? You need some random bits [or pseudo]. So you might as
well make better use of your PRNG.
I'd say study some cryptanalysis... don't make your own designs...
Tom |
|
|
| Back to top |
|
| Douglas A. Gwyn |
| Posted: Tue Dec 30, 2003 10:48 pm |
|
|
|
Guest
|
Peter wrote:
Quote: Most algos that I've seen involve the use of XORing, addition,
subtraction, rotation & bitshifting in any combination and to various
levelsof complexity.
Really? All the ones I've seen just use NAND (apart
from a few that also need a true random bit source).
 |
|
|
| Back to top |
|
| John Savard |
| Posted: Tue Dec 30, 2003 11:38 pm |
|
|
|
Guest
|
On Wed, 31 Dec 2003 02:57:05 GMT, "Tom St Denis" <tomstdenis@iahu.ca>
wrote, in part:
Quote: No and here's why. You have to shuffle after every byte you process. And
how do you shuffle? You need some random bits [or pseudo]. So you might as
well make better use of your PRNG.
But if you have a fast PRNG which isn't too secure, using it to do
shuffles might hide some of the details of the PRNG's output.
However, if you do want to use the full output of the PRNG
efficiently, but you want to use shuffling, there's Terry Ritter's
Dynamic Substitution.
John Savard
http://home.ecn.ab.ca/~jsavard/index.html |
|
|
| Back to top |
|
| John Savard |
| Posted: Tue Dec 30, 2003 11:43 pm |
|
|
|
Guest
|
On Tue, 30 Dec 2003 22:48:02 -0500, "Douglas A. Gwyn"
<DAGwyn@null.net> wrote, in part:
Quote: Peter wrote:
Most algos that I've seen involve the use of XORing, addition,
subtraction, rotation & bitshifting in any combination and to various
levelsof complexity.
Really? All the ones I've seen just use NAND (apart
from a few that also need a true random bit source).
Note the smiley. ALL logical operations can be built up from NAND
gates.
Even so, of course, using lots of NANDs in an inefficient way might
well introduce desirable properties, like nonlinearity, that using
fewer NANDs more directly does not.
This is why DES has S-boxes, for example.
A block cipher where part of a round involves using the f-function of
one-half of a block to generate an S-box to apply to the nibbles of
the other half would be nonlinear in a profound way that is missing
from typical block cipher architectures. This would not be a bad
thing, and would make analysis more difficult, in a way that just
piling on more rounds might fail to.
John Savard
http://home.ecn.ab.ca/~jsavard/index.html |
|
|
| Back to top |
|
| Mok-Kong Shen |
| Posted: Wed Dec 31, 2003 8:21 am |
|
|
|
Guest
|
John Savard wrote:
Quote:
"Tom St Denis wrote:
No and here's why. You have to shuffle after every byte you process. And
how do you shuffle? You need some random bits [or pseudo]. So you might as
well make better use of your PRNG.
But if you have a fast PRNG which isn't too secure, using it to do
shuffles might hide some of the details of the PRNG's output.
However, if you do want to use the full output of the PRNG
efficiently, but you want to use shuffling, there's Terry Ritter's
Dynamic Substitution.
I recently tried to implement a variant of DT but found
that permuting bits could be quite slow. So permuting
instead larger units (bytes) in combination with other
diffusion/confusion mechanisms might turn out to be
more economical.
M. K. Shen |
|
|
| Back to top |
|
| Peter |
| Posted: Wed Dec 31, 2003 2:56 pm |
|
|
|
Guest
|
It never ceases to amaze me how anybody in this group can hijack a
topic. I asked for a opinion and off you went to PRNGs and NAND discussions.
Aside from Tom's reply, which was as expected, I have no indication as
to the validity of my idea. (Tom forgets that RC4 mixes after each encr.
process)
As far as the mixing is concerned... obviously I've got that figured
out. That was a minor exercise. My question concerned...
1) has something like this been proposed before?
2) is this a workable idea? Why or why not!
That is why I asked for serious thoughts, not for an off hand dismissal.
Thank you.
Peter |
|
|
| Back to top |
|
| Peter |
| Posted: Wed Dec 31, 2003 2:56 pm |
|
|
|
Guest
|
It never ceases to amaze me how anybody in this group can hijack a
topic. I asked for a opinion and off you went to PRNGs and NAND discussions.
Aside from Tom's reply, which was as expected, I have no indication as
to the validity of my idea. (Tom forgets that RC4 mixes after each encr.
process)
As far as the mixing is concerned... obviously I've got that figured
out. That was a minor exercise. My question concerned...
1) has something like this been proposed before?
2) is this a workable idea? Why or why not!
That is why I asked for serious thoughts, not for an off hand dismissal.
Thank you.
Peter |
|
|
| Back to top |
|
| Tom St Denis |
| Posted: Wed Dec 31, 2003 3:09 pm |
|
|
|
Guest
|
"Peter" <peter_rabbit@shaw.ca> wrote in message
news:zRFIb.892626$9l5.391346@pd7tw2no...
Quote: It never ceases to amaze me how anybody in this group can hijack a
topic. I asked for a opinion and off you went to PRNGs and NAND
discussions.
Aside from Tom's reply, which was as expected,
Go F' yourself then. I gave my opinion, you asked what people thought.
Hey, if you want people to treat your idea with more professionalism why not
show some on your front. What cryptanalysis have you performed on the idea?
What reference code have you written to see that it actually works?
Quote: I have no indication as
to the validity of my idea. (Tom forgets that RC4 mixes after each encr.
process)
So then how is your idea any better than RC4?
Quote: As far as the mixing is concerned... obviously I've got that figured
out. That was a minor exercise. My question concerned...
1) has something like this been proposed before?
Well since you have failed to present a concrete description of your
algorithm that's hard to say.
Quote: 2) is this a workable idea? Why or why not!
Answer that yourself! Kinda defeats the purpose of doing work if you have
others fill in all the blanks for you.
Quote: That is why I asked for serious thoughts, not for an off hand dismissal.
Well you have to earn attention. Trust me it's hard to get people into what
you want, I've been working on free software seriously for over two years
now. Wait till you have to write support manuals, examples, release timely
bugfixes and do regression testing, etc, etc, etc...
You're idea was just not that appealing to seriously deserve hordes of
attention.
Tom |
|
|
| Back to top |
|
| Tom St Denis |
| Posted: Wed Dec 31, 2003 3:09 pm |
|
|
|
Guest
|
"Peter" <peter_rabbit@shaw.ca> wrote in message
news:zRFIb.892626$9l5.391346@pd7tw2no...
Quote: It never ceases to amaze me how anybody in this group can hijack a
topic. I asked for a opinion and off you went to PRNGs and NAND
discussions.
Aside from Tom's reply, which was as expected,
Go F' yourself then. I gave my opinion, you asked what people thought.
Hey, if you want people to treat your idea with more professionalism why not
show some on your front. What cryptanalysis have you performed on the idea?
What reference code have you written to see that it actually works?
Quote: I have no indication as
to the validity of my idea. (Tom forgets that RC4 mixes after each encr.
process)
So then how is your idea any better than RC4?
Quote: As far as the mixing is concerned... obviously I've got that figured
out. That was a minor exercise. My question concerned...
1) has something like this been proposed before?
Well since you have failed to present a concrete description of your
algorithm that's hard to say.
Quote: 2) is this a workable idea? Why or why not!
Answer that yourself! Kinda defeats the purpose of doing work if you have
others fill in all the blanks for you.
Quote: That is why I asked for serious thoughts, not for an off hand dismissal.
Well you have to earn attention. Trust me it's hard to get people into what
you want, I've been working on free software seriously for over two years
now. Wait till you have to write support manuals, examples, release timely
bugfixes and do regression testing, etc, etc, etc...
You're idea was just not that appealing to seriously deserve hordes of
attention.
Tom |
|
|
| Back to top |
|
| John E. Hadstate |
| Posted: Wed Dec 31, 2003 4:37 pm |
|
|
|
Guest
|
"Peter" <peter_rabbit@shaw.ca> wrote in message
news:MQqIb.872695$pl3.250677@pd7tw3no...
Quote: ------------------------------------------------------------------
Create 2 - 256 Byte arrays: a_key() & rb() (reference box)
In the a_key() scramble the numbers from 0 to 255 according to the
password (similar to an RC4 mix)
Create the ref box (rb()) such that it contains the information as to
which Bytes are stored where in the a_key().
eg. a_key()= 5,1,8,0,4,7,9,2,6,3,...
position 0 1 2 3 4 5 6 7 8 9,...
rb()= 3,1,7,9,4,0,8,5,2,6,...
in other words... rb(0) tells us that the '0' is in a_key(3)
so if the plain text is 834, the cipher text would be 294.
Functionally, there's no difference between this and any other keyed
substitution. Why not? Because there is a one-to-one mapping between a
plaintext byte value and the ciphertext byte value (it really doesn't matter
how you define the mapping). If you shuffle the mapping after each
plaintext character, you have a polyalphabetic substitution cipher with the
number of alphabets equal to the length of the plaintext.
You will also have a horribly slow cipher. Shuffling is not cheap and
rebuilding your arrays after each byte is going to consume a lot of cycles. |
|
|
| Back to top |
|
| John E. Hadstate |
| Posted: Wed Dec 31, 2003 4:37 pm |
|
|
|
Guest
|
"Peter" <peter_rabbit@shaw.ca> wrote in message
news:MQqIb.872695$pl3.250677@pd7tw3no...
Quote: ------------------------------------------------------------------
Create 2 - 256 Byte arrays: a_key() & rb() (reference box)
In the a_key() scramble the numbers from 0 to 255 according to the
password (similar to an RC4 mix)
Create the ref box (rb()) such that it contains the information as to
which Bytes are stored where in the a_key().
eg. a_key()= 5,1,8,0,4,7,9,2,6,3,...
position 0 1 2 3 4 5 6 7 8 9,...
rb()= 3,1,7,9,4,0,8,5,2,6,...
in other words... rb(0) tells us that the '0' is in a_key(3)
so if the plain text is 834, the cipher text would be 294.
Functionally, there's no difference between this and any other keyed
substitution. Why not? Because there is a one-to-one mapping between a
plaintext byte value and the ciphertext byte value (it really doesn't matter
how you define the mapping). If you shuffle the mapping after each
plaintext character, you have a polyalphabetic substitution cipher with the
number of alphabets equal to the length of the plaintext.
You will also have a horribly slow cipher. Shuffling is not cheap and
rebuilding your arrays after each byte is going to consume a lot of cycles. |
|
|
| Back to top |
|
| Peter |
| Posted: Wed Dec 31, 2003 5:07 pm |
|
|
|
Guest
|
you do not need to shuffle the whole array! Simply shuffle the byte just
used with 1 or 2 others. Written in VB6 I manage to encrypt ~7MB/sec on
a 1.8gig Pentium IV. True, other algos are faster, and then there are
some that are slower.
Anyways, you've answered part of my question sensibly. Thank you.
Peter
John E. Hadstate wrote:
Quote: "Peter" <peter_rabbit@shaw.ca> wrote in message
news:MQqIb.872695$pl3.250677@pd7tw3no...
------------------------------------------------------------------
Create 2 - 256 Byte arrays: a_key() & rb() (reference box)
In the a_key() scramble the numbers from 0 to 255 according to the
password (similar to an RC4 mix)
Create the ref box (rb()) such that it contains the information as to
which Bytes are stored where in the a_key().
eg. a_key()= 5,1,8,0,4,7,9,2,6,3,...
position 0 1 2 3 4 5 6 7 8 9,...
rb()= 3,1,7,9,4,0,8,5,2,6,...
in other words... rb(0) tells us that the '0' is in a_key(3)
so if the plain text is 834, the cipher text would be 294.
Functionally, there's no difference between this and any other keyed
substitution. Why not? Because there is a one-to-one mapping between a
plaintext byte value and the ciphertext byte value (it really doesn't matter
how you define the mapping). If you shuffle the mapping after each
plaintext character, you have a polyalphabetic substitution cipher with the
number of alphabets equal to the length of the plaintext.
You will also have a horribly slow cipher. Shuffling is not cheap and
rebuilding your arrays after each byte is going to consume a lot of cycles.
|
|
|
| Back to top |
|
| Peter |
| Posted: Wed Dec 31, 2003 5:07 pm |
|
|
|
Guest
|
you do not need to shuffle the whole array! Simply shuffle the byte just
used with 1 or 2 others. Written in VB6 I manage to encrypt ~7MB/sec on
a 1.8gig Pentium IV. True, other algos are faster, and then there are
some that are slower.
Anyways, you've answered part of my question sensibly. Thank you.
Peter
John E. Hadstate wrote:
Quote: "Peter" <peter_rabbit@shaw.ca> wrote in message
news:MQqIb.872695$pl3.250677@pd7tw3no...
------------------------------------------------------------------
Create 2 - 256 Byte arrays: a_key() & rb() (reference box)
In the a_key() scramble the numbers from 0 to 255 according to the
password (similar to an RC4 mix)
Create the ref box (rb()) such that it contains the information as to
which Bytes are stored where in the a_key().
eg. a_key()= 5,1,8,0,4,7,9,2,6,3,...
position 0 1 2 3 4 5 6 7 8 9,...
rb()= 3,1,7,9,4,0,8,5,2,6,...
in other words... rb(0) tells us that the '0' is in a_key(3)
so if the plain text is 834, the cipher text would be 294.
Functionally, there's no difference between this and any other keyed
substitution. Why not? Because there is a one-to-one mapping between a
plaintext byte value and the ciphertext byte value (it really doesn't matter
how you define the mapping). If you shuffle the mapping after each
plaintext character, you have a polyalphabetic substitution cipher with the
number of alphabets equal to the length of the plaintext.
You will also have a horribly slow cipher. Shuffling is not cheap and
rebuilding your arrays after each byte is going to consume a lot of cycles.
|
|
|
| Back to top |
|
| John E. Hadstate |
| Posted: Wed Dec 31, 2003 6:48 pm |
|
|
|
Guest
|
"Peter" <peter_rabbit@shaw.ca> wrote in message
news:0NHIb.883354$pl3.606937@pd7tw3no...
Quote: you do not need to shuffle the whole array! Simply shuffle the byte just
used with 1 or 2 others. Written in VB6 I manage to encrypt ~7MB/sec on
a 1.8gig Pentium IV. True, other algos are faster, and then there are
some that are slower.
Anyways, you've answered part of my question sensibly. Thank you.
Peter
Okay. Now let's try for round 2. Suppose that instead of mapping your
plaintext bytes through these shuffled arrays you simply add a different
pseudo-random value (mod 256) to each plaintext byte. How is that better or
worse than your original proposal? Hint: functionally, it's exactly the
same thing!
So, what you've constructed is a stream cipher whose security lies in the
unpredictability of the PRNG. The shuffling twist may make it harder to
analyze the PRNG (because it adds state to whatever state is in the PRNG),
but that's all it does. If you've got a good PRNG (like AES in CTR mode)
and you're careful not to abuse it, you may have the basis for a secure
cipher system. |
|
|
| Back to top |
|
| |
Page 1 of 3 Goto page 1, 2, 3 Next
All times are GMT - 5 Hours
The time now is Sun Nov 23, 2008 3:54 am
|
|