comp.lang.ada
 help / color / mirror / Atom feed
From: Austin Obyrne <austin.obyrne@hotmail.com>
Subject: Re: Should I Box Clever.
Date: Wed, 11 Dec 2013 11:07:20 -0800 (PST)
Date: 2013-12-11T11:07:20-08:00	[thread overview]
Message-ID: <a5a18f7d-6188-48d2-82e8-37f46a52e046@googlegroups.com> (raw)
In-Reply-To: <lylhzr2uij.fsf@pushface.org>

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



  reply	other threads:[~2013-12-11 19:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2013-12-11 19:13     ` Austin Obyrne
2013-12-11 22:30     ` Simon Wright
2013-12-12  1:27       ` Austin Obyrne
replies disabled

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