Re: New Encryption Idea

<a.manansala@attbi.com> wrote in message
news:1119014431.946168.315940@g43g2000cwa.googlegroups.com...
> As I noted, secrecy is a problem with any encryption or security
> system.

The problem lies in the lack of temporality to the secrets, with a modern
pRNG the secret needs to be kept at most a few minutes, with yours you
clearly expect them to keep it for 66.7 years.

> For example, credit cards have this problem through mail delivery. They
> address it in their own way.

And unlike yours they expect the secret to remain so for only a maximum of 5
years, and they have recovery procedures in place.

> The public key system must keep private keys secret where those keys
> reside.

Even those are generally temporaly limited, you will find that they expire
long before the 66.7 years you have claimed, this is a very real security
problem, one that you do not even attempt to solve in any way.

> The problem with secrecy is different than that of the algorithm
> itself.

In this case it's actually the reverse, protecting large things is
difficult, protecting small things is easy, that is why we use public
algorithms with secret keys. Protecting the few kb of code to process the
data is in this case easier than protecting the data.

>> Further having them come in the same box with the program requires that
>> these be typed in but also on page 2 there is very clear discussion that
>> the
>> method discussed makes use of tRNG files in the multi-kb range. I have
>> significant doubt that any user will expend the effort necessary to
>> duplicate even a 1024 character file onto their system, let alone the
>> 100KB+
>> files being discussed.
>>
>
> No, the files are electronic files that are downloaded from disk or
> possibly from the internet if you have end-to-end security.

So have you decided to surrender? Your last statement makes it perfectly
clear that end-to-end security is already in place (otherwise it could not
be downloaded), so your algorithm is at best redundant.

> Or they come already with your package like a new computer.

In the same box that is routinely opened and inspected for QC purposes which
means that it is not in any way secure.

> And there's no need for 1024 byte key. This is not a prime
> factorization problem. A 24 byte key is the minimum length and
> sufficient for most operations.

You're confusing what I said with what you think I said. Your system has
multiple keys, one of those keys is the random file, which is by all
statements at least 1KB.

> The key is basically information you have to type in anyway for
> authentication.

Actually in modern systems you don't. In modern systems we use strong
cryptography to go from something a user chooses and can easily memorize
(passphrase) to a key that decrypts the actual keys. We can make a lot of
proofs around this (like that if there is not MAC on the keys an unused key
cannot be decrypted under the OTP proof). With your system we have a huge
mass of secret information with no protection around it.

>> Also from Page 2 you have an error of omission in the paragraph
>> discussing
>> eBay you fail to disclose the filesize necessary leaving only the
>> assumption
>> that the same 100KB file is being discussed from the previous paragraph
>> but
>> the numbers don't add up for that.
>>
>
> That could be a little confusing because I did not give enough
> information.

I suppose I should have been clearer, the paragraph you are discussing has
to do with the user using eBay, the one I was discussing is the next
paragraph, the one actually about eBay, the one where you claim 446 years
without any support.

> But lets assume all you need is one 192 bit (24 byte) key for the
> session.
>
> A 100 KB file produced 10 billion random bytes taking one byte at a
> time (it can take more in the MEAS encryption mode).
>
> 10,000,000,000 / 24 (key) = 416,666,666
> 416,666,666 / 17,123 (sessions) = 24,334
> 24,334 / 365 (days in year) = 66.7 (years)

Since you are already confused, I'm going to raise the bar a little bit. How
do eBay and the user agree on a key? RSA won't have the pRNG requirements
you've set out, instead it requires much more random data. DH generates it's
own keys. ElGamal would not be as secure as DH in this instance. Ntru would
require more data. So the only solution I can find is that the data pool is
shared between the sides. Now we're in an area where you have successfully
_LOWERED_ the security of the entire system by many orders of magnitude.
Instead of using solidly built hardware that does RSA for them, and
generates random numbers, eBay now has to rely on a poorly constructed
massively insecure system. Your example crumbles.

>>
>> End of page 2 the claim is made that hardware random number generators
>> "require" a statistical test. Actually this is exactly incorrect. A
>> cryptographically strong random number generator will produce each number
>> series with equal probability, testing for "randomness" (which cannot be
>> tested for) serves no purpose. In fact it is far more necessary for the
>> "chaotic" generators to be tested than for the hardware. Your claim is
>> exactly backwards.
>>
>
>
> My claim is based on research of hardware generators and their physical
> make-up.

Then continue your research, so far it's been heavily flawed.

>
> They require constant testing to assure they are working properly
> because they are delicate components. They physically break or become
> flawed easily.

Actually they are surprisingly resilient, as a demonstration I have actually
mocked up a functional resistor based tRNG and to show it's durability I
threw it against the wall. For reference this is the same basic technology
that is used in VIA processors to generate strong random numbers. They are
extremely resilient.

> So, you must have real-time testing or they can produce.

I will simply let that statement stand exactly as is.

> The following quote comes from Wikipedia, but you can check it using
> more authoritative sources:
>
> "It is very easy to misconstruct devices that generate random numbers.

That much is true, they are easy to build badly, but good designs are also
available for free.

> Also, they break silently, often producing decreasingly random numbers
> as they degrade. An example might be the rapidly decreasing
> radioactivity of the smoke alarms mentioned earlier. As the radioactive
> intensity decreases, its sensor will be required to compensate, not an
> easily accomplished task. Failure modes in such devices are plentiful
> and are neither easy nor quick nor cheap to detect.

Which is why most of the world has stepped away from radioactive decay to
resistor variance, lavalamps, diode noise, etc.

>> Page 3 has a gross error, immediately signalling that your program is
>> snake-oil. "Algorithm . . . does not alter them mathematically" is
>> completely false, and algorithm is a mathematical construct, in fact a
>> computer is a limited physical instantiation of a mathematical construct
>> called a Turing machine. Anything that a computer can do is math.
>>
>
> What I'm saying is that the last random number is not used in a
> mathematical operation to directly produce the next number.
>
> The successive random numbers are not mathematical equations involving
> the last random number.
>
> The last random number is used to determine order of searching but is
> not "mixed" with other numbers, the equation of which is the new random
> number.

You obviously still don't understand math, you're doing math, your system
relies on math, butyou somehow believe that it doesn't.

>> "encryption systems included in web browsers carry a private security key
>> used for encrypting and decrypting messages that carry the session key
>> and
>> digital signature"
>>
>> is generally false. The browser generally does not have a private key of
>> it's own, instead when using SSL or TLS it is the _server_ that has a
>> private key which is used to negotiate a set of symmetric keys. As such
>> the
>> privacy requires are time constrained, something that your system does
>> not
>> have.
>>
>>
>
> I discuss this in the second article. You are correct. I am
> referring to an ideal situation. The current situation is much worse
> than the ideal situation.

You forgot a few words, that should read "You are correct. I am referring
to an ideal situation [for me]. The current situation is much worse than
the ideal situation [for me]."

The current situation is very different from what you seem to believe, I
suggest a bit of research, simply reading the RFCs for SSL and TLS should
suffice for showing you how completely flawed your idea is.

> In the current situation, your message travels unencrypted at two
> points from each server.

The current situation is that encrypted traffic comes out of the USB port on
my computer, travels over Wi-Fi still encrypted, through a router still
encrypted, through a number of routers on the internet still encrypted, to
the final destination server still encrypted, the destination server
decrypts it. Get used to the concept that the flaws you're addressing do not
exist.

>> "The current system uses many hardware generators to produce seeds live
>> in
>> near real time. These generators by their nature are fragile and can
>> completely fail or break and continue to operate but producing flawed
>> seeds."
>>
>> Completely false. The current system collects entropy, using sound
>> cryptographic constructs to distill proper random numbers, the only way
>> this
>> system will fail is if the system CPU fails, if the system CPU fails
>> there
>> are more important usability concerns.
>>
>
> I am referring to the production of seeds here.

So am I. The current system bears no resemblance to your made up design. For
someone who claims to have done research into RNG systems (see above) you
really don't have any understanding of them.

>
> My references tell me that hardware generators are preferred for
> generating seeds.

That would be correct. Hardware generators are preferred, finally something
that is actually true.

>
> What to you mean by "collects entropy?" A seed file mixed with various
> input from the keyboard, mouse, etc.?

For someone who has "researched" RNG systems you don't have any idea about
even the foundations. Entropy in physics is the tendancy of any experiment
to decay to random, entropy in mathematics is random data in it's purest
form. Because of the nature of the term "random" it can refer to
computational complexity of a result, as well as the step-child of entropy.
Using the term entropy specifically refers to randomness that has not been
sampled and is truly random in it's nature. More broadly an event is random,
the resulting data has some entropy. Seed files are now pretty much extinct,
this is because with our modern understanding of how to collect entropy we
can collect it pretty much as fast as we can put it into our mixing source.

>> Page 4 you claim "PRNGs will produce the same number over and over if
>> broken
>> hardware is spitting out the same seed." This is entirely false, have a
>> look
>> at the design of /dev/random and /dev/urandom these are simple designs
>> that
>> represent some of the best actually secure designs in existance. Just to
>> summarize them for you the part that you will have great difficulty
>> breaking
>> look about like:
>>
>> int getRandom()
>>
>> {
>>
>> SHA1_update(globalPool, "1");
>>
>> localPool = SHA1_duplicate(globalPool);
>>
>> return SHA1_final(localPool);
>>
>
>
> Well, it's not "entirely false." It is true with most PRNGs.

It is false with every pRNG I can think of all the way down to the rand()
function in C if you grab another random number from it, the new number will
be different from the last even though no new entropy was collected, and no
new seed was introduced. For someone who claims to have "researched" RNG
systems you really don't understand them very well.

> You
> could look at the system above though as having two seeds.

Actually you cannot. There is one source of entropy (globalPool) everything
else is entirely deterministic containing no entropy, so there is no second
seed. Apparently you can't understand pseudocode either, either that or your
really don't understand pRNGs, which would go right back to that research
statement I keep making.

> The question is where are both seeds coming from. I'm guessing the
> second seed is encrypted output or something going on in the computer.

Well the first and only seed is the globalPool, the localPool which I'm
assuming you are mistaking for the second seed is just a temporary copy of
globalPool to generate output, that should've been pretty clear in the
pseudocode, you might try actually doing research on pRNG systems, I'd
suggest starting with /dev/random.

>> "Most ordinary computers used in the home or office do not have hardware
>> generators" again, false. The computer components themselves form a solid
>> foundation for entropy that is collected properly, just to prove this for
>> yourself write a small program that counts from 1 to 0 (increment only,
>> no
>> decrement) in a 32-bit number a few thousand times, this should take
>> about
>> an hour, check how long it takes, now repeat the process, you will see
>> that
>> the amount of time changed by a small but easily measured amount.
>>
>
> Ok, I'm referring to hardware generators in the normal sense as special
> products. I think that is rather obvious.

Ok then you have no idea about entropy and how to collect it. It is actually
better to reuse a component that is used for something else because the
other operations might induce some degree of entropy as well.

> You can use input from the computer for entropy. For example, computer
> time, mouse input, streams, etc. The problem is showing that this type
> of input is statistically random and unpredictable.

Quite the opposite, you do not have to show that these are statistically
random, you have to show that these have entropy, a concept that your math
skills apparently haven't grasped yet, might I suggest looking it up. From
there you use functions to distill the entropy out (e.g. a cryptographic
hash function) which results in a random pool which can then be processed ad
infinitum as long as the entropy is allowed to continue flowing into the
pool. It is completely unnecessary to "show" unpredictability, Shannon did
this well enough for the English language showing that the average character
has 1-1.5 bits of entropy so simply running 160 characters of English
through SHA-1 will deliver a 160-bit pure random seed (excluding a small
amount for flaws in SHA-1). This is modern pRNG design, get used to it, your
algorithm is havily flawed, your knowledge is only complete to about 1896
and it's now 2005.

>> The algorithm described on pages 4 and 5 is horribly slow and actually
>> quite
>> vulnerable to tampering, but assuming that the 4 secret values, including
>> 1
>> that is pointless (the substitution table) and one that is huge (the
>> file)
>> it appears that it should be secure. The speed penalty comes from the
>> fact
>> that this is on a hard disk. Current hard disk protocol generally operate
>> at
>> 150Mbits/sec (SATA) or about 20 MB/sec, with seek times in the 7ms range.
>> So
>> performing the 5 reads necessary in the example algorithm results in a
>> delay
>> of 45ms per byte (I'm extending your algorithm to bytes because you're
>> wasting far too much space) or about 22 bytes per second, compare this to
>> Panama at 400MB/sec, or RC4 at about 90MB/sec, or AES in CTR mode at
>> 50MB/sec, and the speed failings of your design become very clear. That
>> comparison is rather unfair because generally the entire block containing
>> the information will be read at once, so instead we have 6 pipeline
>> stalls,
>> and 5 memory reads by my count, I will for simplicity assume that none of
>> this is directly from cache which in the given example would have sped
>> things up by about 10%, but that leaves us with a Pentium 4 having a
>> delay
>> of in the neighborhood of 120 cycles per byte, or about 33MB/sec, still
>> half
>> of AES.
>>
>>
>
> The speed difference here is trivial. I've tested it in limited
> trials.

Speed difference is never trivial when comparing algorithms. Your security
is lower, in order to be considered on par you have to be enormously faster
than anyone else, see Adler-32 for an example, it is clearly very weak, but
it has it's uses because of it's speed.

>> Now that a real algorithm has been proposed how about a bit of a security
>> comparison. I will directly compare 256-bit AES in CTR mode with yours,
>> since this is the slowest of the above I'm sure you won't mind too much,
>> even though it's still double the speed. With the file a one time
>> compromise
>> will compromise the entire system past present and future. with no chance
>> of
>> recovery. With AES in CTR mode generally the key is regenerated at
>> regular
>> intervals so a one time compromise is temporaly limited. With AES in CTR
>> mode we can dependably generate in the neighborhood of 268 million
>> terabytes
>> without rekeying with the proposed algorithm the limit is 10MB, I believe
>> there is a substantial difference there. As far as cryptanalytic
>> security,
>> 256-bit AES requires 2^256 work to break, quick examination says that
>> yours
>> should offer 2^90 security requiring in the neighborhood of 2^90 work to
>> break.
>>
>
> What key size are you assuming for my system?

That estimate was based on observing the similarities between your system
and RC4 and scaling the attacks between the two, I was assuming a 100KB
file, but 100MB would still only make a few bits difference.

Are you referring to
> the authentication phase of the encryption?

I was referring to the pRNG that we've been discussing and that the file was
about, do try to keep up.

>> > Manansala Encryption and Authentication System (MEAS)
>> > http://addr.com/~apu/encrypt.pdf
>>
>> Lets just begin on page 1, the entire page is complete bullshit, having
>> absolutely nothing to do with what you are discussing. The first half of
>> page 2 is not only a continuation but also represents a complete
>> misunderstanding of computation, and beyond misunderstanding of
>> cryptography. Now on to some of the parts I can verifiably refute
>> "Fly-by-night phishing and hacking operations can set up multiple
>> encrypted
>> sites remotely through the internet and often paying by regular mail."
>> fly
>> by night phishing no longer works, these are by all accounts now done
>> with
>> sophisticated networks. Paying through regular mail simply does not
>> happen,
>> payment is rendered through electronic means to eliminate a paper trail.
>
> What I meant to say is that accounts can be opened by paying through to
> regular mail.

Which would not be phishing, which is why I said your first two pages are
complete bullshit.

> I know because I have internet web accounts that are payed through
> regular mail.

Good for you, that still wouldn't be phishing.

>> "Most computers do not actually encrypt messages. They send them to their
>> ISPs for encryption." Completely false. Absolutely, completely utterly
>> false. The truth is that the computer you are at does the encryption.
>>
>
> Now, you're contradicting what you said previously.

Please indicate where I said that, in fact everything before this was about
the pRNG which was all done on the local system, and the encryption
mentioned before was all about the pRNG and done on the local system, even
the encryption discussed before was, guess what, done on the local system,
my statements never included a server except as the other end of the
communication. I will simply assume that you are, as usual, completely
incorrect.

>> "The mathematical problems in solving the RSA algorithm can weight down
>> PDAs
>> and cell phones with small memories and processing ability" yeah it slows
>> them down to a dismal rate of faster than their network connection. The
>> next
>> statement about the servers is as before exactly incorrect.
>>
>
> There is absolutely no doubt that RSA is a slow algorithm.

In your mind that has little to do with reality, maybe there is no doubt.
Here in reality modern PDAs and cellphones do 1024-bit RSA in about 1/4
second and they do it all in the cache memory of the cpu. Your statement is
false. The actual speeds available to a PDA or cellphone are above that of
the 3G network available to them. Sorry, but actual knowledge will always do
better than fake research.

>
>>
>>
>> "Private keys are kept on internet servers." Wrong. Private keys for
>> individuals are kept on a PC hard drive
>
> On an internet server.

Ok, so PGP doesn't exist, and you obviously haven't actually read the
specification for SSL or TLS. You are showing yourself to have no knowledge
of the subject, and worse you refuse to gather any knowledge, the first is
forgivable, the latter never.

>> Next clear problem. Apparently the "message and authentication code [are]
>> a
>> random string" if they are random they do not serve their purpose so this
>> clearly must be false.
>
> They indeed serve the purpose of authentication. How does a hacker
> reproduce the random string in encrypted form without the correct key?

That was not what I said. I said you cannot verify a random string. That is
a simple matter. Allow me to go back before most of us were born to show you
why. Under the entropy-based proof of the OTP, a random string will function
perfectly as a OTP, since there is additional entropy contained in the
system the entropy overflows, so a random string cannot be verified and the
hacker could just as easily substitute his own complete garbage random
string.

>> And "Without a properly encrypted page, the merchant''s credit card
>> verifying agency decryption procedure will render a hacker message into
>> meaningless clutter." Just for the record wouldn't that be a "random
>> string"
>> just like was created in the first place, you really don't seem to be
>> making
>> much progress, but you are clearly trying to make a lot of noise.
>>
>
> The merchant sends (and records) a randomly-generated authentication
> code.

Ok, now we're making progress, now instead of trusting the card issuer
(which we have to trust anyway) we now trust the merchant, I suggest adding
the 3D-Secure specifications to your reading list, or actually even the SET
materials should suffice.

> If the purchaser sends back the code in the same form and with the same
> headers, authentication is complete.

So basically there is no actual authentication involved, and we trust the
merchant, and we trust the hacker, and we trust everyone else. This does not
seem like a good idea to me.

> What are the possibilities of guessing a (minimum) 192 bit
> authentication code?

More importantly what are the possibilities that your system is so heavily
flawed that I could write 500 pages on all the attacks against it? The truth
is that even with the major lack of information you have given the entire
security has crumbled in under 30 minutes of my time, this means very simply
that your system is horribly designed and that you do not have the level of
knowledge necessary to make a good system
                Joe
Received on Thu Sep 29 21:44:33 2005