Re: Checking a foolproof algorithm.

From: spymix (spymix_at_sbcglobal.net)
Date: 07/27/03 

Date: 26 Jul 2003 21:04:25 -0700

kurt wismer <kurtw@sympatico.ca> wrote in message news:<iTyUa.12896$Wh.1302014@news20.bellglobal.com>...
> spymix wrote:
>
> > The scenario --
> >
> > I am an honest and trustworthy person and my friend is also an honest
> > and trustworthy person.
> > We have the same interest in encryption/decryption and programming.
> >
> > I believe I have discovered an algorithm along with the 2 prefixed
> > keys that will create a foolproof coded message. I also created the
> > decryption program.
> > I send my friend the encrypted message along with the 2 prefixed keys.
> > I also send him the same decrypted message.
> >
> > My friend by the way is an accomplished cryptologist and programmer.
> >
> > He studies the two (coded/plaintext) messages for as long as he needs
> > to. He performs the entire test and they turn out inconclusive. He
> > then attempts to write a decryption program to break the coded message
> > but is having a lot of trouble finding out what the 2 key values do.
> > Or at least that is what he thinks the problem is. He brings in other
> > experts and they still have problems writing the decryption program.
> >
> > Given the information above, could this be a possible or impossible
> > scenario?
>
> it's a possible situation, but it's not a very useful one...
>
> > If it is a possible scenario, then the encryption algorithm is
> > foolproof.
>
> and this is not a valid conclusion...
>
> you have made an error in your hypothetical situation... you've made
> your keys known to your attacker but not the algorithm... in any
> practical sense it's the converse of that which you need to be secure
> in... encryption/decryption algorithms cannot remain secret if they're
> used by the public, but keys can... and since the algorithm can't remain
> secret, it can't be considered secure just because someone can't guess
> what it is while it still is secret...
>
> breaking an encryption algorithm does not mean being able to reverse
> engineer the algorithm given all the inputs and outputs, it means being
> able to recover the plaintext (that which you encrypted so as to hide it
> from attackers) from the ciphertext (the encrypted data) in a usefully
> short amount of time... usually without being given the key(s)...
>
> your example is like a door with the key hanging right on it, but with
> the lock hidden in an obscure and hard to reach area... it's security by
> obscurity...

But what if each time a message is sent (encrypted only) one of the 2
keys (which is the most important key), values are different from all
previous messages and the other key value varying between 1-17 integer
value! The value in the important key is not integer but a rational
with a limited length of decimals which actually drives the algorithm
that changes that value into an irrational. Which is then used for
each decimal in its expandtion to correspond to each plain text letter
to add as an integer with each plain text letter value creating a new
letter value. There is also a slight twist here but hard to explain in
a few words. Also these are all unique irrationals that can not be
found easily. I can elaborate if need be but it is difficult to
explain.

Would doing it this way help in the security of any given encrypted
message

These keys could also be prefixed as letters in the encrypted message
so as to be disguised within the actual encrypted message. Where the
first x amount of letters could be the rational key and then the next
2 letters representing the next key integer values between 1-17. All
these prefixed letters (26) could have predetermined values for key
values in the algorithm. Which could also be placed with n letter
length @ end of decrypted message also looking like part of the
cipher.

You are right about exposing the keys.
So it probably would be best to hide the keys within the encrypted
message like I explained above. Where everything looks like one
encrypted message.

Dan

Relevant Pages

  • Re: Checking a foolproof algorithm.
    ... > We have the same interest in encryption/decryption and programming. ... > I send my friend the encrypted message along with the 2 prefixed keys. ... > then attempts to write a decryption program to break the coded message ... your keys known to your attacker but not the algorithm... ...
    (sci.crypt)
  • RE: Email Encryption Between Servers
    ... Secure E-mail, PGP, secure web server, ... Are the doctors going to have separate keys for each provider, doctor, ... desktop e-mail encryption, enterprise e-mail encryption. ... manage key exchange, staff training, ...
    (Security-Basics)
  • Re: Prosecutor cannot compel disclosure of encryption keys?
    ... And how many "home grown" encryption algorithms have ever proven ... Just because you come up with an algorithm that ... This is the major problem with a prosecutor demanding keys. ... The suspect never hands over the legitimate key. ...
    (sci.crypt)
  • My response to a message by Dorothy Denning in 1995 - Australia and Encryption Policy
    ... Subject: Australia and Encryption Policy ... interception, which includes the issue of the use of cryptography as: ... keys but may be required to provide them in response to a court order. ...
    (sci.crypt)
  • Re: OTP and message integrity.
    ... Without the keys, ... You provide some level of integrity, ... The encryption is provided by an OTP. ...
    (sci.crypt)