comp.lang.ada
 help / color / mirror / Atom feed
* Should I Box Clever.
@ 2013-12-10  0:36 Austin Obyrne
  2013-12-11 16:59 ` Simon Wright
  0 siblings, 1 reply; 6+ messages in thread
From: Austin Obyrne @ 2013-12-10  0:36 UTC (permalink / raw)


I want to say with correct programming language parlance that I have encryption software that is known to work in Ada-95 using a gnat 311.p compiler and without testing it in more modern compilers I want it to remain at that level of description for political reasons. I propose saying that it is native to that environment for the time being subject to testing for more modern settings.

Fortunately, the software has been tested this week and is known to run with sufficient success in gnat 2013 in a MAC environment for me to say it is reasonable to assume without testing that it will also run in a modern Windows environment using a compiler of that same vintage.

My reasons for behaving like this is that a huge amount of work has gone into creating this invention and testing it in other compilers outside of the development compiler is almost trivial compared with the original work of getting it up and running and demonstrating that it is in the ultimate class of “theoretically unbreakable” cryptographic strength. 

There is some risk of spurious results unrelated to cryptography however because of using strange new unpredictable compilers - the last thing any cipher wants is doubt being cast on its cryptographic strength and that could easily ensue.


Apart from the historical One-Time Pad ciphers of this class are unheard of and all modern ciphers that are complexity-theoretic in design are living on borrowed time (rumours are strong that they have already been broken by the NSA even on their own AES ciphers in their Data Centre in the Utah desert - they were always only of "practically unbreakable" crypto strength anyway so ....).


Testing ciphers that are known to be unbreakable in a certain environment (i.e. using gnat 311.p compiler however modest) on different modern compilers that are very likely to throw up runtime problems is literally going out on a limb that may well cause damning suspicions that could quite wrongly stick to perfectly good ciphers.

Clearly, should any big operator like NSA, IBM, MIT take a shine to these ciphers they could with their huge resources verify my ciphers very quickly – even to rewriting them - it  is not prudent for me to do it myself before a highly intransigent, dishonest establishment and risk getting a shadow of unjustified doubt cast on my work.

The question is would I be right in saying that my ciphers are ‘native’ to their development environment? only for the time being but pending being tested in other environments (just want to get the semantics right).

Anybody ?

adacrypt




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Should I Box Clever.
  2013-12-10  0:36 Should I Box Clever Austin Obyrne
@ 2013-12-11 16:59 ` Simon Wright
  2013-12-11 19:07   ` Austin Obyrne
  0 siblings, 1 reply; 6+ messages in thread
From: Simon Wright @ 2013-12-11 16:59 UTC (permalink / raw)


Austin Obyrne <austin.obyrne@hotmail.com> writes:

> Fortunately, the software has been tested this week and is known to
> run with sufficient success in gnat 2013 in a MAC environment for me
> to say it is reasonable to assume without testing that it will also
> run in a modern Windows environment using a compiler of that same
> vintage.

That's going a bit far.

The code builds OK, but you can't decrypt on Mac OS X (or Linux, or any
Unix-based system) data that has been encrypted on Windows.

This isn't a version-of-GNAT problem; it's caused by (what the consensus
seems to agree is) a limitation of GNAT's Text_IO.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Should I Box Clever.
  2013-12-11 16:59 ` Simon Wright
@ 2013-12-11 19:07   ` Austin Obyrne
  2013-12-11 19:13     ` Austin Obyrne
  2013-12-11 22:30     ` Simon Wright
  0 siblings, 2 replies; 6+ messages in thread
From: Austin Obyrne @ 2013-12-11 19:07 UTC (permalink / raw)


On Wednesday, December 11, 2013 4:59:48 PM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes: > Fortunately, the software has been tested this week and is known to > run with sufficient success in gnat 2013 in a MAC environment for me > to say it is reasonable to assume without testing that it will also > run in a modern Windows environment using a compiler of that same > vintage. That's going a bit far. The code builds OK, but you can't decrypt on Mac OS X (or Linux, or any Unix-based system) data that has been encrypted on Windows. This isn't a version-of-GNAT problem; it's caused by (what the consensus seems to agree is) a limitation of GNAT's Text_IO.

The code builds OK, 

<but you can't decrypt on Mac OS X (or Linux, or any 
Unix-based system) data that has been encrypted on Windows. 

You are saying understandably that this something you have actually experienced.

In practice this is could not happen because.

I have just explained in another reply that I use the concept of mutual databases i.e. the entities use identical databases both created by the sending entity. Whatever is encrypted in either database is decrypted in the other without fail.  If it does fail at the creation stage then the databases is not used until the reasons why it is failing are corrected and full compatibility is guaranteed at the sending entiy's end.  

The way it works is that Alice (Industry standard pseoudonym for the sending entity) writes her encryption program firstly. She then creates the decryption program that decrypts  her earlier ciphertext from the first program.  She does'n finish with his until it is perfect and when she has tweaked it for the last time only then does she send an exact copy of it to Bob (the receiving entity. 

Any problems must be sorted out at that stage and not wait until it gets it to Bob to fail.  Once all that is done we have a mutual database that is literally a 'closed' loop.  It cannot fail due to compiler incompatiblity or whatever  other cause.

Every thing about the mutual scheme is now constant and totally predictable.  The compiler is ratified - the source code is tested, the encryption domain of plaintext for encryption is guaranteed by belonging to the Latin_1 standard.

There is perfect symmetry between the entities' databases.

*This idea of creating mutual databases is valid for any operation system.

If it hasn't worked for you then there are basic problems still to be sorted out in the mutual databases (you are not working to such a scheme obviously but that is the design concept) - it simply cannot go wrong after being delivered by Alice to Bob (that is using a one-off secure delivery by trusted courier).  

Such a scheme completely obviates the highly vulnerable historic problem of key transport in the past.

Alice always decrypts her own plaintext before sending it to Bob as matter of form so it should never happen that the ciphertext crashes at Bob's end - if it does it may signal tampering en route.

Your experiments are out of kilter with the norm as yet - there is still some way to go - the solutions are just around the coener and I have fears for the future.

Austin



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Should I Box Clever.
  2013-12-11 19:07   ` Austin Obyrne
@ 2013-12-11 19:13     ` Austin Obyrne
  2013-12-11 22:30     ` Simon Wright
  1 sibling, 0 replies; 6+ messages in thread
From: Austin Obyrne @ 2013-12-11 19:13 UTC (permalink / raw)


On Wednesday, December 11, 2013 7:07:20 PM UTC, Austin Obyrne wrote:
> On Wednesday, December 11, 2013 4:59:48 PM UTC, Simon Wright wrote: > Austin Obyrne <austin.obyrne@hotmail.com> writes: > Fortunately, the software has been tested this week and is known to > run with sufficient success in gnat 2013 in a MAC environment for me > to say it is reasonable to assume without testing that it will also > run in a modern Windows environment using a compiler of that same > vintage. That's going a bit far. The code builds OK, but you can't decrypt on Mac OS X (or Linux, or any Unix-based system) data that has been encrypted on Windows. This isn't a version-of-GNAT problem; it's caused by (what the consensus seems to agree is) a limitation of GNAT's Text_IO. The code builds OK, <but you can't decrypt on Mac OS X (or Linux, or any Unix-based system) data that has been encrypted on Windows. You are saying understandably that this something you have actually experienced. In practice this is could not happen because. I have just explained in another reply that I use the concept of mutual databases i.e. the entities use identical databases both created by the sending entity. Whatever is encrypted in either database is decrypted in the other without fail. If it does fail at the creation stage then the databases is not used until the reasons why it is failing are corrected and full compatibility is guaranteed at the sending entiy's end. The way it works is that Alice (Industry standard pseoudonym for the sending entity) writes her encryption program firstly. She then creates the decryption program that decrypts her earlier ciphertext from the first program. She does'n finish with his until it is perfect and when she has tweaked it for the last time only then does she send an exact copy of it to Bob (the receiving entity. Any problems must be sorted out at that stage and not wait until it gets it to Bob to fail. Once all that is done we have a mutual database that is literally a 'closed' loop. It cannot fail due to compiler incompatiblity or whatever other cause. Every thing about the mutual scheme is now constant and totally predictable. The compiler is ratified - the source code is tested, the encryption domain of plaintext for encryption is guaranteed by belonging to the Latin_1 standard. There is perfect symmetry between the entities' databases. *This idea of creating mutual databases is valid for any operation system. If it hasn't worked for you then there are basic problems still to be sorted out in the mutual databases (you are not working to such a scheme obviously but that is the design concept) - it simply cannot go wrong after being delivered by Alice to Bob (that is using a one-off secure delivery by trusted courier). Such a scheme completely obviates the highly vulnerable historic problem of key transport in the past. Alice always decrypts her own plaintext before sending it to Bob as matter of form so it should never happen that the ciphertext crashes at Bob's end - if it does it may signal tampering en route. Your experiments are out of kilter with the norm as yet - there is still some way to go - the solutions are just around the coener and I have fears for the future. Austin

Correction. 

"I have fears for the future."

This should read "I have no fears for the future"







^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Should I Box Clever.
  2013-12-11 19:07   ` Austin Obyrne
  2013-12-11 19:13     ` Austin Obyrne
@ 2013-12-11 22:30     ` Simon Wright
  2013-12-12  1:27       ` Austin Obyrne
  1 sibling, 1 reply; 6+ messages in thread
From: Simon Wright @ 2013-12-11 22:30 UTC (permalink / raw)


Austin Obyrne <austin.obyrne@hotmail.com> writes:

> *This idea of creating mutual databases is valid for any operation system.
>
> If it hasn't worked for you then there are basic problems still to be
> sorted out in the mutual databases (you are not working to such a
> scheme obviously but that is the design concept) - it simply cannot go
> wrong after being delivered by Alice to Bob (that is using a one-off
> secure delivery by trusted courier).

Well, I used your program to try to decrypt a ciphertext that you had
generated, and it failed. So I don't think it's fair to say that *I* am
not working to a scheme.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Should I Box Clever.
  2013-12-11 22:30     ` Simon Wright
@ 2013-12-12  1:27       ` Austin Obyrne
  0 siblings, 0 replies; 6+ messages in thread
From: Austin Obyrne @ 2013-12-12  1:27 UTC (permalink / raw)


On Wednesday, December 11, 2013 10:30:09 PM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes: > *This idea of creating mutual databases is valid for any operation system. > > If it hasn't worked for you then there are basic problems still to be > sorted out in the mutual databases (you are not working to such a > scheme obviously but that is the design concept) - it simply cannot go > wrong after being delivered by Alice to Bob (that is using a one-off > secure delivery by trusted courier). Well, I used your program to try to decrypt a ciphertext that you had generated, and it failed. So I don't think it's fair to say that *I* am not working to a scheme.

No. that is fraught with disaster.

I really appreciate your work but for my stuff (perfect in Windows) to work in MAC you must create this concept of mutual data bases right from the start using your 2013 compiler - you would need to rewrite the programs virtually and tease out any incompatibilities that may arise piece by piece.  I am very optimistic that it will work but it needs to be built up from scratch.

I would gladly do this myself but I don't have an Apple Mac computer and the cost of buying one is prohibitive to me at present.

If you want to try doing this I could liaise with it all the way.  That would be a great injection in Ada cryptography a la Mac.  The whole of the MAC society would benefit.

At present you are trying to zoom in at a quite high level and there are very lots of small stumbling blocks arising but they are indeed quite small that can be overcome when confronted as they arise at their own level piecemeal.

I'm finding it very very frustrating equipping myself to do anything more than what I have done to date i.e. using a gnat 311.p compiler (that loads like a dream) to demonstrate my algorithms.  

The free Libre.ada.com downloads are a pain in the butt and one risks a download of free malaware to come down with it each time.  The whole scheme is not that user friendly - ideally it shoud be made available for purchase even on a CD ROM rather than downloading.

Please don't give up on the mutual database idea for Apple Mac just yet.

Question: any suggestions on how I might get started with Apple Mac myself as cheaply as possible.

I'm sick of the Libre free downloads and would consider acquiring a computer somehow if I could be guaranteed a compiler on a CD ROM that would install easily.

Many thanks for your great input.

Austin


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2013-12-12  1:27 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-10  0:36 Should I Box Clever Austin Obyrne
2013-12-11 16:59 ` Simon Wright
2013-12-11 19:07   ` Austin Obyrne
2013-12-11 19:13     ` Austin Obyrne
2013-12-11 22:30     ` Simon Wright
2013-12-12  1:27       ` Austin Obyrne

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