info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
The Benefits of SMD – Cipher Designing
22 views
Skip to first unread message
adacrypt
Nov 9, 2011, 4:22:52 AM11/9/11
to
I think it is pretty safe to say that the concept of synchronised
mutual databases (SMD for short) is here to stay and certain rules can
now be staked out as basic tenets of future cryptography, this comes
as a happy fallout of this invention. I can demonstrate these tenets
sufficiently to warrant stating them axiomatically in the future. I
have incorporated them in recent de facto up-and-running ciphers in
vector cryptography. I have considered if there are better ways of
expressing these rules like say desiderata, criteria etc. but no, the
word is ‘rules’ without any watering down. SMD is my personal
invention.
The rules are,
1) The elements of cipher-text must not be invertible except by the
human intervention of Bob sequentially calling keys from the arrays of
his database as the operands of his decryption algorithm i.e. it must
not be possible to do this by any adversary mathematically mimicking
Bob’s decryption algorithm using some number-theoretic formula. The
encryption transformation by Alice may be described as a one-way
mathematical function. The human intervention is in fact a transfer
of data from a human memory to a computer memory, something that no
computer will ever be able to do on its own (not yet anyway).
2) The elements of cipher-text that comprise the ciphertext string
must be so totally disparate from each other that they lack all
continuity and it must not be possible to make any mathematical
inductive assumptions like say being able to deduce some upstream
element based on knowledge of some nearby downstream element(s) or
vice versa. This defeats differential analysis, linear analysis,
known plaintext attacks etc.
3) The frequency of the ciphertext elements that comprise the
ciphertext string should, as far as possible, have equal probability
of representing any plaintext character in the secret message text it
represents. They should ideally have equal probability or in other
words they should be scientifically random by definition. This defeats
statistical mapping of ciphertext elements to plaintext elements that
would circumvent all proper decryption and destroy the security of a
cipher-text string in the hands of a cryptanalyst. This randomness
should not be confused with the much laboured randomness of encryption
keys – this randomness makes the *ciphertext random so as to foil
being turned into a key itself in the hands of a cryptanalyst and then
used as an improvised decryption key in a statistical attack based on
frequency comparisons with the plaintext of a sample in a known
plaintext attack.
These are powerful stumbling blocks that may be described as being
sufficiently intractable to warrant being outrightly ascribed
“Theoretically Unbreakable Class” to any cipher that possesses them.
It doesn’t have to be vector data either – it applies equally to
scalar data if the cryptographer can deliver (there is one such scalar
cipher in the pipeline).
The ensuing cryptography i.e. emanating from this design philosophy
is immune to threats from increasing computer power forever more, the
cryptography instead actually thrives on increasing computer power.
It is my abiding contention that synchronised mutual databases that
are configurable by scrambling into an unthinkably vast number of
unique encryption set ups may become the most seminal invention in
cryptography that we will ever see. It has already turned the threat
of increasing computer power from being an impending danger into a
welcome blessing instead.
How it works again.
Alice and Bob are the entities of a single one-way secure
communications loop. If Bob wants to communicate with Alice (which is
probably often the case) he becomes an Alice under the same rules.
They set up a loop initially by exchanging identical softwares that
they have customised beforehand. They synchronise their mutual
databases periodically by exchanging scrambling parameters.
It is not necessary for the entities to ever change the arrays of keys
but they can if they wish by mutual arrangement.
This cipher implementation is universal. There is a unique version of
it available in theory for every one of the seven billion inhabitants
of this planet and then some more left over. There is no need to
alter it from its present state but you can if you wish.
- adacrypt
mutual databases (SMD for short) is here to stay and certain rules can
now be staked out as basic tenets of future cryptography, this comes
as a happy fallout of this invention. I can demonstrate these tenets
sufficiently to warrant stating them axiomatically in the future. I
have incorporated them in recent de facto up-and-running ciphers in
vector cryptography. I have considered if there are better ways of
expressing these rules like say desiderata, criteria etc. but no, the
word is ‘rules’ without any watering down. SMD is my personal
invention.
The rules are,
1) The elements of cipher-text must not be invertible except by the
human intervention of Bob sequentially calling keys from the arrays of
his database as the operands of his decryption algorithm i.e. it must
not be possible to do this by any adversary mathematically mimicking
Bob’s decryption algorithm using some number-theoretic formula. The
encryption transformation by Alice may be described as a one-way
mathematical function. The human intervention is in fact a transfer
of data from a human memory to a computer memory, something that no
computer will ever be able to do on its own (not yet anyway).
2) The elements of cipher-text that comprise the ciphertext string
must be so totally disparate from each other that they lack all
continuity and it must not be possible to make any mathematical
inductive assumptions like say being able to deduce some upstream
element based on knowledge of some nearby downstream element(s) or
vice versa. This defeats differential analysis, linear analysis,
known plaintext attacks etc.
3) The frequency of the ciphertext elements that comprise the
ciphertext string should, as far as possible, have equal probability
of representing any plaintext character in the secret message text it
represents. They should ideally have equal probability or in other
words they should be scientifically random by definition. This defeats
statistical mapping of ciphertext elements to plaintext elements that
would circumvent all proper decryption and destroy the security of a
cipher-text string in the hands of a cryptanalyst. This randomness
should not be confused with the much laboured randomness of encryption
keys – this randomness makes the *ciphertext random so as to foil
being turned into a key itself in the hands of a cryptanalyst and then
used as an improvised decryption key in a statistical attack based on
frequency comparisons with the plaintext of a sample in a known
plaintext attack.
These are powerful stumbling blocks that may be described as being
sufficiently intractable to warrant being outrightly ascribed
“Theoretically Unbreakable Class” to any cipher that possesses them.
It doesn’t have to be vector data either – it applies equally to
scalar data if the cryptographer can deliver (there is one such scalar
cipher in the pipeline).
The ensuing cryptography i.e. emanating from this design philosophy
is immune to threats from increasing computer power forever more, the
cryptography instead actually thrives on increasing computer power.
It is my abiding contention that synchronised mutual databases that
are configurable by scrambling into an unthinkably vast number of
unique encryption set ups may become the most seminal invention in
cryptography that we will ever see. It has already turned the threat
of increasing computer power from being an impending danger into a
welcome blessing instead.
How it works again.
Alice and Bob are the entities of a single one-way secure
communications loop. If Bob wants to communicate with Alice (which is
probably often the case) he becomes an Alice under the same rules.
They set up a loop initially by exchanging identical softwares that
they have customised beforehand. They synchronise their mutual
databases periodically by exchanging scrambling parameters.
It is not necessary for the entities to ever change the arrays of keys
but they can if they wish by mutual arrangement.
This cipher implementation is universal. There is a unique version of
it available in theory for every one of the seven billion inhabitants
of this planet and then some more left over. There is no need to
alter it from its present state but you can if you wish.
- adacrypt
Gordon Burditt
Nov 14, 2011, 12:42:31 AM11/14/11
to
> I think it is pretty safe to say that the concept of synchronised
> mutual databases (SMD for short) is here to stay and certain rules can
> now be staked out as basic tenets of future cryptography, this comes
> as a happy fallout of this invention.
I think it is safe to say that your concept of synchronised mutual
> mutual databases (SMD for short) is here to stay and certain rules can
> now be staked out as basic tenets of future cryptography, this comes
> as a happy fallout of this invention.
databases is unspecified and keeps changing at a whim. It is
particularly disturbing that at one point you said that it would
take several weeks to come up with a new database, when apparently
I'm supposed to have a separate database for each person I communicate
with securely.
Please specify what is *IN* a SMD and how to construct one. Are
there "scrambling parameters" in there? What are the rules for
constructing them (how many numbers, what is the valid range of these
numbers, etc.)
> The rules are,
Rules about *CIPHERTEXT* are meaningless to the problem of constructing
a SMD unless you claim that a SMD contains ciphertext, which is
pretty lame, and contradicts a lot about what you have said previously.
> It is not necessary for the entities to ever change the arrays of keys
> but they can if they wish by mutual arrangement.
do.
adacrypt
Nov 14, 2011, 4:45:50 AM11/14/11
to
that are called at boot-up time and loaded into the program onboard
arrays for using instantaneously by the program at run time. Some of
these packages are huge and initially it can take several weeks to
create them by laboriously keying in elements of data with care. Once
they are created they can be passed around by the network users in one-
way secure loops without further changing. The users may make changes
to personalise these large packages by keying in a few changes to the
values put in by me in a few minutes if they wish or they can just let
them stay put since there is no great risk in doing so.
There are scrambling parameters to each database that the entities may
use also to customise their SMD.
Keeping the SMD safe is the only thing required.
If Bob wants to communicate with another person he becomes an Alice,
creates his own personalised database by making a few small changes
(if he wishes but not essentailly so) and delivers an exact copy by
one-off secure means to this other person - and so on.
Gordon - I don't wish to cut you off rudely but I honestly don't want
to continue a long argumentive thread here - I think I have said it
all before - regards - adacrypt
adacrypt
Nov 14, 2011, 5:01:13 AM11/14/11
to
On Nov 14, 5:42 am, gordonb.n7...@burditt.org (Gordon Burditt) wrote:
download - enjoy - adacrypt
adacrypt
Nov 14, 2011, 5:51:45 AM11/14/11
to
>
> - Show quoted text -
SMD makes it possible for any person to come up with a much more
benign cipher algorithm now. I think this is encouraging to
researchers in sci crypt. Up to now it has been a horrendously
difficult pursuit of complexity based on number theory - everybody has
gone down the same tortured path - the more it stings the better the
medicine fallacy it seemed.
It's over! Spring is here - anybody can write an unbreakable cipher
with relative ease now - more than that, its immune to the threat of
increasing computer power for all time - adacrypt
adacrypt
Nov 14, 2011, 6:07:15 AM11/14/11
to
On Nov 14, 10:01 am, adacrypt <austin.oby...@hotmail.com> wrote:
> download - enjoy - adacrypt- Hide quoted text -
>
> - Show quoted text -
The SMD that comes with the download is a universal one - its huge ,
>
> - Show quoted text -
14250 elements - you can create your own if you wish but it won't be
any better unless you are going to use different data types in your
design of cipher you won't need another.
The SMD is like a pack of playing cards, it is passed around and used
over and over again without any diminution of the disparateness of the
elements. - adacrypt
Gordon Burditt
Nov 14, 2011, 9:43:07 AM11/14/11
to
>> > > It is not necessary for the entities to ever change the arrays of keys
>> > > but they can if they wish by mutual arrangement.
>>
>> > If you wish to retain the property of "theoretically unbreakable", you
>> > do.
>>
>> Also, you don't have to create anything - I've done it for you in the
>> download - enjoy - adacrypt- Hide quoted text -
If you think I can use your cipher by copying the published demo
>> > > but they can if they wish by mutual arrangement.
>>
>> > If you wish to retain the property of "theoretically unbreakable", you
>> > do.
>>
>> Also, you don't have to create anything - I've done it for you in the
>> download - enjoy - adacrypt- Hide quoted text -
key and then making "a few changes" and retain "theoretically
unbreakable" from an enemy who also has a copy of the same demo
key, you need to do some serious re-thinking about how secure it
is. For a short message, I might not even use any of the "a few
changes", and be able to decrypt the message completely with the
demo key. And if a couple of letters come out funny, I can probably
guess the correct ones. Plaintext human languages are funny that
way - plenty of redundancy.
You certainly should expect someone to build a whole new key for
serious use. Not doing so is one of those administrative flaws
that can bite you. Also, breaking your cipher using a key with "a
few changes" from a published demo key doesn't really demonstrate
a flaw in the cipher - it demonstrates seriously stupid keying
policy.
> The SMD that comes with the download is a universal one - its huge ,
> 14250 elements - you can create your own if you wish but it won't be
> any better unless you are going to use different data types in your
> design of cipher you won't need another.
message. (How big is the source code to your cipher?) Even 14250
million elements probably doesn't qualify as huge. It's only a
handful of DVDs.
> The SMD is like a pack of playing cards, it is passed around and used
> over and over again without any diminution of the disparateness of the
> elements. - adacrypt
smart card cheaters will be able to keep track of where all the cards
in the deck are. Some of the better ones can approximately track
cards through a human manual shuffle.
Mark Murray
Nov 14, 2011, 1:09:30 PM11/14/11
to
On 14/11/2011 14:43, Gordon Burditt wrote:
> And if you keep re-using the cards without shuffling them, some very
> smart card cheaters will be able to keep track of where all the cards
> in the deck are. Some of the better ones can approximately track
> cards through a human manual shuffle.
Adacrypt's algorithm involves a fairly naive PRNG to present the numbers
> And if you keep re-using the cards without shuffling them, some very
> smart card cheaters will be able to keep track of where all the cards
> in the deck are. Some of the better ones can approximately track
> cards through a human manual shuffle.
in "scrambled" order. Paolo's attack broke this.
As there are only 14k-odd numbers (yes, they are triples, but each
triple represents a unique value in an R^3 -> R map), the security
is pretty laugable.
I've been sniggering at his notion of having to "carefully key in"
the numerical values. Hasn't he heard of the idea of using a computer
to do this?
M
--
Mark "No Nickname" Murray
Notable nebbish, extreme generalist.
Mark Murray
Nov 14, 2011, 1:12:42 PM11/14/11
to
On 14/11/2011 11:07, adacrypt wrote:
> The SMD that comes with the download is a universal one - its huge ,
> 14250 elements - you can create your own if you wish but it won't be
> any better unless you are going to use different data types in your
> design of cipher you won't need another.
So your previous comments about having folks like Paolo "in your
> The SMD that comes with the download is a universal one - its huge ,
> 14250 elements - you can create your own if you wish but it won't be
> any better unless you are going to use different data types in your
> design of cipher you won't need another.
database" are rubbish? That was the intended use of these numbers?
So what counts for the secret key then?
Mark Murray
Nov 14, 2011, 1:23:37 PM11/14/11
to
On 14/11/2011 09:45, adacrypt wrote:
> My data base is constructed of some 3 or 4 large Ada off-page packages
> that are called at boot-up time and loaded into the program onboard
> arrays for using instantaneously by the program at run time. Some of
> these packages are huge and initially it can take several weeks to
> create them by laboriously keying in elements of data with care. Once
> they are created they can be passed around by the network users in one-
> way secure loops without further changing. The users may make changes
> to personalise these large packages by keying in a few changes to the
> values put in by me in a few minutes if they wish or they can just let
> them stay put since there is no great risk in doing so.
1) So the published database is "good enough".
> My data base is constructed of some 3 or 4 large Ada off-page packages
> that are called at boot-up time and loaded into the program onboard
> arrays for using instantaneously by the program at run time. Some of
> these packages are huge and initially it can take several weeks to
> create them by laboriously keying in elements of data with care. Once
> they are created they can be passed around by the network users in one-
> way secure loops without further changing. The users may make changes
> to personalise these large packages by keying in a few changes to the
> values put in by me in a few minutes if they wish or they can just let
> them stay put since there is no great risk in doing so.
> There are scrambling parameters to each database that the entities may
> use also to customise their SMD.
> Keeping the SMD safe is the only thing required.
> If Bob wants to communicate with another person he becomes an Alice,
> creates his own personalised database by making a few small changes
> (if he wishes but not essentailly so) and delivers an exact copy by
> one-off secure means to this other person - and so on.
"small changes", Bob makes same "small changes". Only the changes
need to be secured, except for the fact that Paolo's attack breaks this.
> Gordon - I don't wish to cut you off rudely but I honestly don't want
> to continue a long argumentive thread here - I think I have said it
> all before - regards - adacrypt
time.
Bruce Stephens
Nov 14, 2011, 1:26:42 PM11/14/11
to
Mark Murray <w.h....@example.com> writes:
[...]
> I've been sniggering at his notion of having to "carefully key in"
> the numerical values. Hasn't he heard of the idea of using a computer
> to do this?
It seems quite possible that he believes it's an essential part of the
process: transferring the numbers from a human brain into the computer.
Without the human brain you'd just be left with computers, and
potentially the algorithms used could be broken. (The fact that humans
are really not good at producing random numbers probably doesn't bother
him.)
(If you really want a laugh, imagine that his comments that using RSA
requires graduates hunched over keyboards because the arithmetic must be
done by hand. I don't know whether he still believes that, but the
evidence suggests that he used to.)
[...]
> I've been sniggering at his notion of having to "carefully key in"
> the numerical values. Hasn't he heard of the idea of using a computer
> to do this?
process: transferring the numbers from a human brain into the computer.
Without the human brain you'd just be left with computers, and
potentially the algorithms used could be broken. (The fact that humans
are really not good at producing random numbers probably doesn't bother
him.)
(If you really want a laugh, imagine that his comments that using RSA
requires graduates hunched over keyboards because the arithmetic must be
done by hand. I don't know whether he still believes that, but the
evidence suggests that he used to.)
Mark Murray
Nov 14, 2011, 1:38:09 PM11/14/11
to
On 14/11/2011 18:26, Bruce Stephens wrote:
> (If you really want a laugh, imagine that his comments that using RSA
> requires graduates hunched over keyboards because the arithmetic must be
> done by hand. I don't know whether he still believes that, but the
> evidence suggests that he used to.)
This doesn't surprise me at all!
> (If you really want a laugh, imagine that his comments that using RSA
> requires graduates hunched over keyboards because the arithmetic must be
> done by hand. I don't know whether he still believes that, but the
> evidence suggests that he used to.)
If you read his program documentation, it involves a description of the
IDE and the GNAT Ada compiler; its clear that he has no idea of the
IDE/Compiler/Source/Application/Data boundaries. At one point, his
"Shared Database" was all of the above :-). In other words, part of
the "secret" includes arbitrary source changes!
Note: He thinks anyone could be taught to use this securely in a few
minutes.
David Eather
Nov 14, 2011, 10:08:37 PM11/14/11
to
make you choke!) He seems totally immune to the fact that his shared
database concept has been invented long before (eg. tri-strata cipher
and Uli Mauer's universal stream cipher - both of those were more
secure, more practical and tri-strata was implemented better with a
meagabyte of shared data - et al) and has no concept or desire to learn
of the strengths and weakness that brings and he can't see that his
hand-waving vector "stuff" adds nothing (as PM's attack shows)
I found a quote yesterday that seems to fit - "You can't win an argument
with an ignorant man"
Does adacrypt ask questions to learn or just to spot rubbish.
0 new messages