Re: Is it possible to encrypt without a key ?

From: Johnny Bravo (nospam_at_no.com)
Date: 08/13/04 

Date: Fri, 13 Aug 2004 21:16:27 GMT

On 13 Aug 2004 10:06:50 -0700, doublehp@doublehp.org (Doublehp) wrote:

>about me: I am student in UK (originally french), Linux user since 4
>years(good knownledges), programming every day iusing various
>langages, but I am a beginner in crypto, and whant to have a start for
>fun.

  Start by learning about crypto, you can get the Handbook of Applied
Cryptography from the web http://www.cacr.math.uwaterloo.ca/hac/

>What I need: I need to encrypt some data with a brand new algorythm,

  Probably a bad idea as you don't know anything about crypto.

>which might be published under GPL, for a new application about CDs: I
>have to design a new algorythm.

  Almost certainly a bad idea since you couldn't recognize a good
algorithm from a bad one. There are plenty of good, and free,
algorithms in the public domain that are almost certain to contain far
fewer weaknesses and will encrypt/decrypt much faster than anything
you will come up with by yourself that meets your requirements.

  I mean no offense but how good of a program could you expect from
someone who says they are good at crypto but a beginner at programming
and this person gets only *1* chance to write a program and no chance
to debug it before release, they don't even get to run it to see if it
works before it is released. Crypto is like that, you have no idea if
it is good or not until it gets broken, having a bunch of experts look
at it can give you a much better estimate of it's strength than just
making something up and hoping for the best; but even that is no
guarantee.

>Those CD should be read by MS-Windows comps.

ie. It can be read by anyone who really wants to read it.

>What the stuff should do:
>- the encryption process is done by myself, with a powerfull computer;
>this process can be as long as required.

  Encryption, with a fairly good algorithm, is usually a fast process
and doesn't require a super fast computer.

>- the normal process of decryption haz to be possible in realtime for
>a Pentium 3 / 800Mhz : that mean decrypt 700Wb within 20 or 30 mn

  Decryption is usually a fast process as well, even on the target
machine you should be able to decrypt 700mb in under a minute.

>- it is highly probable that the algorythme will be published, but CD
>will not mention the URL

  Irrelevant, in crypto you ALWAYS assume your attacker knows your
algorithm. Security through obscurity is a very, very bad idea. Good
ciphers stand up to attack even though the algorithm is known, bad
ones are toast if a decent attack can be found.

>- the process must not allow a debugger to view decrypted data
>'easily'

  If you write it to disk or display it on the screen or load it into
memory, it is trivial to view the decrypted data easily. If you do
none of these things, there seems no point in decrypting it at all.

>- CRITICAL POINT : THE PROCESS MUST NOT BE CRAKABLE BY A GENERIC
>PROGRAM, NOR BY A SPECIAL PROGRAM

  This isn't a critical point, it is a wish. You plan to design a
completely untested cipher with absolutely no crypto background, the
best you can hope for is you get lucky and no one finds a massive
security hole in your cipher that can easily be exploited.

>- the CD must contain a self extractor.

  Trivial, put an exe on the CD, with windows it can even be the
autorun.exe, for those who actually use such things.

>- the CD should not be extractable by an other way than using the
>extractor easily

  Irrelevant, you always assume your attacker can get your encrypted
text, trying to "hide" it on the CD is doomed to fail from the very
start. A proper algorithm doesn't rely on hidden ciphertext or a
unknown cipher to be secure. Besides, trying to hide a file on a CD
so that the computer can't find it but your extractor can is a
programming problem, not a crypto one, that's your area of expertise.

>- an extractor will decrypt the data, and use them in memory without
>accessing the hard drive

  That's a programming concern, but any competant programmer should be
able to get the data from memory and write it anywhere they want.

>- I dont tell about other contraints for now, unless any one asks me
>more details
>
>explanations:
>
>I know that using a good debugger ( or even an emulator like bochs or
>vmware) it is possible to crak everything -> a very good programmer
>can crak everything.

  It only takes one, what one person can crack, a program using their
knowledge can let anyone crack.

>When a manifacturer presses CDs, if there are 100 000 CDs or more, it
>has to engrave several masters. I will provide a different image for
>each master; saying that: it a haker got two CD presse by two
>different masters, IT MUST NOT BE ABLE TO WRITE A GENERIC CRAK TO
>EXTRACT BOTH CD WITH THE SAME APPLICATION/ALGORYTHM WHEN TRYING TO
>EXTRACT DATA WITHOUT THE EXTRACTER.

 And if any programmer cracks it, they can write a program to do it
automatically. And if one person gets it, they all get, rather than
worry about your different CDs use one key; if one person gets your
decrypted data they can just write it to a disc and share that
instead.

>>From that point, a friend gexplained me that:
>- if you have two masters with the same data, encrypted with the same
>algorythm but with different keys, and provided you know the type of
>data contained on the disk, you can easily compute statistical tables
>about the encrypted data, and recover both keys;

  Only if you use a weak cipher, but you don't know a weak one from a
strong one, good luck with your design effort.

>then it is possible
>within resonable time to write a crak able to recover any other master
>encrypted with the same algorythm ( for example, if the data is a
>film[what ever the codec], encrypted with DES, then the haker can know
>where are the keyfrawes, and recover the key using those informations)

  Assuming that DES wasn't capable of being brute forced, using
certain modes of DES won't let you recover the key by knowing what
certain bytes are.

  Speaking of video, if that is what you are trying to hide, you've
failed already. If you show it on my screen and play it on my
speakers, I can capture it to disk completely unencrypted without even
caring about your hidden data, your algorithm or anything else you've
done to prevent me from getting to the data on disc. Nothing short of
replacing my operating system will prevent me from doing so.

>- that is not good for me.

  The thing that is not good for you is that you don't even know how
much you don't know about crypto. Once again, this is nothing
personal, you need to learn quite a bit more before you even start a
project like this.

>Other bad point: the decryption has to be
>stored in the extractor as is, what mean it is very easy to rewrite a
>generic extractor by desassembling any extractor of any master.
>- thus he dgave me a tip: if the extractor do not contain key, the
>second problem is avoided. If each master use a different algorythm,
>the first problem is avoided.
>- the solution is thus to compile each master with a different
>algorythm, without key

  If the extractor doesn't contain a key just an algorithm, the
algorithm "becomes" the key and is easily reverse engineered just like
a serial number generator in a shareware crack program. They find
your algorithm, write a program that does it to your data and writes
it out on a disk.

  Crackers like a challenge, they will just make one crack for every
differnt master, just like game crackers do for each new patch to a
game. Once they get your data they will just rewrite the cracker to
test each differnt algorithm you release in sequence, once they know
what the data should be it will be trivial to test some data to know
which of the decryption routines to use.

>Of course before applying the encryption process, I will compress the
>data to add a bit of anthropy, perhaps with a simple Hauffmann process
>( adds entropy, but not too heavy to unpak).

  If, as you mentioned before, you are using video, it's likely
already compressed and further compression will only make the file
bigger.

>Please tell me what you think about all that:
>is such a process fesable ?

  Not the way you plan to go about it.

>what can be the security holes/issues ?

>Has any one ever done something like that ?

  Heh, CSS, and we all know how well that worked. A P3/450 can brute
force a "40 bit" CSS key in about 18 seconds.

>How can I make a start in that stuff ? which existing algorythm allow
>modification so that I can implement my own algo ?

  Modern crypto isn't about hidden algorithms but strong ciphers,
proper modes of encryption and secure key management, which you can't
really accomplish by sending the key along with the message. 

-- 
"We will always remember. We will always be proud. 
We will always be prepared, so we may always be free."

Relevant Pages

  • Re: Encryption key changing the encryption logic.
    ... >>decides among various elementary crypto operations based on what it sees ... >>adversary knows which key bits select which algorithm and, in practice, N ... > or two rounds of a different block cipher. ... this design is covered under the 1-of-N discussion and your design is ...
    (sci.crypt)
  • Re: Possible new crypto system
    ... Standard cryptographic advice is never to touch any secret algorithm ... if I had a way to encrypt a "text" (some binary data ... Those are the basic requirements for any crypto system. ... Any good modern crypto system is proof against brute force. ...
    (sci.crypt)
  • Re: How much must be revealed
    ... You can convince peope to trust your /algorithm/ by publishing it. ... You can convince people that you are not a liar by providing source code. ... Not only because the algorithm cannot be ... Microsoft-built crypto software in the black. ...
    (sci.crypt)
  • Re: SSH - securing the port
    ... Exactly how do you plan to use your knowledge of SSH ... That best form of crypto is the one that exactly one person ... unpublished algorithm. ... mathmatics out at the limits of human ingenuity, not secret decoder ...
    (comp.unix.solaris)