Re: New Encryption Idea

a.manansala_at_attbi.com
Date: 06/17/05 

Date: 17 Jun 2005 06:20:31 -0700

Joseph Ashwood wrote:
> Please understand that I will now proceed to generally rip the concept into
> small pieces, if the small pieces are good the result is good, however since
>

Well, despite your attitude, I appreciate your comments. At least
they're constructive.

>
> <a.manansala@attbi.com> wrote in message
> news:1118940829.475927.232590@g14g2000cwa.googlegroups.com...
> > Manansala Random Number Generator (MRNG)
> > https://www29.addr.com/~apu/cgi-bin/triman.pl?random
> "By that time, they would have likely loaded new browser versions or
> purchased new computers replacing the old file anyway." (page 2 2/3 of the
> way day)
> very much conflicts with:
>
> "they both come in the same box with the program" message to sci.crypt
> 6/16/2005 by a.manansala@attbi.com.
>
>
>
> The downloaded with a browser or on a new computer are far from secure.
> Downloaded versions require that you protect the data in transit to avoid
> being read, this is a bootstrapping problem. The new computer problem is
> that computer boxes are routinely opened at various points for inspection,
> and as such are subject to complete inspection destroying the security of
> this.
>

As I noted, secrecy is a problem with any encryption or security
system.

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

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

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

>
>
> 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.

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

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.

AES uses only 16 and 24 byte keys.

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

>
>
> 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.

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)

>
>
> 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.

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

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

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.
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.

"Because they are quite fragile, and fail silently, statistical tests
on their output should be performed continuously. Many such devices
include some such tests into the software that reads the device.
Others, of course, don't.

"Just as with other components of a cryptosystem, a software random
number generator should be designed to resist certain attacks. See:
random number generator attack. Defending against these attacks is
difficult.

"Checking the performance of hardware random number generators
Hardware random number generators should be constantly monitored for
proper operation. RFC 1750 and FIPS Pub 140-2 include such tests. Also
see the documentation for cryptlib. Statistical tests can detect
failure of a noise source, or a radios station transmitting on a
channel thought to be empty, for example. Ideally data should be
sampled for testing before it is passed through a "whitener." This
allows better verification of the underlying noise generation.
Detecting some deviation from perfection would be a sign that a true
noise source is being tested. Correlation of bias with other parameters
such as internal temperature of bus voltage would be a further check."

>
>
> Top of page 3 has a typo, should that be a period then capitalized or a
> comma, neither makes sense.
>

Thanks for the correction. The algorithm uses a randomly-generated
file, a random starting point and a random "seed" number.

> 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.

>
>
> "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.

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

>
> "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.

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

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

>
>
> 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. You
could look at the system above though as having two seeds.

One is the normal seed, and the other is the seed that mixes up the
pool.

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.

>
> "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.

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.

>
>
> 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.

The real speed delays come from RSA and prime number modular arimethic
not the encipherment program including this one.

>
>
>
> 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? Are you referring to
the authentication phase of the encryption?

> >
> > 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.

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

> "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.

>
> "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.

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

On an internet server.

>

> 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?

>
> 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.

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

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

You seem to take this whole thing rather emotionally, so I won't bother
you anymore, but you did not raise any valid concerns.

Basically, you have not read the articles closely enough to understand
how the systems acutally work.

Relevant Pages

  • Re: computers cannot generate random numbers?
    ... computer-controlled slot machine couldn't generate random ... They love to hang these hardware generators off serial ports. ... to use as a random event. ... most computer seeds are normally generated from the built in ...
    (alt.comp.hardware.pc-homebuilt)
  • Re: Speaking of Overtones...
    ... also mentions noise as a generator. ... sine, triangle, square, sawtooth, rounded square, noise, and one can get one more by deforming the square into rectangular or pulse. ... Then there is a problem with the hardware coping with it. ... Even the computer program ChucK, which computes it digitally on the fly, quickly chokes if has a lot of generators; this method requires a fast computer. ...
    (rec.music.theory)
  • Re: Twin T Notch Anomaly
    ... The THD of the generator ... I havea web page on which I have measured six different generators, ... Using encryption sofware, which prevents the contents ... Linux cannot open encrypted pages. ...
    (rec.audio.tubes)
  • Re: Is Fax Dead Yet?
    ... some of these generators lack the ability to ... series of pseudo-random numbers each time the program is run. ... An opponent may be able to break such an encryption ... This is *not* a true one-time pad, ...
    (sci.electronics.design)
  • Re: Is Fax Dead Yet?
    ... based "random number generators" are pseudo-random... ... An opponent may be able to break such an encryption ... This is *not* a true one-time pad, ... The problem is proving even the randomness of noise. ...
    (sci.electronics.design)