In the pipeline.

In the pipeline.

[austin.obyrne769]

Thanks to every body for your help in the matter of integer overflow.  The solutions you gave me do not need to be implemented nor is there any danger of it happening uncontrollably because I have decided that my already up-running robust data validation program preempts any problem arising in any case.  

It is important to me to make this clear to reader because I have two very good Ada driven ciphers coming out soon.

This is personalized cryptography on a hand-held device for the uninitiated masses of home computer users who do not need to know anything about the cryptography or the mathematics that under pins it or indeed the programming language being used to convey it as a cipher.

This comes about from the convenience to me of being able to load Ada compilers on a Microsoft Surface Pro 2 tablet (Pro 3 comes out today).  The upshot is that the so-called euphemistic man/woman 'in the street' can now have theoretically unbreakable security of communications as a world first (apart from the trivial One-Time pad) that even the NSA does not have.  This stymies the NSA from shamefully purloining peoples' privacy.

It can be demonstrated before the most rigorous mathematical adjudicators that both of these ciphers are in the ultimate class of "Theoretically Unbreakable" cryptographic strength. The ciphers have an encryption/decryption rate of 30,000 characters per second on a typical home computer which is more than sufficient for most individuals.

It is a very useful thing also to be able to achieve perfect secrecy of communications and secure storage as a second attribute on a hand-held device in out-of-office scenarios.

The discussion on integer overflow was largely for my education.

* there is no problem in practice.

I repeat that Ada is the ideal language for cryptography work in my view and it is very convenient and gratifying to me after fifteen years of hard work to know that this Microsoft tablet can host such a powerful tool as an unbreakable cipher running in Ada-95 on a handheld device (Ian Flemming's 'M' could have conceived the idea even) - *it will load the older gnat 311.p that I use also.

The Apple i-pad probably does all this also I expect?.

Thanks again to every body - I am taking it that user-defined very large integers > 2^31 -1 in yesterday's discussion is only feasible in a 64-bit environment - there is no problem with that.

adacrypt

Re: In the pipeline.

[erlo]

On 26-08-2014 08:35, austin.obyrne769@btinternet.com wrote:
> 
> Thanks to every body for your help in the matter of integer overflow.  The solutions you gave me do not need to be implemented nor is there any danger of it happening uncontrollably because I have decided that my already up-running robust data validation program preempts any problem arising in any case.  
> 
> It is important to me to make this clear to reader because I have two very good Ada driven ciphers coming out soon.
> 
> This is personalized cryptography on a hand-held device for the uninitiated masses of home computer users who do not need to know anything about the cryptography or the mathematics that under pins it or indeed the programming language being used to convey it as a cipher.
> 
> This comes about from the convenience to me of being able to load Ada compilers on a Microsoft Surface Pro 2 tablet (Pro 3 comes out today).  The upshot is that the so-called euphemistic man/woman 'in the street' can now have theoretically unbreakable security of communications as a world first (apart from the trivial One-Time pad) that even the NSA does not have.  This stymies the NSA from shamefully purloining peoples' privacy.
> 
> It can be demonstrated before the most rigorous mathematical adjudicators that both of these ciphers are in the ultimate class of "Theoretically Unbreakable" cryptographic strength. The ciphers have an encryption/decryption rate of 30,000 characters per second on a typical home computer which is more than sufficient for most individuals.


Has this demonstration been made? And to whom?

> 
> It is a very useful thing also to be able to achieve perfect secrecy of communications and secure storage as a second attribute on a hand-held device in out-of-office scenarios.
> 
> The discussion on integer overflow was largely for my education.
> 
> * there is no problem in practice.
> 
> I repeat that Ada is the ideal language for cryptography work in my view and it is very convenient and gratifying to me after fifteen years of hard work to know that this Microsoft tablet can host such a powerful tool as an unbreakable cipher running in Ada-95 on a handheld device (Ian Flemming's 'M' could have conceived the idea even) - *it will load the older gnat 311.p that I use also.
> 
> The Apple i-pad probably does all this also I expect?.
> 
> Thanks again to every body - I am taking it that user-defined very large integers > 2^31 -1 in yesterday's discussion is only feasible in a 64-bit environment - there is no problem with that.
> 
> adacrypt
> 

Erlo

Re: In the pipeline.

[gdotone]

Newbie: only in Chapter 2 of Ada 95, so, please forgive ...

   Can Ada write to specific locations, address spaces? 

   

Re: In the pipeline.

[Simon Clubley]

On 2014-09-01, gdotone@gmail.com <gdotone@gmail.com> wrote:
> Newbie: only in Chapter 2 of Ada 95, so, please forgive ...
>
>    Can Ada write to specific locations, address spaces? 
>

I strongly recommend you start new threads in future and not post
into an unrelated thread. Among other reasons, your question may
never be seen because people might be skipping over a thread.

In answer to your question, yes it can. See here for an example:

http://en.wikibooks.org/wiki/Ada_Programming/Attributes/%27Address

BTW, in that example, assuming the device register does not contain
a signed 32 bit integer, I disagree with the use of Integer_32 if
Integer_32 is supposed to be a signed 32 bit integer. An unsigned
32 bit datatype would be far better here.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: In the pipeline.

[gdotone]

On Monday, September 1, 2014 12:50:45 PM UTC-4, Simon Clubley wrote:

> I strongly recommend you start new threads in future and not post
> into an unrelated thread. Among other reasons, your question may
> never be seen because people might be skipping over a thread.

thanks, i will do next time. the author of the original post was discussing cryptography, and i had just listen to Security Now, with steve gibson, discussing how important it is/was to do certain things, to memory, to make sure the data was not taken from the location where it resided decrypted, in his newest program, written in assembly.

i just figured those who would participate in this discuss would absolutely know. 
but, i will take your advise, as it makes good sense. you are right. it would have been easily seen in a new post.  

thanks for the advice simom, and thanks for the web site.

i am looking forward to understanding and using that bit of information in the future.

g.

Re: In the pipeline.

[Dennis Lee Bieber]

On Mon, 1 Sep 2014 10:12:00 -0700 (PDT), gdotone@gmail.com declaimed the
following:

>On Monday, September 1, 2014 12:50:45 PM UTC-4, Simon Clubley wrote:
>
>> I strongly recommend you start new threads in future and not post
>> into an unrelated thread. Among other reasons, your question may
>> never be seen because people might be skipping over a thread.
>
>thanks, i will do next time. the author of the original post was discussing cryptography, and i had just listen to Security Now, with steve gibson, discussing how important it is/was to do certain things, to memory, to make sure the data was not taken from the location where it resided decrypted, in his newest program, written in assembly.
>
	That situation shouldn't require explicitly referencing ad-hoc memory.
If the data was held in an Ada variable, then you can do whatever you want
with it without having to know where that variable was located. Just make
sure you run a secure erase on the variable. In pseudo-code

myDecryptionBuffer : FixedMemoryBuffer;

for i in myDecryptionBuffer'range loop
	myDecryptionBuffer(i) := someRandom(); -- randomize
end loop;
for i in myDecryptionBuffer'range loop
	myDecryptionBuffer(i) := not myDecryptionBuffer(i); -- bit invert
end loop;
for i in myDecryptionBuffer'range loop
	myDecryptionBuffer(i) := someRandom(); -- different randomize
end loop;

	If you really want to be paranoid, you'll save a copy of the random
pattern, and do a comparison loop after each of the above loops to ensure
the data changed to the pattern that was written.


>i just figured those who would participate in this discuss would absolutely know. 
>but, i will take your advise, as it makes good sense. you are right. it would have been easily seen in a new post.  
>
>thanks for the advice simom, and thanks for the web site.
>
>i am looking forward to understanding and using that bit of information in the future.
>
>g.
>
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: In the pipeline.

[gdotone]

On Monday, September 1, 2014 7:06:40 PM UTC-4, Dennis Lee Bieber wrote:

> 	That situation shouldn't require explicitly referencing ad-hoc memory.
> If the data was held in an Ada variable, then you can do whatever you want 
> with it without having to know where that variable was located. Just make 
> sure you run a secure erase on the variable. In pseudo-code

> myDecryptionBuffer : FixedMemoryBuffer;

> for i in myDecryptionBuffer'range loop
> 	myDecryptionBuffer(i) := someRandom(); -- randomize 
> end loop;

> for i in myDecryptionBuffer'range loop
> 	myDecryptionBuffer(i) := not myDecryptionBuffer(i); -- bit invert
> end loop;
 
> for i in myDecryptionBuffer'range loop 
> 	myDecryptionBuffer(i) := someRandom(); -- different randomize
> end loop;

> 	If you really want to be paranoid, you'll save a copy of the random 
> pattern, and do a comparison loop after each of the above loops to ensure 
> the data changed to the pattern that was written.

that is really, really cool!

Re: In the pipeline.

[Dennis Lee Bieber]

On Mon, 1 Sep 2014 17:22:05 -0700 (PDT), gdotone@gmail.com declaimed the
following:

>
>that is really, really cool!

	Just watch out for stuff that might get built on the stack(s).
Preallocate the buffers statically, and use direct assignments to the
contents...

	A language like Python, OTOH, has no hope for this; strings are
immutable, so any modification to a string really allocates a new string
somewhere in memory, puts the changed data into it, and may (depending on
the code) then mark the old string for garbage collection -- no way to get
to it again.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/