comp.lang.ada
 help / color / mirror / Atom feed
From: Austin Obyrne <austin.obyrne@hotmail.com>
Subject: Re: Problem Cross - Posted fron  Sci Crypt Crypto Group
Date: Mon, 5 Nov 2018 08:03:49 -0800 (PST)
Date: 2018-11-05T08:03:49-08:00	[thread overview]
Message-ID: <15b1f501-28ab-4430-be7d-32f8f15fbf05@googlegroups.com> (raw)
In-Reply-To: <lyh8gwaqc9.fsf@pushface.org>

On Monday, November 5, 2018 at 8:19:52 AM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes:
> 
> > Having thought it through again for the umpteenth time I realise now
> > that my problem is to do with integer overflow i.e. integers greater
> > than 2^31.  I am using 32-bit computer architecture.
> 
> Not sure whether so old a compiler would support declaring 64-bit
> integer as
> 
>    subtype Austins_Integer is Long_Long_Integer;
> 
> or possibly, to make it more explicit,
> 
>    type Austins_Integer is range -2 ** 63 .. 2 ** 63 - 1;

Hi again Simon,

I think I would like to become familiar with 64-bit working as a useful tool but for my present needs what I have is OK. I am able to create totally intractable ciphertext on the back of using plane geometry and vector arithmetic combinations.

A point to be taken into account is the ciphetext-to-plaintext expansion ratio and the effect this has on transmission costs to the secure comunications industry so that larger integer overflow capacity as you outline is not that important.

My personal attitude is security at all costs and I am not very sympathic to that side of things but I must try however to reduce the size of the ciphertext items i.e. the size of the coefficients of the physical vectors that are the transformations of the plaintext items into ciphertext.

I think I am on track now to achieving the ploy of scrambling the ciphertext as de rigueur practice in the industry.  This makes it possible to discontinue my present modus operandi of using a change-of-origin that is given as an addition to the computed ciphertext in order to make it intracable.  That unfortunataely causes quite large ciphertext expansion which as I say is expensive.


Scrambled ciphertext makes it easier to obfuscate the plaintext and even the most benign are made very strong - no need for highly sophisticated glamourised algorithms any more.

Many thanks again for your help.

Austin. 

      reply	other threads:[~2018-11-05 16:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-04 12:57 Problem Cross - Posted fron Sci Crypt Crypto Group Austin Obyrne
2018-11-04 15:27 ` Simon Wright
2018-11-04 15:37   ` Austin Obyrne
2018-11-05  6:40   ` Austin Obyrne
2018-11-05  8:19     ` Simon Wright
2018-11-05 16:03       ` Austin Obyrne [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox