Re: SPES (my new encryption) one of its kind



Hum, actually if cryptanalysis may reduce the effort in breaking
something at less than bruteforcing the key, the system is broken.
It's quite obvious that noone should use a system known to be broken

i totaly agree


and for the very same reason people trust more clean and simple designs
with provable security properties rather than a system very difficult
to understand and with properties that are hard to forecast, understand
and prove with known math.

i agree with you ..

i have 2 questions :

1- can you name an encryption system which has provable security ?

2- some time in future we will reach a limit where computers very fast
and we have to do some designs that is nightmare to prove secure ...
what will you do?





For the same reason, the key size is not a factor to overstimate, since
an AES128 is far more secure than a Vingenere cipher even with a MB
sized key... since cryptanalysis lead to crack the second cipher with
really smaller effort than bruteforcing.

i totaly agree

however like you said later in this page

"I usually agree that if no other things get in conflict with that you
should use the bigger key, but only if the bigger key is available for
a system that has proved to have desiderable security properties!"




Moreover, it's probable that users will use password recoverable with a
dictionary attach (few thousands of words are commonly used in a
language...) or that are related to dictionary entries and can be
recovered with some billions of trial instead of 2^n, so independently
from the cypher's keyspace

true ,but that depend on you random number generator not the cipher
itself


, so the keyspace may not even matter and
certainly is not the magic bullet!

agree



So a good Key Schedule algorithm becomes critical for non randomly
generated password (that on the other side will require to build a
robust protocol and a good randomness sampling tool).
And moreover in real world it should not be understimated that people
may even use silly password that may be easily guessed or recovered
with social engineering, or the password may be extorted or etc etc...

this should not be allowed

personally , in my system i will make the password a several megabyte
file


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.



The step are like the legs of Pres. Lincoln, long enough to touch the
ground. In other words steps are chosen to give some security
properties and, yes, as a general role of thumb more is better (but
generally will require a new proof).

ok ...



But if the aim is to aquire a certain security property why overkilling
it?
i think doing more "mixing" makes decryption very diffecult especially
if salting is used


The system is weak as the weakest link, we should try to spot out
and eliminate weak points rather that getting overkilling results in
other points, that will generally not cover unrelated weakness, but
securely they will cost computational complexity.

you know .. i tried some benchmarking using c++

in 5 Mbyte file i was able to do 2 milion such operations in just 3
seconds


it does not add much complexity also because my computer is not very
fast

why i insist? i think more complexity will give cryptanalysist hard
time




No, if the system reach a target of security making it slow will not be
generally a benefit unless there is another target of security to
reach.
And the attacker may rely on much more computing power than the user!

yes , exactly ... i read that some big hackers use ICs to crack
encryption (very fast decryption)

so there is really another target of security which is making the
encryption breakable only by computers not ICs



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)

Well, the problem is: has it less computational complexity than
bruteforcing the cypher? If no, it's not a viable attack and attackers
will not bother, chosing a simpler way.

who knows ?


in that sense even if one agree with your point
may not say that a block cypher used in CTR mode is stupid!)

possible .. honestly between me and you i doubt it



The rightful user may need to access the file in small block (because
it's remote, because smaller chunks will easily fit in the CPU cache
making the application faster) while the attacker may not suffer any of
those constrains... I think that it may be more a drawback than a real
advantage.

true ... forgive me i did't state something in the first place :

my sytstem is very slow system , but crazy

it is used for long term file archieving or sending a file over
insecure medium like the internet

ONLY



I know what you are saying, if you Google for my name plus "kyu" you
will find my attempts to make an adaptative algorithm driven (in a
nonlinear way) by the key and or by the plaintext.

good , i will read on that and go back to you


The very problem is that proving that you never fall into a non secure
mode of operation is quite a nightmare! As said before, its more
trustworthy something you may forecast and understand security and
insecurity issues before rather than something hard to understand and
nearly impossible to prove.

i think you can ... how?

use some "trusty" encryption system e.g. AES (if you agree)

then take the output and encrypt it with your system





7- the encryption algorithm should incorporate randomness into the
cipher text (salting)

Well, most actually does it mandatory.
which cipher does that?




8- the encryption system should not depend only on one or few math
theories

Well, in the future I'll tend to trust a newly designed system
addressing newfound issues rather than an old system designd to be
future proof!

i wonder what happened to those algorithms which was supposed to be
"secure"

why not i try my idea?


Otherwise, something similar can be obtained, without falling in any of
the (hopefully costructive) critics I expressed before, simply
composing different cyphers, so having a cypher or even an entire class
of cyphers broken will not be an issues if those old files were
encrypted also with ciphers that resisted to the future!


ok ... why not ?





Most systems jet require it mandatory.
can you name some please?




10- distraction layers should be used a lot (very important)
operations on the plain text that plays with the bits and bytes a lot
should be used EXTENSIVELY ,and when I say extensive I mean at least
millions of times

It's not required.

come on my friend .... do not be so sure



Perfect privacy may be obtained with a singlexor
operation given enough enthropy (One Time Pad)

i read a lot about OTP being not perfectly secure unless you have 100%
RNG device



If I may hint, you should:
- consider some work on message authentication: privacy is not the only
important result in cryptography, sometimes is mandatory know if the
message was tampered;

my idea cover that also ... actually in the system i have in mind if
you change one bit (bit not byte) most probably the entire plain text
may not be decrypted correctly



- keep message content privacy separated from message concealing, that
requires rather different approach and tecnique (as I said before,
about steganography)

that is another thing



thank you for discussing with me .... nice

.

Relevant Pages

  • Re: SPES (my new encryption) one of its kind
    ... That scheme seem quite complicated and, in fact, you may see a cypher ... as a good example of an algorith having all characteristic of a secure, ... canonical multilayer encryption, where, if I undestood well, what you ... but sure there are other ways security can get ...
    (sci.crypt)
  • Re: SPES (my new encryption) one of its kind
    ... with provable security properties rather than a system very difficult ... an AES128 is far more secure than a Vingenere cipher even with a MB ... If you are speaking of the key used into the encryption, ... bruteforcing the cypher? ...
    (sci.crypt)
  • Re: Enigma machine strenght using a computer
    ... cipher with rotors that spin backwards, forwards, stop and start based ... Is this a good way to get security on modern ... encryption less error-prone and they were a cost effective way to get ... case) than not since a wider base uses the same algorithm. ...
    (sci.crypt)
  • No Shared Cipher message
    ... 128 encryption) ... No Shared Cipher ... Your browser is unable to negotiate a security level ... Update your browser to a version that supports the ...
    (microsoft.public.windows.inetexplorer.ie6.setup)
  • IE6 - No Shared Cipher Message
    ... 128 encryption) ... No Shared Cipher ... Your browser is unable to negotiate a security level ... Update your browser to a version that supports the ...
    (microsoft.public.windows.inetexplorer.ie6.browser)