Ponder on this.

the

..

Yes, that gives a little more insight. I suppose you could XOR several JPEG files for more randomness. The first with the second, and that result with the third, and so forth. Seems not too difficult to produce secure encryption.

Are you familiar with the encryption used on the internet for secure financial transactions? I always wonder how secure my connection is when logging onto a financial site. Paypal or whatever.

-Bill

" snipped-for-privacy@att.bizzzzzzzzzzzz"

reduce the

number

and

of

entropy

which

consists

at

the

would

instance...

goes

Much of that is provided by secure sockets layer 'SSL'. =20 This may help you:

?-)

uce the

nd

of

ropy

at

ld

ce...

es

Yes, thanks for the link. It was a little deep for me, so I did a search for (TLS) Transport Layer Security, and found something in wiki.

"In order to generate the session keys used for the secure connection, the client encrypts a random number with the server's public key and sends the result to the server. Only the server should be able to decrypt it, with its private key."

So, I guess if you send me an encoded random number using my published procedure which everybody knows, I can decode it using my secret key which nobody else knows? So, the procedure of decoding is different from the procedure of encoding. Everybody knows how the data is encoded, but only the receiver knows how to decode it?

Is that about right?

-Bill

Getting a good bit closer.

That part of the preliminary key exchange is supported by what are called public key crypto systems. They have paired keys, one public and one private generated such that one key cannot be reasonably derived from the other. Examples include RSA, see:

And a related system issue, key exchange:

Does this help you form a more complete picture?

the

In a public-key system, I publish my public key for all to see. Anybody can use that key, and a public program, to encrypt stuff and send it to me. But only I have the matching decode key.

John

On Jul 13, 8:53=A0am, John Larkin

It's the public program I don't get. Knowing the public program and the public key would suggest anyone could work it backwards to decode the original message. I think it has something to do with the time required to do that. I found an example in wiki, but the math is a little deep.

Notice it says;

"In real life situations the primes selected would be much larger; in our example it would be relatively trivial to factor n, 3233, obtained from the freely available public key back to the primes p and q. Given e, also from the public key, we could then compute d and so acquire the private key."

-Bill

The public key is a product of two large primes. The program that manipulates the data can be published. There is no reliance at all on security by obscurity. The mathematics protects the secrets.

Those two large numbers are important in that have been carefully tested for primality: by construction having no small factors I think it has something to do with the time required to do that. I

The crucial point is that it is easy to compute the product of two primes, but it is incredibly difficult to factor a very large composite number where the factors are a roughly similar size.

A discussion of the relevance of key size in public key encryption algorithms is given at:

PS. I would not rely on 128bit encryption for anything I really cared about keeping secret.

Certain methods may have backdoors and trapdoors as well as that of the official keyholder. US DOD tried to foist one such system on the world Clipper/Skipjack a while back. When it was eventually declassified cryptanalysts at universities pretty effectively shredded it.

Probably a bit too mathematical for you but a bit more detail online at:

Regards, Martin Brown