Re: SPES (my new encryption) one of its kind
- From: "Joseph Ashwood" <ashwood@xxxxxxx>
- Date: Fri, 12 May 2006 22:30:38 GMT
<doctoresam@xxxxxxxxx> wrote in message
I hope everybody look into the introduction and tell me what he think
I'll tell you, but I don't think you'll like it. Standard disclaimer when
I'm talking to someone who proposes a new cipher around here: Your design
will be torn to little tiny pieces. If these little tiny pieces are
insecure, your system is insecure. If the little tiny pieces are secure,
well we won't have to worry about that.
Security Priority Encryption System (SPES)
Start with a better name, this one shows you don't understand what security
or priority is.
Section 1 : some assumptions
Work on some real asumptions, this was just some random statements.
Section 2 : features of the required encryption algorithm :
1- the encryption key should be as large as possible
if you count it 2^256 in AES for example is huge , however
cryptanalysis also can reduce this huge number considerably making this
key length less attractive.
to be sure you have to make this 256 bit much more , so that even
cryptanalysis is difficult or impossible , and when I say "impossible"
I mean making it so long that you do not have enough time in your life
to decrypt this massage
Key length has nothing to do with difficulty of cryptanalysis. Just to give
a trivial example, remove the subkey generation procedure form AES,
substitute with a key large enough to simply be split between the subkeys,
it will still offer the same strength as before even though the key is now
many times larger.
Further difficulty in performing cryptanalysis is actually a bad thing.
Because of cryptography's position it is easiest to understand things from a
kill vs be killed scenario. Which would you want in a fight:
1) A well made, fully loaded gun
2) A device I make that I certify will never jam and fail to fire. Can be
used at any speed you can handle. Capable of penetrating any armor. Is so
forward looking that the US military is only recently looking at it as a
possibility for the future of combat.
I'll give you a hint, device 2 is walkman with some speakers (it's good to
20,000 per second!!!!, and it's true that the US military is looking at
sound for weapons, just their designs are more substantial). All I did was
make analysis of the risks involved difficult, and in so doing many people
would have entered combat with a walkman.
Marketing excretia is not a good way to discuss cryptography. Either give a
solid reason why 2^256 is not a big enough number, or change your concept to
line up with the truth.
2- the length of the encryption key is known to the hacker, instead it
should be arbitrary
the arbitrary length makes guessing the key much more difficult , in
AES for example the longest key= 256 bits so the number of possible
keys = 2^256 = 1.15 E+77 , but if the key is arbitrary then the number
of possible keys greatly increase e.g. 2^256 + 2^257 + 2^258 . . . . .
. +2^2454 . . . . . . + 2^ 6546484 etc.
Actually, take a look at the complexity involved. If we take the sum of the
complexity of brute force search for all key lengths < K, we have a maximum
complexity of (2^K)-1 in a brute force search. It is far better to simply
design the system with a K-bit key (with brute force complexity of 2^K), so
that, going back to point 1, proper analysis can be made.
3-many of the current encryption methods has only few steps of
if you look at almost all the encryption algorithms commonly used today
you will find them having relatively low number of steps e.g. 10 or
so.... like : s-box +permutation + ..... etc
this low number of steps markedly makes cryptanalysis easier from 2
1- fewer steps means more easy to "follow it backwards" to the original
text ,or more easy to analyze the encryption system as a whole
Again, this is actually a good thing. Making complex designs leads very
quickly to the marketing excretia problem in 1. By making a system that can
be analyzed in depth you can make sure that every known attack fails against
2- fewer steps means that decryption takes very short time ... which is
not good security wise because the hacker will need to try a huge
number of keys until he find the correct one .... making encryption
slower (by making it complex) will force the hacker for more computing
power or more time which is a security advantage .
You do have a small point here but you picked the wrong place for it. There
is a philosophy of cipher design that says make the key function compute
intensive. The idea being that the legitimate user will only be doing it
once, but that the attacker will payit over and over. Unfortunately, this
philosophy has fallen out of common use because all the attacker needs to do
is break the key generator in such a way that generating K processed keys
does not take K*generating 1 processed key, RC2 makes a good example of this
flaw. The end result is that you may actually give the attacker a greater
advantage because the user will try to save processing time by reducing key
so in short : making the algorithm slow add some security at least from
this aspect ,other aspects may play its rules it shall be discussed
I realize it is counter-intuitive, but because users will optimize their
experience, it very often leads to actually weakening the security.
4- block ciphers are stupid
I feel very stupid depending on block ciphers alone ... why? for mare
than one reason....
1-I can " image " that the super hacker (he is genius .. remember) can
compare various blocks of the encrypted massage and come up with the
key , although this may (I am saying "may") not be possible , who knows
? but I think it is somehow possible (our genius hacker can tell us)
So basically your argument against block ciphers is that cryptanalysts
exist. I've got news for you, no matter what system you design, we exist.
2- block ciphers means that the hacker can hack the cipher using one
block of cipher text
The Unicity Distance says differently. In fact if one makes full use of the
unicity distance in the design of a system you can actually reach a state
where even a very long ciphertext actually cannot be broken. Of course this
level of work is rarely worth it, and will very often be counter-productive,
but it is possible.
, instead ... another approach can make the
process slower to the hacker by making processing the whole text as a
unit mandatory (to be explained during explaining my encryption system)
File ciphers don't work well in practice for many reasons, the biggest of
which is streaming. Let's say I'm chatting with Tom, a file cipher is
ineffective because the entire text of the session is not available. The
best you can do in this case is to drop down to fixed sized (or variable
sized) chunks of text.
Of course the method of preference (because mathematical proofs exist for
this) is to use a secure chaining mode which allows the designer to build
things in arbitrarily sized blocks.
5- the encryption algorithm should be "driven" or "guided" by the key
in the current encryption methods the steps of encryption is constant
whatever the key was (the key only act as a "password" to the
algorithm, this is not strong since it makes the job of the hacker
instead: the key should control how the algorithm work i.e. the
encryption system should "take orders " from the key itself
in effect to this : each and every different key will have its
fingerprint on the algorithm itself in terms of the number and the
nature of the encryption steps, noting that "having its fingerprint"
does not mean that it becomes disclosed .... (to be explained during
explaining my encryption system)
Actually, there have been many attempts at this, none of them very
successful. During the AES contest FROG was just such a design. The problem
with these designs is not that you don't have some portion of keys that are
secure, but that making sure every key result in a secure construction
becomes effectively impossible. In the worst case your design gets whittled
away until only 1 key remains strong, from there brute force is trivial.
6- the encryption algorithm should be "driven" or "guided" by the
contents and the length of the plaintext itself
the plaintext should have its fingerprint on the algorithm ,again not
in way that disclose it .... (to be explained during explaining my
This actually won't work. The reason is quite simple, at a certain level
your key selects a permutation, that is, there exist no inputs i,j such that
i<>j and F(i)=F(j). From there it is reasonably easy to prove that even if
your plaintext is incorporated into your cipher design is some way, there is
an expression of your design that does not have this behavior.
7- the encryption algorithm should incorporate randomness into the
cipher text (salting)
this makes the job of the hacker much more difficult
Actually not really, at least in most cases. You would have to cryptanalyze
the source of random bits as well in order to see whether or not that system
could be compromised. If the attacker con compromise your source of bits he
can now push the unicity distance in his favor instead of yours.
8- the encryption system should not depend only on one or few math
The problem with this is that you have to prove that you rely on A OR B OR C
OR D being true, but history says that is difficult, and you will end up
with relying on A AND B AND C AND D being true, so the attacker only has to
break one of these to break your system. The problem many people don't
realize is in cryptography is that putting all your eggs in one basket tells
you very easily if your eggs are broken, but with multiple baskets it is
harder to check them all.
10- distraction layers should be used a lot (very important)
Completely unimportant in the best case, a crticial flaw in the worst. Any
keyed structure has to be cryptographically strong, otherwise it can and
will be used against you, but this costs you setup time, you have to find
entropy for it, etc which slows things down and now we're back to the user
optimizing their own experience. Any unkeyed structure is cryptographically
I would like to here your comments while I write description for my
encryption system in details .. (in few days period)
does not work with
not only that : my system already examined by experts around the world
and no flows found , be assured
Also, since you are posting here free from any defenders, I suspect your
"experts" are nothing of the sort. If you can get any one of David Wagner,
me, Robert Silverman, Ron Rivest, Coppersmith, Schneier, Shamir, Daemon,
Rijmen, Wu, or pretty much anyone else that has ever published a
cryptographic paper, or has experience as a cryptanalyst, I'd be well and
+ my system has more "careful consideration" than some of the stupid
encryption system like AES for example
AES has nearly a million hours of examination behind it (bulk estimate).
Considering that you are designing this alone and that 1 million hours is
longer than your lifetime this statement is just plain false.
Based on what's been said I give the design a couple of weeks. The reason is
quite simple, the design is ill-thought out, the author doesn't speak
english very well, there doesn't seem to be a strong mathematical background
to build an design from, all of this will make it very difficult to
understand the design. Basically, I probably won't bother looking at it for
a few months (I've got a product to get out the door), I'll let someone else
grab this low-hanging fruit.
- Re: SPES (my new encryption) one of its kind
- From: doctoresam
- Re: SPES (my new encryption) one of its kind
- SPES (my new encryption) one of its kind
- From: doctoresam
- SPES (my new encryption) one of its kind
- Prev by Date: Re: DaVinci Crap!
- Next by Date: Re: Tor Security Discussion Thread
- Previous by thread: Re: SPES (my new encryption) one of its kind
- Next by thread: Re: SPES (my new encryption) one of its kind