Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Funny Thing About Number-Theoretic Vector Ciphertext .
15 views
Skip to first unread message
adacrypt
Feb 8, 2012, 7:45:10 AM2/8/12
to
Ciphertext that has been generated using random keysets as I do in
this new displacement cryptography is secured against all attacks in
several ways. The attack I have in mind here is when an external
statistical attack is made on the ciphertext string on the basis of
frequency of occurrence of the elements of the string that might
enable probabilistic mapping of the ciphertext directly to plaintext
(as message text) thus successfully circumventing the proper
decryption algorithm by an illegal cryptanalyst.
I’m speaking of vector ciphertext here that has three columns of non-
zero integers that may contain elements that may be variously positive
or negative.
Usually ciphertext strings in any form are usually not random (i.e.
having equal probability) albeit created using internal random keysets
that make them secure against other more direct attack there is always
the chance therefore of external attack by Eve hoping that there is
sufficient discernable giveaway correlations in the frequency of the
ciphertext elements that might enable a Kasiski-Babbage style attack
on the ciphertext, using frequency as the basis of a statistical
mapping operation.
Random ciphertext here means the elements of the ciphertext string
having equal probability and supposing the ciphertext string to be
considered as a keyset itself in some attack such as the one I
described above i.e. a statistical attack.
With this in mind I have been conducting experiments on finding the
frequency of large ciphertext strings of numeric ciphertext via the
three column vector coefficients of (i, j, k) using a file of
encrypted 10852 alphanumeric characters that comprise the ciphertext
i.e. the ciphertext that emanates when this file of plaintext is
encrypted into the number-theoretic ciphertext. I am seeking to
secure that back door from ever being opened by Eve.
The experiment is still ongoing but one interesting result is this
(might be obvious to many readers), the larger the integers involved
as coefficients of (i, j, k) in the ciphertext the nearer the
ciphertext string gets to becoming truly random and of course stronger
in resisting statistical attack.
I must explain here that I rate anything less than 100% truly random
as the inferior pseudo random type – that latter level is not
acceptable as true random quality keys for ‘internal’ encryption but
as an external property of ciphertext it is very welcome when it is up
in the 95% level – virtually random you might say in the context of
being external and not as crucially important as the internal
encryption keysets. It is possible to make it totally random however
i.e. 100% truly random but the law of diminishing returns comes into
effect then because the volume of the enchanced cipher text becomes
very great by comparison with AES for instance and it becomes
expensive to process secured information then by vector means.
I have no hesitation meanwhile in saying that “Displacement
Cryptography” implemented by vector means can be summarised as being
demonstrated as rock solid on all fronts.
A down side of displacement cryptography is of course the very large
ciphertext expansion ratio - that may have to be seen as a price to be
paid for cryptography that is both theoretically unbreakable and
immune to computer power for all time
More later as it evolves.
- adacrypt
this new displacement cryptography is secured against all attacks in
several ways. The attack I have in mind here is when an external
statistical attack is made on the ciphertext string on the basis of
frequency of occurrence of the elements of the string that might
enable probabilistic mapping of the ciphertext directly to plaintext
(as message text) thus successfully circumventing the proper
decryption algorithm by an illegal cryptanalyst.
I’m speaking of vector ciphertext here that has three columns of non-
zero integers that may contain elements that may be variously positive
or negative.
Usually ciphertext strings in any form are usually not random (i.e.
having equal probability) albeit created using internal random keysets
that make them secure against other more direct attack there is always
the chance therefore of external attack by Eve hoping that there is
sufficient discernable giveaway correlations in the frequency of the
ciphertext elements that might enable a Kasiski-Babbage style attack
on the ciphertext, using frequency as the basis of a statistical
mapping operation.
Random ciphertext here means the elements of the ciphertext string
having equal probability and supposing the ciphertext string to be
considered as a keyset itself in some attack such as the one I
described above i.e. a statistical attack.
With this in mind I have been conducting experiments on finding the
frequency of large ciphertext strings of numeric ciphertext via the
three column vector coefficients of (i, j, k) using a file of
encrypted 10852 alphanumeric characters that comprise the ciphertext
i.e. the ciphertext that emanates when this file of plaintext is
encrypted into the number-theoretic ciphertext. I am seeking to
secure that back door from ever being opened by Eve.
The experiment is still ongoing but one interesting result is this
(might be obvious to many readers), the larger the integers involved
as coefficients of (i, j, k) in the ciphertext the nearer the
ciphertext string gets to becoming truly random and of course stronger
in resisting statistical attack.
I must explain here that I rate anything less than 100% truly random
as the inferior pseudo random type – that latter level is not
acceptable as true random quality keys for ‘internal’ encryption but
as an external property of ciphertext it is very welcome when it is up
in the 95% level – virtually random you might say in the context of
being external and not as crucially important as the internal
encryption keysets. It is possible to make it totally random however
i.e. 100% truly random but the law of diminishing returns comes into
effect then because the volume of the enchanced cipher text becomes
very great by comparison with AES for instance and it becomes
expensive to process secured information then by vector means.
I have no hesitation meanwhile in saying that “Displacement
Cryptography” implemented by vector means can be summarised as being
demonstrated as rock solid on all fronts.
A down side of displacement cryptography is of course the very large
ciphertext expansion ratio - that may have to be seen as a price to be
paid for cryptography that is both theoretically unbreakable and
immune to computer power for all time
More later as it evolves.
- adacrypt
Bruce Stephens
Feb 8, 2012, 7:51:40 AM2/8/12
to
adacrypt <austin...@hotmail.com> writes:
[...]
> A down side of displacement cryptography is of course the very large
> ciphertext expansion ratio - that may have to be seen as a price to be
> paid for cryptography that is both theoretically unbreakable and
> immune to computer power for all time
So it's still useless, then, since OTP requires no expansion and has
perfectly security?
[...]
> A down side of displacement cryptography is of course the very large
> ciphertext expansion ratio - that may have to be seen as a price to be
> paid for cryptography that is both theoretically unbreakable and
> immune to computer power for all time
perfectly security?
adacrypt
Feb 8, 2012, 8:54:30 AM2/8/12
to
This is the frequency spread of the cipher results to hand. The
experiment was totally unrehearsed and unbiased.
10852 characters were encrypted
9181 no repeats of numbers as ciphertext => 9181 = 84.6 % random
746 numbers as ciphertext repeated once => 1492 = 13 .7 % random
57 numbers as ciphertext repeated twice => 114 = 1 % random
2 numbers as ciphertext repeated three times => 4 = 0
Clearly, this data would be worthless to any adversary as a means of
statistical attack on the ciphertext. Alice could even hand the
ciphertext to Eve outrightly and be assured that It cannot be broken.
- adacrypt
adacrypt
Feb 8, 2012, 10:37:24 AM2/8/12
to
On Feb 8, 12:45 pm, adacrypt <austin.oby...@hotmail.com> wrote:
I took advice from members of the group “Comp.lang.ada” - re
“dynamically allocating memory and de-allocation” in overcoming a
problem that limited my previous results.
Having run the experiment again without changing anything and without
any tampering I can verify now that the (pseudo) randomness of any
ciphertext (over and above the cipher randomness imparted by the
encryption keys internally) that will use this cryptography is 94% of
true randomness. This is a result that was not easily available to me
previously because of limitations.
This result is sustainable at any time in the future.
This is a good result of this experiment and I am impressed with the
performance.
I commend it to the readership.
- adacrypt
Mark Murray
Feb 8, 2012, 1:42:58 PM2/8/12
to
On 08/02/2012 15:37, adacrypt wrote:
> Having run the experiment again without changing anything and without
> any tampering I can verify now that the (pseudo) randomness of any
> ciphertext (over and above the cipher randomness imparted by the
> encryption keys internally) that will use this cryptography is 94% of
> true randomness. This is a result that was not easily available to me
> previously because of limitations.
>
> This result is sustainable at any time in the future.
>
> This is a good result of this experiment and I am impressed with the
> performance.
Try this on; the cipher is one-to-many. A particular plaintext P(a)
> Having run the experiment again without changing anything and without
> any tampering I can verify now that the (pseudo) randomness of any
> ciphertext (over and above the cipher randomness imparted by the
> encryption keys internally) that will use this cryptography is 94% of
> true randomness. This is a result that was not easily available to me
> previously because of limitations.
>
> This result is sustainable at any time in the future.
>
> This is a good result of this experiment and I am impressed with the
> performance.
character will be transformed into one of a set of triples in C(a).
This set of triples C(a) is unique to P(a), so it is possible to
construct a dictionary of C(a) -> P(a) for all a. The dictionary
an no more than an annoyance to create, and currently inefficient
to run as I am using pretty basic scripting tools and linear searches
to prove the concept.
The use of the large "vector" triples is what introduced this weakness.
I discovered this by enciphering 16Mi of one character and looking for
duplicates, and noticing that a MUCH smaller number of triples was
multiply reused.
This cipher is _busted_.
Do you even know you have a bug in your constant tables? Looks like
a silly typo. One of the change-of-origin tables has a mistake in it
that results in the entry being zero. And this has been copied around a
bit. How much care/thought went into those numbers?
M
--
Mark "No Nickname" Murray
Notable nebbish, extreme generalist.
Mark Murray
Feb 8, 2012, 3:28:24 PM2/8/12
to
On 08/02/2012 18:42, Mark Murray wrote:
> Do you even know you have a bug in your constant tables? Looks like
> a silly typo. One of the change-of-origin tables has a mistake in it
> that results in the entry being zero. And this has been copied around a
> bit. How much care/thought went into those numbers?
While you are there; there is code that does _nothing_ in a few places.
> Do you even know you have a bug in your constant tables? Looks like
> a silly typo. One of the change-of-origin tables has a mistake in it
> that results in the entry being zero. And this has been copied around a
> bit. How much care/thought went into those numbers?
(Except perhaps slow down proceedings)
Functions that return a constant given an index can comfortably be
rewritten as arrays (with a VERY measurable increase in speed).
Storing the cipher/plaintext for later regurtitation serves only
to limit the message size.
Review all your variable use; you have no consistent use of local
vs global usage, and this could significantly simplify your code.
Use variable names that make sense; your current lot are bizarre.
Abstract properly; Ada can "do" vectors; let it!
I've made local changes to your code to understand it and speed
it up; my version runs WAAAAAAY faster than yours, and has the same
result.
adacrypt
Feb 8, 2012, 9:38:54 PM2/8/12
to
On Feb 8, 12:45 pm, adacrypt <austin.oby...@hotmail.com> wrote:
It is quite feasible to adjust the randomness of this crypto to
something in excess of 98.6 % truly random.
This is realised as 10695 non-repeated elements of the ciphertext from
a file of 10852 encrypted characters. The demonstration can be
repeated at will here.
There is nothing to be gained by trying to achieve a better result
than this.
It is achieved by simply tweaking a particular one of the variables in
the source code of the cipher program.
It is being mentioned here as being of crypto interest for future
before drawing a line under the matter of further experiments along
these lines altogether.
It does mean however that it can be demanded as normal now to expect
random ciphertext in the future as standard i.e. the external
ciphertext can be made a random string having equal probability by
every element while having been generated by internally random keys
itself, i.e. at source in the encryption program. That counters a
particular attack on the ciphertext by statistical cryptanalysis in
future, it may be called another milestone in the advance of
cryptology.
- adacrypt
Mark Murray
Feb 9, 2012, 2:17:34 AM2/9/12
to
On 09/02/2012 02:38, adacrypt wrote:
> Supplement 3) to “A Funny Thing ….”
>
> It is quite feasible to adjust the randomness of this crypto to
> something in excess of 98.6 % truly random.
Turd-painting.
> Supplement 3) to “A Funny Thing ….”
>
> It is quite feasible to adjust the randomness of this crypto to
> something in excess of 98.6 % truly random.
> This is realised as 10695 non-repeated elements of the ciphertext from
> a file of 10852 encrypted characters. The demonstration can be
> repeated at will here.
plaintext chararcter is large (high 100000's). At the low statistics
that you are using, the output wil OF COURSE look random, and OF COURSE
you can tweek, this, but unit you address the base problem that I know
what each image set has as an origin, your cipher is no more than
an annoyance to crack.
> There is nothing to be gained by trying to achieve a better result
> than this.
> It is achieved by simply tweaking a particular one of the variables in
> the source code of the cipher program.
"b" have equal probability of enciphering to the SAME output item(s),
this cipher has no chance.
Noob
Feb 9, 2012, 4:52:02 AM2/9/12
to
Mark Murray wrote:
> adacrypt wrote:
>
>> It is quite feasible to adjust the randomness of this crypto
>> to something in excess of 98.6 % truly random.
This "cipher" is 99.44% pure!
http://www.straightdope.com/columns/read/870/ivory-soap-is-99-and-44-100-pure-what
> adacrypt wrote:
>
>> It is quite feasible to adjust the randomness of this crypto
>> to something in excess of 98.6 % truly random.
http://www.straightdope.com/columns/read/870/ivory-soap-is-99-and-44-100-pure-what
David Eather
Feb 9, 2012, 3:22:17 PM2/9/12
to
On Wed, 08 Feb 2012 23:54:30 +1000, adacrypt <austin...@hotmail.com>
wrote:
Um, the German Enigma was what you are calling 96% random - and it was
badly flawed and broken. By your own figures your's is 4 times worse.
--
We have failed to address the fundamental truth that endless growth is
impossible in a finite world.
wrote:
badly flawed and broken. By your own figures your's is 4 times worse.
--
We have failed to address the fundamental truth that endless growth is
impossible in a finite world.
0 new messages