Re: Non-Scalar Cryptography - The Emporor is stark naked.

On May 13, 12:47 pm, rossum <rossu...@xxxxxxxxxxxx> wrote:
On Mon, 12 May 2008 14:00:20 -0700 (PDT), austin.oby...@xxxxxxxxxxxxxx
wrote:

Key management,

In all the computerised ciphers that I refer to as having written,
there is no key transport per se - Alice and Bob have exactly the same
databases of shared information - established at the outset by
unsecured ordinary mail - in my cipher this a keystring (array) of
14000- laboriously keyed-in alphanumeric characters

So we can assume that any attacker has access to the same database of
characters since it is transmitted unsecured.

.  Once this set of keys is established, Alice and Bob liaise by Alice
sending scrambling parameters for the keys array to Bob for each new
message - this ensures the 'once only' bit of OTP rigour.........(1)

So the database is not actually the key as such, the actual key is the
particular permutation of the database that you are using - your
"scrambling parameters".  How many bits are there in these scrambling
parameters?  How easy would it be for an attacker, who has access to a
copy of the database, to brute force the scrambling parameters?

How secure is the scrambling algorithm against an attacker who has
access to the database, the plaintext and the cyphertext - can such an
attacker recover the scrambling parameters?

as well as solving the traditional ket [key?] transport problem ......(2)

How are you transporting the "scrambling parameters"?  Since your
database is unsecured, and hence public, then the scrambling
parameters *are* the key.  The attacker already knows the database.
If the attacker also learns, or can guess, the scrambling parameters
then the cypher is presumably broken.  This is not looking much like
OTP to me.



It simply happens as a convenience in the programming that each
plaintext is enciphered one at a time and the corresponding element of
ciphertext is stored in a growing array of ciphertext such that the
eventual string of ciphertext is numerically equal to the length of
the plain text message - this ensures that piece of OTP rigour....(3)

You may want to allow for padding of messages.  If the attacker knows
that the message is either "yes" or "no" and that the cyphertext is
the same length as the plaintext then the length of the cyphertext
leaks information.

rossum





Finally, and most importantly the randomness of the ciphertext is
argued axiomatically as being of equal uncertainty between the
separate elements of the ciphertext string => equal uncertainty means
equal probably => means randomness by definition.  The argument for
randomness based on equal uncertainty is reinforced by the
alphanumeric character of the ciphertext string => there are no
mechanical methods, lexical ( Babbage / Kasiski style of attack). no
arithmetical methods ( the presence of keys like %, *. ^ $ that are
not arithmetical data pers se), and lastly numerical analysis is foile
d by the same reasoning ie the alphanurmic string of ciphertext is bad
data to each style of attack => the upshot of this reasone randomness.

The cipher can handle a message of any length between 1 and 14000
characters - any longer thatn this measn two blocks as separate pieces
- 14000 characters ios about 5 A4 pages.

Because of the newness of this cipher one has to keep an open mind on
what the industry authorities may think of it and of course be ready
accept whatever they say.

It would be great help if anybody would help out with the Beta -
Testing of the cipher - just running the program and noting anything
that you think needs changing - contact me at :

austin.oby...@xxxxxxxxxxxxx

Thanks - adacrypt.- Hide quoted text -

- Show quoted text -

Each data base of every Alice is a permutation of somebody else's
database ( that is the key domain of that person). It is
particularised by Alice for each Bob she initiates in her network. It
must be kept safe by the Alice in question in every case - this is
reasonable and is a basic requirement of every Alice. Knowing it and
the corresponding scrambling parameters at any time means of course
that the cipher is broken.

Yes the parameters are public - they travel between Alice and as
unsecured data - everything depends on keeping the shared information
secret and safe. This true for all ciphers - adacrypt
.

Relevant Pages

  • Re: Non-Scalar Cryptography - The Emporor is stark naked.
    ... sending scrambling parameters for the keys array to Bob for each new ... particular permutation of the database that you are using - your ... ciphertext is stored in a growing array of ciphertext such that the ... Each data base of every Alice is a permutation of somebody else's ...
    (sci.crypt)
  • Re: Non-Scalar Cryptography - The Emporor is stark naked.
    ... So we can assume that any attacker has access to the same database of ... sending scrambling parameters for the keys array to Bob for each new ... So the database is not actually the key as such, ... ciphertext is stored in a growing array of ciphertext such that the ...
    (sci.crypt)
  • Big Brother Alert! (ndc)
    ... The spy agency would then mine this database to uncover ... just a sliver of the data on individuals that the government could assemble. ... If Alice is on a terrorist watch list, ... do much more than simply find new terrorism suspects; ...
    (rec.music.gdead)
  • Re: What do you think about......?
    ... Alice in NJ, Royal Cybrarian ... :> just posting a message on one of the Yahoo groups I moderate and I ... :> One thing I thought of was putting the Directory in a database. ... One problem I see is that to limit access to the ...
    (rec.crafts.textiles.quilting)
  • Re: Database encryption.
    ... that destroys the functionality of the database. ... > okay with Indexes based on ciphertext. ... In your scheme encryption is one-to-many. ...
    (sci.crypt)