* In the pipeline. @ 2014-08-26 6:35 austin.obyrne769 2014-09-01 12:31 ` erlo 2014-09-01 16:34 ` gdotone 0 siblings, 2 replies; 8+ messages in thread From: austin.obyrne769 @ 2014-08-26 6:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: In the pipeline. 2014-08-26 6:35 In the pipeline austin.obyrne769 @ 2014-09-01 12:31 ` erlo 2014-09-01 16:34 ` gdotone 1 sibling, 0 replies; 8+ messages in thread From: erlo @ 2014-09-01 12:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: In the pipeline. 2014-08-26 6:35 In the pipeline austin.obyrne769 2014-09-01 12:31 ` erlo @ 2014-09-01 16:34 ` gdotone 2014-09-01 16:50 ` Simon Clubley 1 sibling, 1 reply; 8+ messages in thread From: gdotone @ 2014-09-01 16:34 UTC (permalink / raw) Newbie: only in Chapter 2 of Ada 95, so, please forgive ... Can Ada write to specific locations, address spaces? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: In the pipeline. 2014-09-01 16:34 ` gdotone @ 2014-09-01 16:50 ` Simon Clubley 2014-09-01 17:12 ` gdotone 0 siblings, 1 reply; 8+ messages in thread From: Simon Clubley @ 2014-09-01 16:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: In the pipeline. 2014-09-01 16:50 ` Simon Clubley @ 2014-09-01 17:12 ` gdotone 2014-09-01 23:06 ` Dennis Lee Bieber 0 siblings, 1 reply; 8+ messages in thread From: gdotone @ 2014-09-01 17:12 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: In the pipeline. 2014-09-01 17:12 ` gdotone @ 2014-09-01 23:06 ` Dennis Lee Bieber 2014-09-02 0:22 ` gdotone 0 siblings, 1 reply; 8+ messages in thread From: Dennis Lee Bieber @ 2014-09-01 23:06 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: In the pipeline. 2014-09-01 23:06 ` Dennis Lee Bieber @ 2014-09-02 0:22 ` gdotone 2014-09-02 12:51 ` Dennis Lee Bieber 0 siblings, 1 reply; 8+ messages in thread From: gdotone @ 2014-09-02 0:22 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: In the pipeline. 2014-09-02 0:22 ` gdotone @ 2014-09-02 12:51 ` Dennis Lee Bieber 0 siblings, 0 replies; 8+ messages in thread From: Dennis Lee Bieber @ 2014-09-02 12:51 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-09-02 12:51 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-08-26 6:35 In the pipeline austin.obyrne769 2014-09-01 12:31 ` erlo 2014-09-01 16:34 ` gdotone 2014-09-01 16:50 ` Simon Clubley 2014-09-01 17:12 ` gdotone 2014-09-01 23:06 ` Dennis Lee Bieber 2014-09-02 0:22 ` gdotone 2014-09-02 12:51 ` Dennis Lee Bieber
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox