Problem Cross - Posted fron Sci Crypt Crypto Group

Problem Cross - Posted fron Sci Crypt Crypto Group

[Austin Obyrne]

My invention of scrambling of the cipher text as an invincible way of securing it against cryptanalysis has stalled at file sizes of 30000 plaintext items. This isn't bad but I want to go further.

I post here some scrambling extracts from my development work that show that my current programs will work on files up to 30000 items but not on a file of 50000 characters.  I cannot find any reason for this happening and I think there may be something in the Ada language that perhaps sets a latent bound on what I am trying to do. 

1) File size : 30000 items

SliceNum_26  : CONSTANT Integer := 0; --Start point in slice  of a ciphertext string in hand    
StepNum_26   : CONSTANT Integer := 45; -- Upstream placemoves  from A to B in this string     
RepeatsNum_26: CONSTANT Integer := 2099; -- make repeats of placemoves instruction  
  -- scrambling device in ''Load_n_Scramble_CipherTexts'' procedure 
  -- (SliceNum_26 + stepNum_26*RepeatsNum_26 <= Current number of ciphertext items.

There are 94491 items of ciphertext in the largest string in hand on this occasion i.e. 31497 vectors that have 31497 x 3 = 94491 coefficients

My program handles this quite OK - no problem in transposing the elements of ciphertext

When I try to scramble a larger program as follows however I get a " CONSTRAINT ERROR " annunciation.



2) File size : 50000 items.

SliceNum_26  : CONSTANT Integer := 0; --Start point in slice  of the  ciphertext string  in hand    -
StepNum_26   : CONSTANT Integer := 29; --Upstream placemoves  from A to B in this string     
 RepeatsNum_26: CONSTANT Integer := 5179; --repeats of placemoves instruction  
  -- scrambling device in ''Load_n_Scramble_CipherTexts'' procedure 
  -- (SliceNum_26 + stepNum_26*RepeatsNum_26 <= Current number of ciphertext items.

The second program is comprised of 527 repeats of the ASCII set of 95 characters i.e. 50065 characters.  Each character is transformed into a displacement vector that has 3 coefficients so that there are 50065 x 3 = 150195 coefficients that comprise the ciphertext string for scrambling this second time.

The program will not run and I repeat, I get an error message "CONSTRAINT ERROR"

My problem:-

This encryption of what might be a fairly large general office program runs perfectly in another (different) program where it is not required to scramble the ciphertext but crashes when it is asked to do so according to the new scrambling parameters in my desired development(different)scrambling program i.e. the parameters 29 x 5159 that were OK earlier for scrambling seem to be too much for it to scramble now when the parameters are 45 x 2099.

Question:- What is causing this.

I have gone over all of the other coincident possibilities that might cause a constraint error in the scrambling of this larger program and I cannot see anything that might do it.  I am slowly coming to the conclusion that it must be to do with the number of I_O ( IN - OUT) operations that the scrambling operation requires.  Am I exceeding some latent upper bound in the Ada language - alternatively it is unlikely to be computer-related I think ?.

My CS knowledge doesn't go far enough to do any analysis or solution and I would be grateful for more informed help from anybody.

*I am using a very old compiler - Gnat 311.p - and a typical home computer that has Windows 7 operating system,  It has a fairly good processor however.
 
Any help would be appreciated

Comment:

This does not affect the future of scrambling the ciphertext as a future ploy in general cryptography.  It just means that in my present case I seem to be limited to encrypting plaintext files of 30000 in extent only *i.e. if I decide to scramble the ciphertext string after encrypting it.

Austin O'Byrne

Re: Problem Cross - Posted fron Sci Crypt Crypto Group

[Simon Wright]

There doesn't appear to be any group "Sci Crypt Crypto".

It's extraordinarily unlikely that you'd get a constraint error from
I/O.

The most likely reason is that you have an array in your code with
bounds such as 1 .. 100_000 and your code is exceeding these bounds.

But the chance of anyone here being able to help you find out where is
also on the low side, since you haven't posted any code (note, I'm not
inviting you to, since the last time I tried to help you you completely
ignored my suggestions).

You would almost certainly gain from using an up-to-date compiler
(https://www.adacore.com/community).

Even if you won't do that, try compiling with appropriate options:
"gnatmake -g -O0 your_program.adb" will probably give you the line
number where the CE is happening.

Re: Problem Cross - Posted fron Sci Crypt Crypto Group

[Austin Obyrne]

On Sunday, November 4, 2018 at 3:27:28 PM UTC, Simon Wright wrote:
> There doesn't appear to be any group "Sci Crypt Crypto".
> 
> It's extraordinarily unlikely that you'd get a constraint error from
> I/O.
> 
> The most likely reason is that you have an array in your code with
> bounds such as 1 .. 100_000 and your code is exceeding these bounds.
> 
> But the chance of anyone here being able to help you find out where is
> also on the low side, since you haven't posted any code (note, I'm not
> inviting you to, since the last time I tried to help you you completely
> ignored my suggestions).
> 
> You would almost certainly gain from using an up-to-date compiler
> (https://www.adacore.com/community).
> 
> Even if you won't do that, try compiling with appropriate options:
> "gnatmake -g -O0 your_program.adb" will probably give you the line
> number where the CE is happening.

Thanks Simon,

I agree with everything you say. I have other solutions that are not language related but i would like to know more about a solution that is langauge based.

Many thanks - Austin O'Byrne

Re: Problem Cross - Posted fron Sci Crypt Crypto Group

[Austin Obyrne]

On Sunday, November 4, 2018 at 3:27:28 PM UTC, Simon Wright wrote:
> There doesn't appear to be any group "Sci Crypt Crypto".
> 
> It's extraordinarily unlikely that you'd get a constraint error from
> I/O.
> 
> The most likely reason is that you have an array in your code with
> bounds such as 1 .. 100_000 and your code is exceeding these bounds.
> 
> But the chance of anyone here being able to help you find out where is
> also on the low side, since you haven't posted any code (note, I'm not
> inviting you to, since the last time I tried to help you you completely
> ignored my suggestions).
> 
> You would almost certainly gain from using an up-to-date compiler
> (https://www.adacore.com/community).
> 
> Even if you won't do that, try compiling with appropriate options:
> "gnatmake -g -O0 your_program.adb" will probably give you the line
> number where the CE is happening.
Hi again Simon,

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.

I do apologise if it seems I have a churlish disregard for the valuabloe help you gave me in the past but in truth it was beyond my ambitions to apply it.  My interest in Ada is solely in producing a single strong cipher called ASLEC that is vector based. I have done that now.  I do admire the language greatly but as an end in itself but to study it would be an extra string to my bow that I might never use.

May I thank you once more for your responsible attitude to my posted question.

Austin O'Byrne

Re: Problem Cross - Posted fron Sci Crypt Crypto Group

[Simon Wright]

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;

Re: Problem Cross - Posted fron Sci Crypt Crypto Group

[Austin Obyrne]

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.