Re: New Encryption Idea

From: Joseph Ashwood (ashwood_at_msn.com)
Date: 06/17/05


Date: Fri, 17 Jun 2005 03:49:09 GMT

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
I'm only on page 2 of the rng file and I'm already having serious doubts
most likely the pieces left over will not be all that good.

Also note that while I will make reasonable efforts to keep this
semi-readable it is primarily an accompanying text to the documents and
other comments.

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

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.

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.

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.

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

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.

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

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

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);

}

This will repeat if you draw approximately 2^80 number from it (on average),
and since there is the stirring of entropy into the mix continually the
exact same "seed" can be submitted continually with no adverse effects.

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

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.

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.

So since I've poked holes in the arguments to page 5, proven that the
algorithm is inferior to AES in CTR mode in just about every possible way,
and left the aforementioned little pieces in not such great condition I will
stop the attack in order to accept a reasonable surrender.

>
> 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.
"With the Manansala system all encrypted transmissions can only be decrypted
with prior knowledge of this authenticating information" allow me to
translate "With the Manansala system you can only do business with people
that already know you, but you are free to do business with people you don't
know" and since it allows user to set up their own protocols you can screw
yourself over a million ways before breakfast.

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

As for "The vast majority of computers do not have strong random number
generators needed for cryptography" if you look at the first half of this
message you will see that you are completely wrong as well.

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

"Private keys are kept on internet servers." Wrong. Private keys for
individuals are kept on a PC hard drive (or sometimes on a flash drive) or
smartcard, server ones are often kept on dedicated hardware such as
available from nCipher, Eracom, and SafeNet (formerly Rainbow). And you
continue your completely incorrect assertion about ISPs and private keys.

About the "entered at the beginning of each encrypted session" you seem to
have forgotten that these keys are 100,000 characters long, no user is going
to actually do that.

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. Since the length of the authentication code can be
set by the page creator there appears to be nothing stopping the page
creator from deliberately choosing insecure parameters leading very quickly
back into man-in-the-middle attacks. Not to mention the fact that since we
clearly have to perform the manansala fake-rng both sides clearly must have
the same files which leads quickly to everyone must have the same files
simply in order to make it possible to communicate. Everyone of course
includes the attacker, game over attacker wins.

Page 5 begins with a complete misuse of the term cryptographically.

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.

"No well-established internet security system is proved to be unbreakable."
Except for that pesky One-Time-Pad thingie that's a century old. And the
claim that it is impractical is once again completely incorrect, for
reference take a look at the one time passwords that are used by some banks.

At this point I've grown completely tired of the pointless drivel in the
files. I strongly suggest reading up on actual cryptography, and if you want
to deal with the credit card system I suggest you read up on 3D-Secure which
not only has all the benefits you try to argue your way into, but many, many
more beginning with actual cryptographic knowledge and design behind it.

The Manandbeast algorithms are pointlessly complex, horribly slow, badly
designed, and insecure to boot.

            Joe



Relevant Pages

  • Re: How to pick best encryption algorithm based on application
    ... the optimum encryption algorithms for your particular application. ... severley affected if one algorithm is better at treating a continuous ... AES and other AES contest finalist will be unfeasible to break from a ... we should take in account not only attacks to the algorithm ...
    (sci.crypt)
  • Re: AES 256bit or Blowfish 448bit is better?
    ... Both Algorithms are well respected (although AES ... has been chosen as new encryption standard), ... so its rather pointless whether your encryption algorithm uses ... And, BTW, too much crossposting is another counterexample to the "the more ...
    (comp.security.misc)
  • Re: Virtual Matrix Encryption
    ... Right - it is snake-oil, simply because their algorithm is not ... AES is the standard now, and I have no doubts folks from NSA (or whatever ... die or simply another algorithm will be used in the AES. ... >> We are seeking commercial encryption library for one of our software ...
    (sci.crypt)
  • Re: Popular Cryptography Magazine
    ... The articles include an evaluation of an algorithm, ... Electronic Strata" encrypted with AES using the 128 key of all zeros. ... This encryption step prevents incompetent people from reading the ...
    (sci.crypt)
  • Re: A new encryption software of mine
    ... and zero rigorous analysis or testing. ... the algorithm was designed as an extreme parallel algorithm, ... random data that the programmers who wrote STS assumed that it simply ... this is the *worst* possible thing that could happen to any encryption ...
    (sci.math)