Ada Connections to this Crypto.

Ada Connections to this Crypto.

[Austin Obyrne]

This cryptography is complete now and several variants of the original cipher are up and running.

The focus all along has been on getting the core algorithm satisfactory with the outlook that anything else outside of that while still being under the general umbrella of cryptology is more to do with management of the infrastructure that has this algorithm as its core. No less important but a separate thing!

The cipher has been nominally been described as ASCII orientated (characters 32 ...126 incl.) but the real scope is that of the entire Latin_1 Character set 0 ... 255 and this is available to users.

In the Ada programming language the type CHARACTER is an enumeration type that is built in to the Ada package STANDARD and CHARACTER can take all the values represented by 8 bits in Latin_1.

The cipher documentation that goes with this cipher makes heavy use of the ASCII subset since this is the most used part of the full scope of 'CHARACTER' that readers may want to become familiar with initially but the full Latin_1 set is there also for users to use.  I have included some demonstration programs of the use of the full Latin_1 set in the ciphers that have been uploaded to http://www.adacryptpages.com

The way this cipher works is that the main program is a LOOP that calls each item of plaintext, - character by character from a prepared file and encrypts each one in each single pass of the loop and continuing until the end-of-file is reached and the loop is terminated. 

*We piped and you didn't dance.

I have been harassed by some readers with claims that there are ways by which 'any' data can be called (whatever that means)and encryption will still work.  They seem to be saying that this is done by user-defined enumeration types  that can be used instead of ASCII or Latin-1.  This ploy will not work in this cipher and at best will not be viable long-term in the science of cryptology.

All programming languages in the WEST at least have this same enumeration type called CHARACTER in Ada, as standard. 

I repeat - "ASCII"  is a nominal description of this cryptography - it is not a limitation.
 
Adacrypt

Re: Ada Connections to this Crypto.

[mrvmurray]

On Sunday, 14 December 2014 19:20:42 UTC+2, Austin Obyrne  wrote:
> I have been harassed by some readers with claims that there are ways
> by which 'any' data can be called (whatever that means)and encryption
> will still work.  They seem to be saying that this is done by user-defined
> enumeration types  that can be used instead of ASCII or Latin-1. 
> This ploy will not work in this cipher and at best will not be viable
> long-term in the science of cryptology.

You contradict yourself with every post!

A couple of days back, your endorsed the opposite position in a post
right here:

https://groups.google.com/d/msg/comp.lang.ada/mDM8cI7JbDU/z39Q-eCoqsgJ

You yet again distance yourself from the folks who you so recently revered.

Are you sure you are able to handle this level of debate; it sure looks like
you have no idea of what you are trying to say, or maintain a cogent argument.

M
-- 

Re: Ada Connections to this Crypto.

[Björn Lundin]

On 2014-12-14 18:20, Austin Obyrne wrote:

...
>the real scope is that of the entire Latin_1 Character
> set 0 ... 255 and this is available to users.

You do realize that with 0 .. 255 you describe a byte.
And that _any_ file is made up by bytes.
Like images, movies, text, exe-files, databases ...

> I have been harassed by some readers with claims that 
>there are ways by which 'any' data can be called 
>(whatever that means)and encryption will still work.

As I said :
Like images, movies, text, exe-files, databases ...


They seem to be saying that this is done by
user-defined enumeration types
that can be used instead of ASCII or Latin-1.

Well no. That is your interpretation. I have not seen
anyone here state that.

> This ploy will not work in this cipher and

Ploy ? You may write your own ciphers,
but say pgp/gpg is no ploy.

> at best will not be viable long-term in the science of cryptology.

Most likely longer than yours.

--
Björn

Re: Ada Connections to this Crypto.

[mrvmurray]

On Sunday, 14 December 2014 20:08:38 UTC+2, björn lundin  wrote:
> On 2014-12-14 18:20, Austin Obyrne wrote:
>> They seem to be saying that this is done by
>> user-defined enumeration types
>> that can be used instead of ASCII or Latin-1.
> 
> Well no. That is your interpretation. I have not seen
> anyone here state that.

Whoever sorts out this misconception of O'Byrne's can claim to
have achieved something.

O'Byrne is rigidly attached to the idea that the computer bytes contain
character values equating to text (plus the control codes).

Abstract bytes as numbers are beyond his capability. He just doesn't
get it.

M
-- 

Re: Ada Connections to this Crypto.

[Simon Wright]

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

> I have been harassed by some readers with claims that there are ways
> by which 'any' data can be called (whatever that means)and encryption
> will still work.  They seem to be saying that this is done by
> user-defined enumeration types that can be used instead of ASCII or
> Latin-1.

I rather think I take offence at that. You imply that the program I
wrote using your crypto to encrypt/decrypt a ZIP file (which is anything
but Latin-1 text!) was bogus.

:plonk:

Re: Ada Connections to this Crypto.

[mrvmurray]

On Sunday, 14 December 2014 22:28:36 UTC+2, Simon Wright  wrote:
> I rather think I take offence at that. You imply that the program I
> wrote using your crypto to encrypt/decrypt a ZIP file (which is anything
> but Latin-1 text!) was bogus.

O'Byrne has form here.

His arrogance has turned very many folks away from taking him
seriously. This may be forgivable, but as he has no clue and is
hostile to learning, perhaps not yet.

He has demonstrated exceptionally poor listening (er, reading)
skills too.

You are not alone.

M
-- 

Re: Ada Connections to this Crypto.

[Denis McMahon]

On Sun, 14 Dec 2014 09:20:40 -0800, Austin Obyrne wrote:

> waffly crap

Until you get your head round the concepts of bytes and streams, your 
cryptography is of no interest to anyone except yourself.

People don't give a toss about your waffle and flannel, they want 
provably unbreakable encryption that works on streams of bytes.

Even if you have provably unbreakable encryption (which you don't) it is 
still of no interest until it works on streams of bytes.
-- 
Denis McMahon, denismfmcmahon@gmail.com

Re: Ada Connections to this Crypto.

[Austin Obyrne]

On Sunday, December 14, 2014 8:28:36 PM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes:
> 
> > I have been harassed by some readers with claims that there are ways
> > by which 'any' data can be called (whatever that means)and encryption
> > will still work.  They seem to be saying that this is done by
> > user-defined enumeration types that can be used instead of ASCII or
> > Latin-1.
> 
> I rather think I take offence at that. You imply that the program I
> wrote using your crypto to encrypt/decrypt a ZIP file (which is anything
> but Latin-1 text!) was bogus.
> 
> :plonk:

Oh Gosh NO,
lemme explain.
What I am getting at is this.

In my mind -

In cryptography when a data item is called in for encryption the 'coinage' i.e. the currency for mutual understanding in the obfuscation scheme is a standard enumeration type which happily is the ASCII standard today (ignore the extension to the full Latin_1 which my be marked - 'proved'). 

Because it is a universal standard there is no need for the entities to send copies of it to each other.  This is a hugely important benefit that is invariably taken for granted because of the sheer familiarity that we all enjoy with it - i.e. because we are using 'standard' computers and 'standard' programming languages that have ASCII as the inbuilt code the intrinsic comparator for buying and selling is ASCII.

I repeat we do not have to send copies of our comparator in cryptography to each other with each message so long as we are both using the same ubiquitous standard that each entity can safely assume the other is also using. It is virtually a public key and it travels free without any need to be secured against theft.

Consider now the case when the entities deliberately eschew this mutual standard and opt instead for a user-defined enumeration type instead of ASCII that evolves from using sequential_IO instead of Text_IO (which already enables perfect sequential calling of the plaintext items for encryption anyway) then this new non-standard comparator cannot be assumed anymore and a copy of Alice's customized "Information Interchange" encryption alphabet whatever it is must be sent by secure means to Bob to enable him to decrypt her ciphertext. What was previously a free and helpful tool has now become a liability that needs protection itself while in transit instead of helping to provide protection as it would in the normal scheme of things. 

There may be exceptions to this like your ZIP file model- since this debate is not fully researched - but at the present time it is not to be recommended and I would certainly rule it out for now at least if not for ever in my cryptography.

I don't accept the inevitable trivial curio exceptions that always arise in discussions like this as valid argument which of course your ZIP model is not.  

*It may well be very worthwhile in very important super cases to do just that i.e. to contrive a non-standard as the comparator - a future researcher will of course keep an open mind but in broad principle it is NO from me to any such scheme at this time.  

I don't think the readers involved are thinking that far ahead.

Thanks for your input.  

adacrypt

Re: Ada Connections to this Crypto.

[Austin Obyrne]

On Monday, December 15, 2014 6:14:40 AM UTC, Denis McMahon wrote:
> On Sun, 14 Dec 2014 09:20:40 -0800, Austin Obyrne wrote:
> 
> > waffly crap
> 
> Until you get your head round the concepts of bytes and streams, your 
> cryptography is of no interest to anyone except yourself.
> 
> People don't give a toss about your waffle and flannel, they want 
> provably unbreakable encryption that works on streams of bytes.
> 
> Even if you have provably unbreakable encryption (which you don't) it is 
> still of no interest until it works on streams of bytes.
> -- 
> Denis McMahon, denismfmcmahon@gmail.com

Hi,

In my view binary representation is what is holding up the progress of cryptography.  It is short-sightedly ring-fencing current crypto research in binary number-work to the exclusion of all the vast possibilities that exist in decimal mathematics.  This is an appalling mistake.

No I will not be getting my head around bytes 'n streams as you suggest - that is retrogressive.

Binary arithmetic is only useful for demonstrating machine code to very young students.

adacrypt

Re: Ada Connections to this Crypto.

[Austin Obyrne]

On Sunday, December 14, 2014 8:28:36 PM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes:
> 
> > I have been harassed by some readers with claims that there are ways
> > by which 'any' data can be called (whatever that means)and encryption
> > will still work.  They seem to be saying that this is done by
> > user-defined enumeration types that can be used instead of ASCII or
> > Latin-1.
> 
> I rather think I take offence at that. You imply that the program I
> wrote using your crypto to encrypt/decrypt a ZIP file (which is anything
> but Latin-1 text!) was bogus.
> 
> :plonk:

Clearly, what I have suggested earlier is already being done indirectly by the other key-sets in every crypto scheme so it is not to be expected that using customized "Information Interchange" (Using the extract from ASCII) has any erstwhile latent benefits. 

I am more interested in your take on using Sequential_IO (being advocated to me) instead of my preferred Text_IO which is totally adequate as it stands.

What really puzzles me is the inference that using sequential_IO for which I would have to create crypto instances has extra *cryptographic properties that will enable any data type to be be encrypted.  I don't think the people saying this realise that reading in data is very, very easy by many methods whereas encrypting it unbreakably after you have got it in is very, very difficult and changing the method of reading it in seems to be the undoing of an already  very robust current system.

I would be grateful for your opinion on this because a number of people seem to be mixing up the CS with the Crypto. Nothing one does with the method of reading in data for encryption will make it easier to encrypt.

adacrypt

Re: Ada Connections to this Crypto.

[mrvmurray]

On Monday, 15 December 2014 10:50:45 UTC+2, Austin Obyrne  wrote:
> In cryptography when a data item is called in for encryption the 'coinage'
> i.e. the currency for mutual understanding in the obfuscation scheme is
> a standard enumeration type which happily is the ASCII standard today
> (ignore the extension to the full Latin_1 which my be marked - 'proved'). 

Use standard terminology, please.

Subroutines are "called". Data is "read" (or "written" not) "called".

The standard enumeration type is a byte, also known as an octet, NOT Latin-1
or any other character encoding that you happen to be unable to forget about.
These resemble integers in the range 0..255 and that is all they are.
 
> I repeat we do not have to send copies of our comparator ...

In the case of bytes you don't even have to think about doing this.

> Consider now the case when the entities deliberately eschew this
> mutual standard and opt instead for a user-defined enumeration
> type instead of ASCII that evolves from using sequential_IO ...

You are tantalisingly close to "getting it" here. it is not a user-defined
enumeration type, it is a UNIVERSAL enumeration type.

> There may be exceptions to this like your ZIP file model- since this
> debate is not fully researched ...

This is about as "fully researched" as it gets! You are making a very
basic new-programmer error.

> I don't accept the inevitable trivial curio exceptions ...

Well, nobody agrees with you here, because you are about as wrong as 
it is possible to get. Read the numerous responses you get from the
knowledgeable people you continuously thank for their input.

> I don't think the readers involved are thinking that far ahead.

You think wrong. Read your readers' responses to see what they are thinking,
and stop assuming that you are unassailably correct.

> Thanks for your input.  

... which you ignore and reject.

M
-- 

Re: Ada Connections to this Crypto.

[mrvmurray]

On Monday, 15 December 2014 11:30:56 UTC+2, Austin Obyrne  wrote:
> I am more interested in your take on using Sequential_IO (being advocated
> to me) instead of my preferred Text_IO which is totally adequate as it stands.

Sequential_IO can read and write ANY file and ANY data trivially. MP3s,
photographs, files whose contents are otherwise opaque - ANYTHING.
That includes the data that text_io can read.

Text_IO can only read/write human readable _text_ files. That makes it 
inadequate.

> What really puzzles me is the inference that using sequential_IO for which
>I would have to create crypto instances has extra *cryptographic properties
> that will enable any data type to be be encrypted.

No.

Currently, you read a text character, and turn it into a number in the range
32..126, which corresponds to its ASCII numeric value. Reading using
sequential_io will give you this same 32..126 for any ASCII characters that
happen to be in the sequential stream without having to go through an
explicit conversion step, PLUS, you get the full 0..255 range of which
32..126 is a subset. There is no need to "create crypto instances has
extra *cryptographic properties that will enable any data type to be
be encrypted" at all.

> I would be grateful for your opinion on this because a number of
> people seem to be mixing up the CS with the Crypto.

CS, mathematics and crypto are already mixed.

Show your gratitude by believing this.

M
-- 

Re: Ada Connections to this Crypto.

[mrvmurray]

On Monday, 15 December 2014 11:02:10 UTC+2, Austin Obyrne  wrote:
> In my view binary representation is what is holding up the progress of cryptography. 

Nobody cares about your mistaken view.

> No I will not be getting my head around bytes 'n streams as you suggest - that is retrogressive.

No, it is aggressive ignorance on your part. You refuse to try to learn.

> Binary arithmetic is only useful for demonstrating machine code to very young students.

Bullshit.

M
-- 

Re: Ada Connections to this Crypto.

[Austin Obyrne]

On Sunday, December 14, 2014 8:28:36 PM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes:
> 
> > I have been harassed by some readers with claims that there are ways
> > by which 'any' data can be called (whatever that means)and encryption
> > will still work.  They seem to be saying that this is done by
> > user-defined enumeration types that can be used instead of ASCII or
> > Latin-1.
> 
> I rather think I take offence at that. You imply that the program I
> wrote using your crypto to encrypt/decrypt a ZIP file (which is anything
> but Latin-1 text!) was bogus.
> 
> :plonk:

May I take the opportunity of aerating a particular point the has been influencing cryptography for far too long.

Everybody will agree that binary numbers are extremely counter intuitive and it is a prodigious task some times to change a binary number into the equivalent decimal number.  One cannot just verbalise (as they should be able to do) binary numbers as easily as decimal numbers so those magical figments of the mathematical imagination that often lead to theorems are far less likely to be born in such a constrained environment than in the denary world.   

This is due to the innate complexity of the binary number system.  In cryptography complexity is seen as a measurable property and cryptography that uses complexity to obfuscate reality is simply called complexity-theoretic.

Back in the 60'/70's the US government ordained that ASCII would be the standard in all communications - I applaud that decision and I see nothing whatever wrong with ASCII - I like it.

What I don't like and I consider a big mistake was to represent (publicly) the elements of ASCII in binary form and not in decimal form.  I conjecture that the reason for this was the innate counter-intuitiveness of the binary number system that suggested itself as a readymade encryption system to the government experts of the day.  It would fit nicely with the block ciphers of binary digits that they were also planning to come out about the same time.

I contend that this innate complexity of binary numbers was the low-hanging fruit that beguiled those experts of the day into wrongly going for block ciphers that would be populated by binary digits.  The result is complexity-theoretic cryptography such as DES firstly and now AES.  Admittedly, there is no way they could have foreseen the enormous power of super-computers that have been realised since then to say nothing of what is on the horizon that would threaten these block ciphers.  The AES encryption system is computer-dependent because if it happens that enough computer power becomes available  the AES cipher will be prone to being brute forced.  How true or false that premise may be is  immaterial.  A national government should not knowingly sail that close to the wind and should instead be looking for alternatives. 

Apart from the RSA cipher which is decimal based and brute force-able there has not been a "Theoretically Unbreakable" cipher since the One-Time pad in about 1920 in the past fifty years of trying by all cryptographers world wide (I claim to be able to demonstrate two such ciphers).  The RSA cipher is a very powerful one but again it is prone to brute force if enough computer materialises  - it is also in the second rated class of being, like the AES only "Practically Unbreakable".

My argument is that the failure to design totally unbreakable ciphers is not being helped by using the binary number system.  Mathematically, the binary number system is a cul-de-sac and is so constrained that no creative ideas are forthcoming - it is the most infertile ground for creative thinking one can imagine.  Unfortunately complexity theoretic cryptography is still being promoted and a whole new approach in the form of  decimal based cryptography is unlikely but that is what is needed.

Common sense says that since all known number theory is decimal based there are many more possibilities for cipher ideas (hope this doesn't open another stream of petulance) out there in the decimal world than in the binary world.

Changing infrastructures of communications systems is enormously expensive so it is understandable why any government is slow to take it on.  It is not known to anyone that I know how near we are to the realisation of Quantum Computing but rumour has that when and if it comes it may blow binary encryption and block ciphers out of the water.

In any case common sense says there are more opportunities in decimal mathematics than in binary.

It is incredible to read just the list of titles alone of complexity-theoretic cipher proposal papers on the web pages of the establishment.  The expense of travelling to far flung places to hear these speakers seems to be no object.

After the revolution - Viva.

adacrypt

Re: Ada Connections to this Crypto.

[mrvmurray]

On Monday, 15 December 2014 15:34:17 UTC+2, Austin Obyrne  wrote:
> Everybody will agree that binary numbers are extremely counter intuitive and
> it is a prodigious task some times to change a binary number into the equivalent
> decimal number.

Crap. Binary is trivial. Conversions are dead simple.

> One cannot just verbalise (as they should be able to do) binary numbers as
> easily as decimal numbers so those magical figments of the mathematical 
> imagination that often lead to theorems are far less likely to be born in such
> a constrained environment than in the denary world.

Maybe with you, but your limited understanding of this subject is not one
that cryptographers, CS folks and mathematicians share. Very many folks
can do binary<->decimal conversion on their fingers, and binary<->hex
conversions in their sleep.

Number theorists don't care what base their numbers are in.

> This is due to the innate complexity of the binary number system.  In
> cryptography complexity is seen as a measurable property and cryptography
> that uses complexity to obfuscate reality is simply called complexity-theoretic.

Complete bullshit.

> Back in the 60'/70's the US government ordained that ASCII would be the
> standard in all communications - I applaud that decision and I see nothing
> whatever wrong with ASCII - I like it.

So do a lot off people. That is irrelevant.

> What I don't like and I consider a big mistake was to represent (publicly)
> the elements of ASCII in binary form and not in decimal form.

What?! Are you serious? Do you really think there is some inherent difference
between decimal 12, binary 1100 hexadecimal C and octal 14? The news for
you is that there isn't. The human-readable representation is of no relevance
at all, and the computer stores all of these as binary 00001100 in a byte. This
happens to also be CR (carriage return) in ASCII if you are interpreting the
byte that way. It is also called a dozen, no matter how you write it.

>  I conjecture that the reason for this was the innate counter-intuitiveness
> of the binary number ...

Total crap.

> I contend that this innate complexity ...

You contend wrong. You have no idea what you are talking about.

> Apart from the RSA cipher which is decimal based ...

RSA is not decimal based. It is numeric, and the base of the number system 
is if no relevance. Numbers are usually represented using a base that is
convenient to the reader or writer, and this choice changes not a thing with
the algorithm. The computer does it in binary, and the source code is typed
in whatever the programmer likes; decimal, hex, octal, whatever. The compiler
translates this to binary numbers and instructions. 

> My argument is that the failure to design totally unbreakable ciphers is not
> being helped by using the binary number system. ...

And your argument fails because of your obvious mathematical ignorance.

> Common sense says that since all known number theory is decimal based

Bullshit. Number theory is not decimal based.

> It is not known to anyone that I know how near we are to the realisation
> of Quantum Computing but rumour has that when and if it comes it may
> blow binary encryption and block ciphers out of the water.

Your naive understanding is showing again.

Certain algorithms are vulnerable to quantum computing attacks. The best
you can manage is "rumour has it ...", yet the fact of a brute-force attack on your
own cipher leaves you unfazed?!

And you know no more than rumour? Good grief!

> In any case common sense says there are more opportunities in decimal
> mathematics than in binary.

Bullshit. There is no difference.

> It is incredible to read just the list of titles alone of complexity-theoretic
> cipher proposal papers on the web pages of the establishment.

Not one of which you understand.

You should call your own cipher "Ignorance-based cryptography".

M
-- 

Re: Ada Connections to this Crypto.

[Mark Carroll]

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

> This is due to the innate complexity of the binary number system.  In
> cryptography complexity is seen as a measurable property and
> cryptography that uses complexity to obfuscate reality is simply
> called complexity-theoretic.

The conventional choice to use binary / bytes is not an attempt to
increase complexity. It has nothing to do with causing confusion and
diffusion, etc. I actually find the binary approach simpler for some
kinds of analysis because I can reduce many ciphers to a composition of
simple logic gates.

> Back in the 60'/70's the US government ordained that ASCII would be
> the standard in all communications - I applaud that decision and I see
> nothing whatever wrong with ASCII - I like it.

I'd thus guess that you're in North America or perhaps Australia? For
most people in the world, ASCII is missing many common useful symbols.

(snip)
> Common sense says that since all known number theory is decimal based
> there are many more possibilities for cipher ideas (hope this doesn't
> open another stream of petulance) out there in the decimal world than
> in the binary world.

You probably need to be careful how you use the phrase "number theory":
the conventional version is /not/ specifically decimal-based. Everything
from perfect numbers to the Euclidean algorithm to the Chinese remainder
theorem to the law of quadratic reciprocity work just as well in binary
as they do in decimal. It sounds like you're actually talking about
something more like elementary school arithmetic.

> In any case common sense says there are more opportunities in decimal
> mathematics than in binary.

No serious cryptographer is going to look at your algorithm until you
have shown mathematically why it resists linear and differential
cryptanalysis. You'll find rather more of them over on sci.crypt than
here. (Ada has no special claim on ASCII.)

-- Mark

Re: Ada Connections to this Crypto.

[mrvmurray]

On Monday, 15 December 2014 16:27:12 UTC+2, Mark Carroll  wrote:
> I'd thus guess that you're in North America or perhaps Australia? For
> most people in the world, ASCII is missing many common useful symbols.

He is an 80-something-year-old retired ships' engineer resident somewhere
in UK. He's been banging this particular drum for 10 years or so, and the
basic premises are unchanged in this time.

Take a look at his code sometime. Beginner stuff.

> No serious cryptographer is going to look at your algorithm until you
> have shown mathematically why it resists linear and differential
> cryptanalysis. You'll find rather more of them over on sci.crypt than
> here. (Ada has no special claim on ASCII.)

He's been laughed at in sci.crypto for many years. He's the resident crank
there.

M
-- 

Re: Ada Connections to this Crypto.

[Denis McMahon]

On Mon, 15 Dec 2014 01:02:09 -0800, Austin Obyrne wrote:

> On Monday, December 15, 2014 6:14:40 AM UTC, Denis McMahon wrote:
>> On Sun, 14 Dec 2014 09:20:40 -0800, Austin Obyrne wrote:
>> 
>> > waffly crap
>> 
>> Until you get your head round the concepts of bytes and streams, your
>> cryptography is of no interest to anyone except yourself.
>> 
>> People don't give a toss about your waffle and flannel, they want
>> provably unbreakable encryption that works on streams of bytes.
>> 
>> Even if you have provably unbreakable encryption (which you don't) it
>> is still of no interest until it works on streams of bytes.

> In my view binary representation is what is holding up the progress of
> cryptography.  It is short-sightedly ring-fencing current crypto
> research in binary number-work to the exclusion of all the vast
> possibilities that exist in decimal mathematics.  This is an appalling
> mistake.

What binary representation? Cryptography is not "ring-fenced" in binary 
number work. You obviously have no understanding of current cryptographic 
methods at all.

> No I will not be getting my head around bytes 'n streams as you suggest
> - that is retrogressive.

You clearly don't even understand the term. Your encryption system is 
doomed.

> Binary arithmetic is only useful for demonstrating machine code to very
> young students.

Binary arithmetic has nothing to do with it. People encrypt and decrypt 
streams of bytes. Anything less than this is what is retrogressive.

-- 
Denis McMahon, denismfmcmahon@gmail.com

Re: Ada Connections to this Crypto.

[Simon Wright]

mrvmurray@gmail.com writes:

> Very many folks can do binary<->decimal conversion on their fingers,
> and binary<->hex conversions in their sleep.

People who programmed the Ferranti F1600 series of military computers
could count up to 31 on the fingers of one hand (the register-address
field in the instruction was 5 bits).

Re: Ada Connections to this Crypto.

[mrvmurray]

On Monday, 15 December 2014 18:17:18 UTC+2, Simon Wright  wrote:
> People who programmed the Ferranti F1600 series of military computers
> could count up to 31 on the fingers of one hand (the register-address
> field in the instruction was 5 bits).

*Like*

<brag type="one-upmanship">
I can do my 9-times-table with both hands by hiding one finger at a time.
</brag>

M

PS: I can program in Ada too. I'm a software engineer, but Ada is a comparatively
new language for me. So far I haven't done a big job in it, but I did use it to write
a brute-force cipher-breaker to decipher O'Byrne's ciphergrams. Trivial.

m
-- 

Re: Ada Connections to this Crypto.

[Austin Obyrne]

On Monday, December 15, 2014 4:17:18 PM UTC, Simon Wright wrote:
> mrvmurray@gmail.com writes:
> 
> > Very many folks can do binary<->decimal conversion on their fingers,
> > and binary<->hex conversions in their sleep.
> 
> People who programmed the Ferranti F1600 series of military computers
> could count up to 31 on the fingers of one hand (the register-address
> field in the instruction was 5 bits).

Thanks for your help all along.

The bottom line has to be "Where are the ciphers that all these clever readers have written? - there blowing in their own wind can be the only answer - there's pedantry, politics and petulance, vicious personal attacks but no ciphers"
 A bit like the golfer who has a lovely set of clubs, polishes the bag , cleans and polishes his shoes, buys some snazzy outfits with a white cap, knows the rules of the game inside out panders to club politics with lots of 'me too' stuff but never hits a ball.

Adacrypt

I do a huge amount of counting in my head too - binary and hex. 

Re: Ada Connections to this Crypto.

[mrvmurray]

On Monday, 15 December 2014 19:59:29 UTC+2, Austin Obyrne  wrote:
> Thanks for your help all along.

You've rejected and dismissed all his help!

> The bottom line has to be "Where are the ciphers that all these clever
> readers have written? - there blowing in their own wind can be the only
> answer - there's pedantry, politics and petulance, vicious personal
> attacks but no ciphers"

More crap.

Cipher writing is not the point. Cipher study and cipher analysis is, as
you've been told many times.

>  A bit like the golfer who has a lovely set of clubs, polishes the bag,
> cleans and polishes his shoes, buys some snazzy outfits with a white
> cap, knows the rules of the game inside out panders to club politics
> with lots of 'me too' stuff but never hits a ball.

That's you. Always on the driving range, swinging wildly with an amateur
stroke, claiming this is somehow new and innovative. Never plays a match
without cheating and excuses. Always boasts about how he could
theoretically shoot a perfect round. No score cards to show anyone,
no valid club membership, big reputation as a bullshitter and a bore.

> I do a huge amount of counting in my head too - binary and hex.

So? Learn and practice something useful. Toddlers can count.

If binary/decimal conversion is tantamount to cryptography to you,
the maybe you need to get a book on school mathematics and do
exercises until you understand it properly. While there try to learn
enough elementary number theory so as not to make quite such an
ass of yourself.

M
-- 

Re: Ada Connections to this Crypto.

[Mark Carroll]

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

> The bottom line has to be "Where are the ciphers that all these clever readers have written? - there blowing in their own wind can be the only answer - there's pedantry, politics and petulance, vicious personal attacks but no ciphers"
>  A bit like the golfer who has a lovely set of clubs, polishes the bag , cleans and polishes his shoes, buys some snazzy outfits with a white cap, knows the rules of the game inside out panders to club politics with lots of 'me too' stuff but never hits a ball.

Not really. I would have loved to developed worthwhile ciphers. In some
of my master's program work I developed software for generating and
assessing block ciphers; only last year I worked on an idea for
automating differential cryptanalysis to assist in my ideas for creating
ciphers. (It failed miserably.) I am /not/ offering cipher designs
because I have read enough and learned enough and tried enough to have
found that I am simply not good enough at it: that other people in the
field are far more skilled than I am, and that I still don't understand
the theory well enough to devise ciphers and provide credible assurance
of their security.

I'm not like a golfer who panders to club politics, I'm like a golfer
who likes the game but after a lot of trying and even two rounds of
classes still can't even hit the ball reliably and realizes that his
efforts are best applied elsewhere. I wouldn't have responded to you at
all had you not been persistently filling an Ada group -- something I
/am/ interested in reading about -- with your peculiar assertions and
misapprehensions, which I've made a good-faith constructive effort to
help you move past.

-- Mark

Re: Ada Connections to this Crypto.

[erlo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15-12-2014 14:34, Austin Obyrne wrote:
> On Sunday, December 14, 2014 8:28:36 PM UTC, Simon Wright wrote:
> May I take the opportunity of aerating a particular point the has been influencing cryptography for far too long.
> Everybody will agree that binary numbers are extremely counter intuitive and it is a prodigious task some times to change a binary number into the equivalent decimal number.  One cannot just verbalise (as they should be able to do) binary numbers as easily as decimal numbers so those magical figments of the mathematical imagination that often lead to theorems are far less likely to be born in such a constrained environment than in the denary world.   

... and a lot more b*llsh*t to which one can only say: *LOL*
But the entertainment value is high :o)

Erlo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUjzsuAAoJEDhA0GICupPBun8H/3otD9Jvx6qiFaUGic4kcS9r
wsjFUddqM1VCPfpmU3prkvFaCozLuSmjlaHQF6175UHJhA45nE/rAlcG0PqB7/Fz
9FNfaQuKd0zTrRhYQDcJ/1s+1FOz2hAJAIoFB+/or1PsrpF48hJ2Xe8uB05xqmrw
HLwjR7I2b5vCXiCC/Bov1vlu28llSc9bOtOCkg03Ha1l2ZMFzCzIpUnWAORcChPo
IyC9Ve5zqnRsEWA0OKA0e+933txxjROp1ruhcsTgdo3dSg6QNjpMTXv0jUAhfhqw
GQnE2oNB46DtOoEw6RDLxMOEB9UWAK9aVmmcvWictR8Thx2RV3biMr1HhsD7Seg=
=ZPi6
-----END PGP SIGNATURE-----

Re: Ada Connections to this Crypto.

[Pascal Obry]

Le lundi 15 décembre 2014 à 01:02 -0800, Austin Obyrne a écrit : 
> Hi,
> 
> In my view binary representation is what is holding up the progress of cryptography.  

Ok, this time you make my day :)

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Ada Connections to this Crypto.

[Shark8]

On 15-Dec-14 10:59, Austin Obyrne wrote:
> "Where are the ciphers that all these clever readers have written?
> - there blowing in their own wind can be the only answer -
> there's pedantry, politics and petulance, vicious personal attacks but no ciphers"

http://en.wikipedia.org/wiki/List_of_algorithms#Cryptography

Re: Ada Connections to this Crypto.

[Shark8]

On 15-Dec-14 02:02, Austin Obyrne wrote:
>
> In my view binary representation is what is holding up the progress of cryptography.

Why? / How?
What is the difference between 2#1010# and 10#10# and 16#A#?
NOTHING! The Ada compiler recognizes these all as ways to write "ten".
What's the difference between 3 and 三 and ٣?
NOTHING! They are all representations of the concept/number: "Three".

Thus it is immaterial if the cryptographic function was 
dreamt-up/developed-with in binary, hex, Japanese or whatever... what 
matters is the mathematics behind it.

Re: Ada Connections to this Crypto.

[Denis McMahon]

On Mon, 15 Dec 2014 14:53:05 -0700, Shark8 wrote:

> Thus it is immaterial if the cryptographic function was
> dreamt-up/developed-with in binary, hex, Japanese or whatever... what
> matters is the mathematics behind it.

And in AO's case, the mathematics is all smoke and mirrors.

If smoke := 1 and mirror := 0, does that make it binary cryptography?

-- 
Denis McMahon, denismfmcmahon@gmail.com

Re: Ada Connections to this Crypto.

[Austin Obyrne]

On Monday, December 15, 2014 7:06:56 PM UTC, Mark Carroll wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes:
> 
> > The bottom line has to be "Where are the ciphers that all these clever readers have written? - there blowing in their own wind can be the only answer - there's pedantry, politics and petulance, vicious personal attacks but no ciphers"
> >  A bit like the golfer who has a lovely set of clubs, polishes the bag , cleans and polishes his shoes, buys some snazzy outfits with a white cap, knows the rules of the game inside out panders to club politics with lots of 'me too' stuff but never hits a ball.
> 
> Not really. I would have loved to developed worthwhile ciphers. In some
> of my master's program work I developed software for generating and
> assessing block ciphers; only last year I worked on an idea for
> automating differential cryptanalysis to assist in my ideas for creating
> ciphers. (It failed miserably.) I am /not/ offering cipher designs
> because I have read enough and learned enough and tried enough to have
> found that I am simply not good enough at it: that other people in the
> field are far more skilled than I am, and that I still don't understand
> the theory well enough to devise ciphers and provide credible assurance
> of their security.
> 
> I'm not like a golfer who panders to club politics, I'm like a golfer
> who likes the game but after a lot of trying and even two rounds of
> classes still can't even hit the ball reliably and realizes that his
> efforts are best applied elsewhere. I wouldn't have responded to you at
> all had you not been persistently filling an Ada group -- something I
> /am/ interested in reading about -- with your peculiar assertions and
> misapprehensions, which I've made a good-faith constructive effort to
> help you move past.
> 
> -- Mark

Hi Mark,

I don't profess to be anything in the way of an Ada developer or a cryptography developer but when one comes up with an algorithm that is demonstrably irreversible then that's it  - the mathematics don't lie and the mathematician cannot lie successfully in the face of all the known and time proven theorems.  It's simple - anybody even a person totally unrelated to cryptography can come up with a successful algorithm - a cab driver, a doctor of medicine, anybody.  There is no apprenticeship to be served, no defence to be made for having tried, no need to vindicate oneself to so-called pros - all it needs is the mathematical proof.

Spotting bases for algorithms is an art.  It helps if one has a very broad background of *Applied maths and even then there is a specially aptitude needed.  One never sets out to write an algorithm - you keep the general idea in your head and when opportunity knocks you answer by doggedly pursuing even the slightest whiff of an idea - figment of the imagination, conjecture, copious testing, claim, theorem - that's the order.

In my view there are no associates (camp followers) of cryptography - you are in it to write algorithms - nothing else.

Mt background is in ship propulsion - I was Chief Engineer in the British Merchant Navy for most of my life - I also have a very large background in power generation stations , factories. Inspection work and much more.

My basic career qualification is more of a License (Ministry of Transport Certificate of Competency as Chief Engineer) to operate rather than an academic one and it follows an apprenticeship at the bench.  I attained a Fellowship of my Institute followed by Chartered Engineer Registration (40 years ago)  and I have studied Pure and Applied Maths on a Degree course at University.

I was pitched into cryptography accidentally when I asked another mathematician to read my invention of 'vector factoring'.  

None of this is important to the ciphers in hand - the point I am making is that the skill of spotting algorithms is dependent to a great extent on one's creative instincts in mathematics.

I my view proper cryptography does not yet exist - it will come eventually and like everything else that lasts it will be underpinned by well-established decimal mathematical methods.

Of the three disciplines that are involved i.e. cryptography, mathematics and programming the most important one is the one comes naturally to some of us - that is the  ability to spot algorithms - it can be acquired with time by others but it must be there somehow in order to write cipher algorithms.

Everything else that purports to be worth posting is just playing with the box that cryptography comes in.

No. I am not a 'nutcase' to be humoured good-naturedly - that's the face-saving escape hatch for the under-achievers to brand me as such.  Its quite amusing to hear the no-hopers spouting on about my perceived shortcomings not having written anything of note themselves.

adacrypt.

Re: Ada Connections to this Crypto.

[Natasha Kerensikova]

On 2014-12-15, Pascal Obry <pascal@obry.net> wrote:
> Le lundi 15 décembre 2014 à 01:02 -0800, Austin Obyrne a écrit : 
>> Hi,
>> 
>> In my view binary representation is what is holding up the progress
>> of cryptography.  
>
> Ok, this time you make my day :)
>
And what about dropping the binary representation of input, and instead
represent it as a point on some weird curve (let's say a fourth order
curve, so that it's not too weird) over a finite field space?

I sense a tremendous potential of breakthroughs in there...


Natasha

Re: Ada Connections to this Crypto.

[mrvmurray]

On Tuesday, 16 December 2014 10:53:04 UTC+2, Austin Obyrne  wrote:
> I don't profess to be anything in the way of an Ada developer or a cryptography
> developer but when one comes up with an algorithm that is demonstrably
> irreversible then that's it ...

Stop lying. Your cipher was bust by brute force - trivially.

> ... - the mathematics don't lie and the mathematician cannot lie successfully
> in the face of all the known and time proven theorems.

No, but you can and do. You ignore and dismiss the inconvenient facts.

> It's simple - anybody even a person totally unrelated to cryptography
> can come up with a successful algorithm - a cab driver, a doctor of
> medicine, anybody.  There is no apprenticeship to be served, no defence
> to be made for having tried, no need to vindicate oneself to so-called pros 
> - all it needs is the mathematical proof.

You do not have a mathematical proof and you never had one. You have a crap
cipher with many faults and you don't have the talent to understand these.

> Spotting bases for algorithms is an art.  It helps if one has a very broad
> background of *Applied maths and even then there is a specially aptitude 
> needed.

Which you don't have.
> One never sets out to write an algorithm - you keep the general idea in your
> head and when opportunity knocks you answer by doggedly pursuing even the
> slightest whiff of an idea - figment of the imagination, conjecture, copious
> testing, claim, theorem - that's the order.

Very little of which you did. No useful testing, no understanding of the relevant
theory, no study of the relevant background.

That could be done by a talented individual. It has not been done by you. You do
not have a broad background in any form of mathematics, in fact your mathematical
talent is horrible.

> In my view there are no associates (camp followers) of cryptography - you are
> in it to write algorithms - nothing else.

Your view is irrelevant.
 
> Mt background is in ship propulsion - I was Chief Engineer in the British Merchant
> Navy for most of my life - I also have a very large background in power generation
> stations , factories. Inspection work and much more.

But very little real mathematics, cryptography or computer science.

> My basic career qualification is more of a License (Ministry of Transport Certificate
> of Competency as Chief Engineer) to operate rather than an academic one and it
> follows an apprenticeship at the bench.  I attained a Fellowship of my Institute
> followed by Chartered Engineer Registration (40 years ago)  and I have studied
> Pure and Applied Maths on a Degree course at University.

Your university-level mathematics appears to have been forgotten. Did you pass?
Did you get the degree in Maths? Did you do maths courses at major level?

Your demonstrated understanding of number theory suggests you learned little or
have forgotten a great deal.

> I was pitched into cryptography accidentally when I asked another mathematician
> to read my invention of 'vector factoring'.

This is not a useful concept in mathematics.

> None of this is important to the ciphers in hand - the point I am making is that the
> skill of spotting algorithms is dependent to a great extent on one's creative instincts
> in mathematics.

It can be, yes.

> I my view proper cryptography does not yet exist - it will come eventually and like
> everything else that lasts it will be underpinned by well-established decimal
> mathematical methods.

With this you revert to speaking from ignorance with too much unwarranted authority.

> Of the three disciplines that are involved i.e. cryptography, mathematics and
> programming the most important one is the one comes naturally to some of us
> - that is the  ability to spot algorithms - it can be acquired with time by others
> but it must be there somehow in order to write cipher algorithms.

You miss the very important point of being able to recognise and spot problems,
which you simply can't do.

> Everything else that purports to be worth posting is just playing with the box
> that cryptography comes in.

Meaningless waffle.

> No. I am not a 'nutcase' to be humoured good-naturedly - that's the face-saving
>  escape hatch for the under-achievers to brand me as such.  Its quite amusing
> to hear the no-hopers spouting on about my perceived shortcomings not having
> written anything of note themselves.

Yeah, yeah. Go and learn some maths, and read about the subject of crypto before
spouting forth like the expert you are not.

Until you can properly define terms like "key", "key stream", "key schedule" and
so forth without demonstrating colossal cluelessness, you need to shut up and
take your place at the table like the newbie you are.

The same goes for your mathematical knowledge - your number radix confusion
is crippling your understanding.

As for computing, you program like a child, but without the learning, the willingness
to experiment and the flexibility.

M
-- 

Re: Ada Connections to this Crypto.

[john]

> Because it is a universal standard there is no need for the entities to send copies of it to each other.  This is a hugely important benefit that is invariably taken for granted because of the sheer familiarity that we all enjoy with it - i.e. because we are using 'standard' computers and 'standard' programming languages that have ASCII as the inbuilt code the intrinsic comparator for buying and selling is ASCII.

If you're interested in text encryption, why don't you use Unicode? For example UTF-32? It's also a standard and has a vastly larger character range, including all kinds of scripts from many different languages. It's not yet as ubiquitous as ASCII, but you can read Unicode text on any halfway modern PC and mobile phone and there are plenty of converters between different Unicode versions (UTF-8, UTF-16, UTF-32).

Sticking to ASCII makes your program outdated from the start.

Another thing you might want to consider are code books. You can download huge dictionary files for a language, e.g. English, and then swap words or compress words into smaller numbers using your encryption scheme based on the code book, which must be shared between the two parties. You could do this in a way that two people can agree on an arbitrary code book of their choice.

If the code book is kept secret (=huge shared secret), this can add an additional layer of security on top of the character-based encryption, and if you assign numbers to code book positions it can also compress the message tremendously.

Just some ideas/suggestions.

Re: Ada Connections to this Crypto.

[mrvmurray]

On Tuesday, 16 December 2014 13:47:27 UTC+2, jo...@peppermind.com  wrote:
> Sticking to ASCII makes your program outdated from the start.

This fellow's problem is that he has very poor computing skills (among other
issues). He thinks his ASCII-only encryption is the answer to all crypto
questions.

Unicode/UTF-* are not the answer, as he can't (and won't) learn how to do it.
In his mind, computer memory holds ASCII. Period. And he won't let go of this.

> Another thing you might want to consider are code books.

This WELL exceeds his programming capability.

M
-- 

Re: Ada Connections to this Crypto.

[Austin Obyrne]

On Tuesday, December 16, 2014 11:47:27 AM UTC, jo...@peppermind.com wrote:
> > Because it is a universal standard there is no need for the entities to send copies of it to each other.  This is a hugely important benefit that is invariably taken for granted because of the sheer familiarity that we all enjoy with it - i.e. because we are using 'standard' computers and 'standard' programming languages that have ASCII as the inbuilt code the intrinsic comparator for buying and selling is ASCII.
> 
> If you're interested in text encryption, why don't you use Unicode? For example UTF-32? It's also a standard and has a vastly larger character range, including all kinds of scripts from many different languages. It's not yet as ubiquitous as ASCII, but you can read Unicode text on any halfway modern PC and mobile phone and there are plenty of converters between different Unicode versions (UTF-8, UTF-16, UTF-32).
> 
> Sticking to ASCII makes your program outdated from the start.
> 
> Another thing you might want to consider are code books. You can download huge dictionary files for a language, e.g. English, and then swap words or compress words into smaller numbers using your encryption scheme based on the code book, which must be shared between the two parties. You could do this in a way that two people can agree on an arbitrary code book of their choice.
> 
> If the code book is kept secret (=huge shared secret), this can add an additional layer of security on top of the character-based encryption, and if you assign numbers to code book positions it can also compress the message tremendously.
> 
> Just some ideas/suggestions.

Hi Jo,

By coincidence, that scheme is already well hand - as you say it is not ubiquitous yet - a useful aside that I am promoting at times is that the entire set of code points reduces to the sixteen hexadecimal digits of Unicode (UTF 32 and none other is considered by me) and ASCII while also being within Unicode itself can be commissioned (in the West) in a surrogate role to encrypt all of Unicode code points with much greater ease than addressing each one.

Thanks - adacrypt

Re: Ada Connections to this Crypto.

[Austin Obyrne]

On Monday, December 15, 2014 7:06:56 PM UTC, Mark Carroll wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes:
> 
> > The bottom line has to be "Where are the ciphers that all these clever readers have written? - there blowing in their own wind can be the only answer - there's pedantry, politics and petulance, vicious personal attacks but no ciphers"
> >  A bit like the golfer who has a lovely set of clubs, polishes the bag , cleans and polishes his shoes, buys some snazzy outfits with a white cap, knows the rules of the game inside out panders to club politics with lots of 'me too' stuff but never hits a ball.
> 
> Not really. I would have loved to developed worthwhile ciphers. In some
> of my master's program work I developed software for generating and
> assessing block ciphers; only last year I worked on an idea for
> automating differential cryptanalysis to assist in my ideas for creating
> ciphers. (It failed miserably.) I am /not/ offering cipher designs
> because I have read enough and learned enough and tried enough to have
> found that I am simply not good enough at it: that other people in the
> field are far more skilled than I am, and that I still don't understand
> the theory well enough to devise ciphers and provide credible assurance
> of their security.
> 
> I'm not like a golfer who panders to club politics, I'm like a golfer
> who likes the game but after a lot of trying and even two rounds of
> classes still can't even hit the ball reliably and realizes that his
> efforts are best applied elsewhere. I wouldn't have responded to you at
> all had you not been persistently filling an Ada group -- something I
> /am/ interested in reading about -- with your peculiar assertions and
> misapprehensions, which I've made a good-faith constructive effort to
> help you move past.
> 
> -- Mark


Further to my earlier post - herewith a cipher that was prompted by a chance remark in a popular hand book - it took me three years before I was satisfied with the mathematics - the cipher algorithm harks back to the famous Vigenere Cipher of some 500 years ago - a more expanded description with copious explanatory pdf diagrams is available on http;//www.adacryptpages.com

adacrypt
Scalable Key Cipher. 

Copyright © 2009 Austin O'Byrne.
Last modified october 2013.

The encryption model is, 

[(Plaintext + X) + (Key +X)] mod N = residue >= 0
(N divides at least once but must divide once)
=> [ (Plaintext + X) + (Key +X)]  = N + residue mod N  >= 0

All of these variables are keys in his cipher => they must be validated therefore for a particular scope according to a table of values.

The elements of the table are positive integers. The bounds of this table of values are also tertiary key material - the bounds are arbitrarily set by the entities exchanging two suitable positive integers.  Suitable meaning positive integers that have a differential in excess of say of 100.  The entities may also stipulate a message length scope.

Key-making process.

The keys are named:

Plaintext (a numerical variable name)
Key (a numerical value)
X ( a constant value key)
N ( a modulus - a variable integer value)
Residue (instantaneous fall-out residue mod N)
n = an arbitrary scalar multiplier

The Table (bounds  700 ... 850).

PlainText     Key
---------------------------------
  700         700
  701         701
  ___         ___
  ___         ___ 
  849         849
  850         850 
----------------------------------- 

The table comprises two identical sets of positive integer elements in the range 700 to 850 (in this demonstration) those numbers being the nominated bounds of 700 and 850. Every element in the RH column is paired with every element in the LH column

'Plaintext' is drawn from Alice's encryption alphabet which is a subset of the table.
'Key' is drawn from the entire table at any moment. 

Nomenclature:

Largest valued element is called HI_NUM.
MAX_NUM = HI_NUM + 1
Lowest valued element is called LOWEST_NUM 
N =  is the instantaneous value of the modulus N
M = the scope of all anticipated message lengths => max-message-length.
n = an arbitrary scalar multiplier  

To enable N to divide every possible pairing of the elements they must each be incremented by an amount X so the table becomes,

Plaintext + X    Key + X 
--------------------------
  700 + X        700  +  X
  701 + X        701 + X
  _______        _______
  _______        _______ 
  849  + X       849 + X
  850  + X       850 + X
--------------------------


To find X :- One pass of the encryption loop by the loop counter N will lead to X.
Consider N as the counter of the eventual encryption loop being constrained to just one pass here.

For N in (X + MAX_NUM) ... 2 (X + LOWEST_NUM) Loop -- one only N
=> 2X + 2.LOWEST_NUM - (X + MAX_NUM) = 0 (0 => 1 incl.)
X + 2 .LOWEST_NUM - MAX_NUM = 0
X = MAX_NUM - 2.LOWEST_NUM 
=> X = 851 - 2x700
= 851 -1400 = - 549

This is the 'identity' X (a coined name) for this particular table (<= N = 1) 

To Find the bounds of 'N'.
X is incremented by the max message-length.
Let M = 50000 be the max-message-length
Then,
the loop  program array bounds emanate from N in the counter,

For N in (X + 50000 + Max_NUM) ... 2 (LOWEST_NUM + X + M) Loop

checking,

2 (LOWEST_NUM + X + M) - (X + 50000 + Max_NUM) = 50000 ?
2(700 - 549 +50000) - (-549 +50000 + 851)
1400 - 1098 +100000 + 549 -50000 -851 = 50000 (this is correct obviously)

Encryption:
Ciphertext = residue + n. N

Decryption:
Plaintext = Ciphertext - (n-1) . N - Key - 2X

The ciphertext is contrived to be a large integer of about 6 to 8 digits - may be positive or negative but is entirely so in a given case.

Cryptanalysis:

The ciphertext is secured by the impossibility of an adversary being able to correctly partition the integer into the subsets (residue + N) and (n-1.N).  The partitioning function can only be enabled by the intervention of the entities who must supply the keys  that enable this to be done.

adacrypt

Re: Ada Connections to this Crypto.

[mrvmurray]

On Tuesday, 16 December 2014 19:17:18 UTC+2, Austin Obyrne  wrote:
> Scalable Key Cipher. 

This is the cipher that I wrote my first brute-force cracker for. This was
more of an exercise in writing in Ada than anything else, but a quick-and-
dirty effort produced a program that cracked this in seconds.

M
-- 

Re: Ada Connections to this Crypto.

[mrvmurray]

On Tuesday, 16 December 2014 19:00:14 UTC+2, Austin Obyrne  wrote:
> By coincidence, that scheme is already well hand - as you say it is not
> ubiquitous yet - a useful aside that I am promoting at times is that the
> entire set of code points reduces to the sixteen hexadecimal digits of
> Unicode (UTF 32 and none other is considered by me) and ASCII while
> also being within Unicode itself can be commissioned (in the West) in
> a surrogate role to encrypt all of Unicode code points with much greater
> ease than addressing each one.

Please learn to write English. The above is incomprehensible gobbledegook.

M
-- 

Re: Ada Connections to this Crypto.

[Simon Clubley]

On 2014-12-16, mrvmurray@gmail.com <mrvmurray@gmail.com> wrote:
> On Tuesday, 16 December 2014 13:47:27 UTC+2, jo...@peppermind.com  wrote:
>> Sticking to ASCII makes your program outdated from the start.
>
> This fellow's problem is that he has very poor computing skills (among other
> issues). He thinks his ASCII-only encryption is the answer to all crypto
> questions.
>

I wonder if we should introduce him to full disk encryption and see how
that fits into his ASCII only world view. That should get rid of his
ASCII only concept once and for all.

Simon.

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

Re: Ada Connections to this Crypto.

[Denis McMahon]

On Wed, 17 Dec 2014 23:43:42 +0000, Simon Clubley wrote:

> On 2014-12-16, mrvmurray@gmail.com <mrvmurray@gmail.com> wrote:
>> On Tuesday, 16 December 2014 13:47:27 UTC+2, jo...@peppermind.com 
>> wrote:
>>> Sticking to ASCII makes your program outdated from the start.

>> This fellow's problem is that he has very poor computing skills (among
>> other issues). He thinks his ASCII-only encryption is the answer to all
>> crypto questions.

> I wonder if we should introduce him to full disk encryption and see how
> that fits into his ASCII only world view. That should get rid of his
> ASCII only concept once and for all.

Nope, he'll simply respond that whole disk encryption can not be the 
solution when the problem with current encryption systems is that they 
have to work with binary number systems.

Therefore, in his worldview, the solution is to convert the contents of 
the disk to ascii and then encrypt it at a 10:1 size expansion.

Of course, the fact that at least one other poster has been able to 
bruteforce his encryption already means nothing to him, he is still of 
the unshakeable belief that the problem with current cryptosystems is 
that they use binary numbers, and that his trivially easy to bruteforce 
system is perfect and unbreakable.

I'm still waiting for him to demonstrate, rather than theorise, the 
"inherent fallibility of binary based cryptosystems to attack".

I paraphrase his comments, I hope I present the idea of what he keeps 
saying fairly accurately.

-- 
Denis McMahon, denismfmcmahon@gmail.com

Re: Ada Connections to this Crypto.

[MM]

On Thursday, 18 December 2014 03:08:05 UTC+2, Denis McMahon  wrote:
> I'm still waiting for him to demonstrate, rather than theorise, the 
> "inherent fallibility of binary based cryptosystems to attack".

Don't hold your breath.

> I paraphrase his comments, I hope I present the idea of what he keeps 
> saying fairly accurately.

No more inaccurately than anyone else. He contradicts himself so often
that it is nearly impossible to understand what he really means most of
the time. The best you'll manage is a sort of general overview where his
most blatant ideas remain unchangeable, but the details are somewhere
between completely mutable and opaque.

M
-- 

Re: Ada Connections to this Crypto.

[Austin Obyrne]

On Thursday, December 18, 2014 1:08:05 AM UTC, Denis McMahon wrote:
> On Wed, 17 Dec 2014 23:43:42 +0000, Simon Clubley wrote:
> 
> > On 2014-12-16, mrvmurray@gmail.com <mrvmurray@gmail.com> wrote:
> >> On Tuesday, 16 December 2014 13:47:27 UTC+2, jo...@peppermind.com 
> >> wrote:
> >>> Sticking to ASCII makes your program outdated from the start.
> 
> >> This fellow's problem is that he has very poor computing skills (among
> >> other issues). He thinks his ASCII-only encryption is the answer to all
> >> crypto questions.
> 
> > I wonder if we should introduce him to full disk encryption and see how
> > that fits into his ASCII only world view. That should get rid of his
> > ASCII only concept once and for all.
> 
> Nope, he'll simply respond that whole disk encryption can not be the 
> solution when the problem with current encryption systems is that they 
> have to work with binary number systems.
> 
> Therefore, in his worldview, the solution is to convert the contents of 
> the disk to ascii and then encrypt it at a 10:1 size expansion.
> 
> Of course, the fact that at least one other poster has been able to 
> bruteforce his encryption already means nothing to him, he is still of 
> the unshakeable belief that the problem with current cryptosystems is 
> that they use binary numbers, and that his trivially easy to bruteforce 
> system is perfect and unbreakable.
> 
> I'm still waiting for him to demonstrate, rather than theorise, the 
> "inherent fallibility of binary based cryptosystems to attack".
> 
> I paraphrase his comments, I hope I present the idea of what he keeps 
> saying fairly accurately.
> 
> -- 
> Denis McMahon, denismfmcmahon@gmail.com

I am prepared to send you a batch of ciphertext for brute forcing if you can set up an honest adjudicating team who will oversee it for fair play.

Empty claims of brute force programs are legion - terminating them with a unique and correct outcome is something else.

Waiting to hear.

adacrypt

Re: Ada Connections to this Crypto.

[MM]

On Thursday, 18 December 2014 09:37:06 UTC+2, Austin Obyrne  wrote:
> I am prepared to send you a batch of ciphertext for brute forcing if you
> can set up an honest adjudicating team who will oversee it for fair play.

The group can do the adjudicating, as sci.crypt did last time. Remember
that you were called a cheat there? (Not only by me).

This time, put your money where your mouth is is, and make is substantial,
and propose an escrow agent. I want to take money out of your pocket
for my time.

Paolo's challenge procedure is sufficient; you have been sent it enough
times. Do your homework, and go and find it (again).

A challenge does not begin until you agree to ALL of the rules and your
challenger(s) agree to the escrow agent and the sum offered.

I will ignore any attempt at a challenge where these conditions are not met.

M
-- 

Re: Ada Connections to this Crypto.

[Denis McMahon]

On Wed, 17 Dec 2014 23:37:05 -0800, Austin Obyrne wrote:

> I am prepared to send you a batch of ciphertext for brute forcing if you
> can set up an honest adjudicating team who will oversee it for fair
> play.

What adjudicating team do you need? The fact that the plaintext can be 
created from the ciphertext is sufficient to prove the brute force attack.

Publishing the plaintext (or a link to it) here here would be proof of 
the success of the bruteforce attack.

To put it another way, if all you supply me with is the ciphertext and I 
can publish the plaintext, then obviously the cipher has failed!

-- 
Denis McMahon, denismfmcmahon@gmail.com

Re: Ada Connections to this Crypto.

[MM]

On Friday, 19 December 2014 01:25:36 UTC+2, Denis McMahon  wrote:
> What adjudicating team do you need? The fact that the plaintext can be 
> created from the ciphertext is sufficient to prove the brute force attack.

Not to O'Byrne it isn't.

> Publishing the plaintext (or a link to it) here here would be proof of 
> the success of the bruteforce attack.

So you'd think.

> To put it another way, if all you supply me with is the ciphertext and I 
> can publish the plaintext, then obviously the cipher has failed!

Not the way O'Byrne plays the game.

A year or two back, a challenge was to break a ciphertext given that
"two small integers"[*] were sufficient to provide the security. He cheated
by not sticking to the game plan. His previously cleartext "scrambling
parameters", Which were supposed to be cleartext knowledge, suddenly
became secret, and he changed them surreptitiously.

He therefore created a cipher text that his "Bob" couldn't read, and for 
which my brute-force program needed rewriting. I looked at how to do this,
and while I didn't complete the job, I saw that his ciphertext, when plotted
as a graph, leaked those parameters heavily, thus offering a clear attack.

I demonstrated my program on his example plaintext/ciphertext examples,
where it did not need his "small integers" to decrypt, and did this by brute
force.

He made some cockamamy excuse about "needing to protect his cipher",
showing that he had no clue about how such challenges work. He ignored
the fact that my brute-force program could break his example ciphertexts
in seconds. A previous challenge with his other cipher solicited a similar
/post hoc/ excuse for that cipher's failure.

I didn't see much point in continuing, at that point. If he wasn't going to
display any integrity, then the game was over.

This is why he needs an adjudicator, and this is why the challenge reward
needs to be in escrow and substantial.

M

[*] "Two small integers" turned out to be "three small integers", but he kept
referring to two numbers, not three. You may have noticed in his writing that
he doesn't often make a lot of sense. If you could be bothered to compare
his verbal description his cipher with the Ada code, its clear he is very
confused about a lot of things.

Re: Ada Connections to this Crypto.

[Austin Obyrne]

On Thursday, December 18, 2014 11:25:36 PM UTC, Denis McMahon wrote:
> On Wed, 17 Dec 2014 23:37:05 -0800, Austin Obyrne wrote:
> 
> > I am prepared to send you a batch of ciphertext for brute forcing if you
> > can set up an honest adjudicating team who will oversee it for fair
> > play.
> 
> What adjudicating team do you need? The fact that the plaintext can be 
> created from the ciphertext is sufficient to prove the brute force attack.
> 
> Publishing the plaintext (or a link to it) here here would be proof of 
> the success of the bruteforce attack.
> 
> To put it another way, if all you supply me with is the ciphertext and I 
> can publish the plaintext, then obviously the cipher has failed!
> 
> -- 
> Denis McMahon, denismfmcmahon@gmail.com

Yeah, that is what I also maintain but this fellow claims he was cheated in a similiar experiment some years ago.  I mean to close the escape route this time by engaging outsiders to monitor the situation.

Let me know if you want me to go ahead - shall I send you a small batch of ciphertext ? - Austin O' Byrne

Re: Ada Connections to this Crypto.

[MM]

On Friday, 19 December 2014 10:09:39 UTC+2, Austin Obyrne  wrote:
> Yeah, that is what I also maintain but this fellow claims he was cheated
> in a similiar experiment some years ago.  I mean to close the escape
> route this time by engaging outsiders to monitor the situation.
> 
> Let me know if you want me to go ahead - shall I send you a small
> batch of ciphertext ? - Austin O' Byrne

Learn what Kerckhoff's principle is first:
http://en.wikipedia.org/wiki/Kerckhoffs%27s_principle

M
-- 

Re: Ada Connections to this Crypto.

[Austin Obyrne]

On Friday, December 19, 2014 8:24:18 AM UTC, MM wrote:
> On Friday, 19 December 2014 10:09:39 UTC+2, Austin Obyrne  wrote:
> > Yeah, that is what I also maintain but this fellow claims he was cheated
> > in a similiar experiment some years ago.  I mean to close the escape
> > route this time by engaging outsiders to monitor the situation.
> > 
> > Let me know if you want me to go ahead - shall I send you a small
> > batch of ciphertext ? - Austin O' Byrne
> 
> Learn what Kerckhoff's principle is first:
> http://en.wikipedia.org/wiki/Kerckhoffs%27s_principle
> 
> M
> --
Countdown starts now - copy ciphertext has been sent to another reader in this group who should remain anonymous until you publish your brute force results.

Herewith the ciphertext for cryptanalysing -(these integers go in groups of three being the coefficients of vectors)

adacrypt

(820       4889       4221)     (975       5165       4001)  etc  1040       5411       3715        951       5277       3758        677       4548       4594        795       4864       4274       1065       5529       3584       1034       5346       3835        921       5178       3947        818       5078       4072       1057       5469       3858        757       4806       4446       1071       5552       3725        980       5354       3781        900       5129       4154        934       5301       3960       1056       5571       3551        780       5016       4259        689       4702       4585        591       4725       4487        981       5205       4007        659       4705       4582       1069       5405       3870        893       5203       3919        756       4816       4445        658       4702       4581        590       4649       4486       1055       5421       3856        924       5302       3950        809       4934       4393        979       5364       3786        854       5245       3880        582       4703       4478        942       5370       3743        621       4828       4310        742       5146       3996        924       5436       3599        853       5247       3879        655       4927       4239        720       5079       4031        950       5369       3751        855       5257       3881       1031       5558       3568        939       5405       3746        662       4892       4159        620       4872       4204        852       5268       3878        948       5378       3749        660       4949       4157        657       4950       4154        946       5406       3747        961       5441       3636        660       4895       4244        665       4929       4144        599       4807       4288        515       4653       4411        840       5201       3866        855       5254       3869        888       5447       3689        622       4774       4311        850       4882       4434        842       4717       4624        950       5142       4204       1161       5358       3962        902       4970       4399       1095       5227       4121       1073       5406       3880       1101       5270       4115       1101       5266       4127        882       4934       4451        836       4851       4525        941       5034       4249       1180       5400       3981        830       4737       4678       1010       5209       4036        939       4976       4436        835       4710       4617       1003       5251       4017       1068       5273       4082        951       5013       4430       1227       5561       3746        835       4989       4314        990       5384       3791       1018       5495       3693        804       4838       4388        929       5251       3955        703       4870       4287       1037       5361       3844        985       5295       4011        613       4639       4536       1064       5391       3865        954       5211       4097        763       4909       4242       1104       5486       3779        900       5286       3926        806       4854       4390       1040       5446       3835        886       5236       3918       1063       5457       3864        754       4994       4251       1059       5385       3860        797       4940       4381        730       4840       4314        817       4985       4296       1019       5550       3694        923       5146       4066        928       5311       3954        885       5234       3917        744       4875       4433        915       5309       3947        988       5386       3789        895       5157       4149        734       4974       4231        918       5213       3944       1104       5607       3599        735       5012       4214        751       4853       4335        815       5049       4126        816       5008       4295       1016       5616       3691        991       5426       4017        720       4946       4409        919       5323       3945        894       5419       3908       1041       5570       3842       1062       5688       3557        961       5428       3987        831       5239       4142        971       5505       3778        717       4877       4499        896       5235       4150        785       5111       4282        938       5421       3964       1009       5470       3816        907       5427       3921        960       5383       3986        698       5038       4282        819       5048       4298       1060       5744       3597       1005       5510       3806        809       4947       4477

Re: Ada Connections to this Crypto.

[MM]

On Friday, 19 December 2014 11:02:30 UTC+2, Austin Obyrne  wrote:
> Countdown starts now

No thanks.

M

Re: Ada Connections to this Crypto.

[Austin Obyrne]

On Friday, December 19, 2014 9:02:30 AM UTC, Austin Obyrne wrote:
> On Friday, December 19, 2014 8:24:18 AM UTC, MM wrote:
> > On Friday, 19 December 2014 10:09:39 UTC+2, Austin Obyrne  wrote:
> > > Yeah, that is what I also maintain but this fellow claims he was cheated
> > > in a similiar experiment some years ago.  I mean to close the escape
> > > route this time by engaging outsiders to monitor the situation.
> > > 
> > > Let me know if you want me to go ahead - shall I send you a small
> > > batch of ciphertext ? - Austin O' Byrne
> > 
> > Learn what Kerckhoff's principle is first:
> > http://en.wikipedia.org/wiki/Kerckhoffs%27s_principle
> > 
> > M
> > --
> Countdown starts now - copy ciphertext has been sent to another reader in this group who should remain anonymous until you publish your brute force results.
> 
> Herewith the ciphertext for cryptanalysing -(these integers go in groups of three being the coefficients of vectors)
> 
> adacrypt
> 
> (820       4889       4221)     (975       5165       4001)  etc  1040       5411       3715        951       5277       3758        677       4548       4594        795       4864       4274       1065       5529       3584       1034       5346       3835        921       5178       3947        818       5078       4072       1057       5469       3858        757       4806       4446       1071       5552       3725        980       5354       3781        900       5129       4154        934       5301       3960       1056       5571       3551        780       5016       4259        689       4702       4585        591       4725       4487        981       5205       4007        659       4705       4582       1069       5405       3870        893       5203       3919        756       4816       4445        658       4702       4581        590       4649       4486       1055       5421       3856        924       5302       3950        809       4934       4393        979       5364       3786        854       5245       3880        582       4703       4478        942       5370       3743        621       4828       4310        742       5146       3996        924       5436       3599        853       5247       3879        655       4927       4239        720       5079       4031        950       5369       3751        855       5257       3881       1031       5558       3568        939       5405       3746        662       4892       4159        620       4872       4204        852       5268       3878        948       5378       3749        660       4949       4157        657       4950       4154        946       5406       3747        961       5441       3636        660       4895       4244        665       4929       4144        599       4807       4288        515       4653       4411        840       5201       3866        855       5254       3869        888       5447       3689        622       4774       4311        850       4882       4434        842       4717       4624        950       5142       4204       1161       5358       3962        902       4970       4399       1095       5227       4121       1073       5406       3880       1101       5270       4115       1101       5266       4127        882       4934       4451        836       4851       4525        941       5034       4249       1180       5400       3981        830       4737       4678       1010       5209       4036        939       4976       4436        835       4710       4617       1003       5251       4017       1068       5273       4082        951       5013       4430       1227       5561       3746        835       4989       4314        990       5384       3791       1018       5495       3693        804       4838       4388        929       5251       3955        703       4870       4287       1037       5361       3844        985       5295       4011        613       4639       4536       1064       5391       3865        954       5211       4097        763       4909       4242       1104       5486       3779        900       5286       3926        806       4854       4390       1040       5446       3835        886       5236       3918       1063       5457       3864        754       4994       4251       1059       5385       3860        797       4940       4381        730       4840       4314        817       4985       4296       1019       5550       3694        923       5146       4066        928       5311       3954        885       5234       3917        744       4875       4433        915       5309       3947        988       5386       3789        895       5157       4149        734       4974       4231        918       5213       3944       1104       5607       3599        735       5012       4214        751       4853       4335        815       5049       4126        816       5008       4295       1016       5616       3691        991       5426       4017        720       4946       4409        919       5323       3945        894       5419       3908       1041       5570       3842       1062       5688       3557        961       5428       3987        831       5239       4142        971       5505       3778        717       4877       4499        896       5235       4150        785       5111       4282        938       5421       3964       1009       5470       3816        907       5427       3921        960       5383       3986        698       5038       4282        819       5048       4298       1060       5744       3597       1005       5510       3806        809       4947       4477

He concedes defeat - He should do now what Tom St Dennis (Canada) told him to do some years ago - too rude to repeat here - adacrypt

Re: Ada Connections to this Crypto.

[MM]

On Friday, 19 December 2014 11:50:37 UTC+2, Austin Obyrne  wrote:
> He concedes defeat - He should do now what Tom St Dennis (Canada)
> told him to do some years ago - too rude to repeat here - adacrypt

I did no such thing. I'm refusing to play a mugs' game for a reason I've
already given you.

If you are going to play, agree to the rules FIRST. Sending out ciphergrams
is well down the list. Also I don't see any prize money in escrow. As I'm
on holiday, and I have other things to do. I'll only take on your dishonesty
if it is a cast-iron case that you can't cheat. In this case I don't even know
what cipher you're using, and there is no open Alice<->Bob exchange,
there is no declaration of what you think they keys are this time and there
is every indication that you will make surreptitious changes to give the 
illusion of winning.

You forget that most folks in sci.crypt have told you get lost over the years.
Add hypocrisy to your list of faults, and don't get prissy about swearing, as
you are no angel yourself.

M
-- 

Re: Ada Connections to this Crypto.

[Denis McMahon]

On Fri, 19 Dec 2014 02:18:38 -0800, MM wrote:

> I'll only take
> on your dishonesty if it is a cast-iron case that you can't cheat.

Hmm, he sent me a plaintext / adacrypt pair, the adacrypt of which is (if 
I understand correctly):

(820, 4889, 4221)
(975, 5165, 4001)
(1040, 5411, 3715)
(951, 5277, 3758)
(677, 4548, 4594)
(795, 4864, 4274)
(1065, 5529, 3584)
(1034, 5346, 3835)
(921, 5178, 3947)
(818, 5078, 4072)
(1057, 5469, 3858)
(757, 4806, 4446)
(1071, 5552, 3725)
(980, 5354, 3781)
(900, 5129, 4154)
(934, 5301, 3960)
(1056, 5571, 3551)
(780, 5016, 4259)
(689, 4702, 4585)
(591, 4725, 4487)
(981, 5205, 4007)
(659, 4705, 4582)
(1069, 5405, 3870)
(893, 5203, 3919)
(756, 4816, 4445)
(658, 4702, 4581)
(590, 4649, 4486)
(1055, 5421, 3856)
(924, 5302, 3950)
(809, 4934, 4393)
(979, 5364, 3786)
(854, 5245, 3880)
(582, 4703, 4478)
(942, 5370, 3743)
(621, 4828, 4310)
(742, 5146, 3996)
(924, 5436, 3599)
(853, 5247, 3879)
(655, 4927, 4239)
(720, 5079, 4031)
(950, 5369, 3751)
(855, 5257, 3881)
(1031, 5558, 3568)
(939, 5405, 3746)
(662, 4892, 4159)
(620, 4872, 4204)
(852, 5268, 3878)
(948, 5378, 3749)
(660, 4949, 4157)
(657, 4950, 4154)
(946, 5406, 3747)
(961, 5441, 3636)
(660, 4895, 4244)
(665, 4929, 4144)
(599, 4807, 4288)
(515, 4653, 4411)
(840, 5201, 3866)
(855, 5254, 3869)
(888, 5447, 3689)
(622, 4774, 4311)
(850, 4882, 4434)
(842, 4717, 4624)
(950, 5142, 4204)
(1161, 5358, 3962)
(902, 4970, 4399)
(1095, 5227, 4121)
(1073, 5406, 3880)
(1101, 5270, 4115)
(1101, 5266, 4127)
(882, 4934, 4451)
(836, 4851, 4525)
(941, 5034, 4249)
(1180, 5400, 3981)
(830, 4737, 4678)
(1010, 5209, 4036)
(939, 4976, 4436)
(835, 4710, 4617)
(1003, 5251, 4017)
(1068, 5273, 4082)
(951, 5013, 4430)
(1227, 5561, 3746)
(835, 4989, 4314)
(990, 5384, 3791)
(1018, 5495, 3693)
(804, 4838, 4388)
(929, 5251, 3955)
(703, 4870, 4287)
(1037, 5361, 3844)
(985, 5295, 4011)
(613, 4639, 4536)
(1064, 5391, 3865)
(954, 5211, 4097)
(763, 4909, 4242)
(1104, 5486, 3779)
(900, 5286, 3926)
(806, 4854, 4390)
(1040, 5446, 3835)
(886, 5236, 3918)
(1063, 5457, 3864)
(754, 4994, 4251)
(1059, 5385, 3860)
(797, 4940, 4381)
(730, 4840, 4314)
(817, 4985, 4296)
(1019, 5550, 3694)
(923, 5146, 4066)
(928, 5311, 3954)
(885, 5234, 3917)
(744, 4875, 4433)
(915, 5309, 3947)
(988, 5386, 3789)
(895, 5157, 4149)
(734, 4974, 4231)
(918, 5213, 3944)
(1104, 5607, 3599)
(735, 5012, 4214)
(751, 4853, 4335)
(815, 5049, 4126)
(816, 5008, 4295)
(1016, 5616, 3691)
(991, 5426, 4017)
(720, 4946, 4409)
(919, 5323, 3945)
(894, 5419, 3908)
(1041, 5570, 3842)
(1062, 5688, 3557)
(961, 5428, 3987)
(831, 5239, 4142)
(971, 5505, 3778)
(717, 4877, 4499)
(896, 5235, 4150)
(785, 5111, 4282)
(938, 5421, 3964)
(1009, 5470, 3816)
(907, 5427, 3921)
(960, 5383, 3986)
(698, 5038, 4282)
(819, 5048, 4298)
(1060, 5744, 3597)
(1005, 5510, 3806)
(809, 4947, 4477)

The string length of the plaintext appears to match the number of integer 
triples.

-- 
Denis McMahon, denismfmcmahon@gmail.com

Re: Ada Connections to this Crypto.

[MM]

On Friday, 19 December 2014 18:50:09 UTC+2, Denis McMahon  wrote:
> On Fri, 19 Dec 2014 02:18:38 -0800, MM wrote:
> 
> > I'll only take
> > on your dishonesty if it is a cast-iron case that you can't cheat.
> 
> Hmm, he sent me a plaintext / adacrypt pair, the adacrypt of which is (if 
> I understand correctly):

For O'Byrne, thats Still not good enough, and I have said so. I don't know
exactly what cipher he used (he fiddles with these, quite a bit, so exact
version is relevant).

He hasn't yet disclosed the variables he considers to be secret key as
opposed to the ones that are cipher-invariant.

In short, he has not satisfied the requirements of Kerckhoffs' principles.

As I already broke his cipher (different variant) and he ignored that, I see
little need to break this one for him without being paid, hence my earlier
request for a large sum of money in escrow.

M
-- 

Re: Ada Connections to this Crypto.

[MM]

On Friday, 19 December 2014 19:57:39 UTC+2, MM  wrote:
> As I already broke his cipher (different variant) and he ignored that, ...

This is supported over in sci.crypt:
https://groups.google.com/d/msg/sci.crypt/-C0-Cbj8yMw/EeJoB6JraqcJ

M
-- 

Re: Ada Connections to this Crypto.

[Dennis Lee Bieber]

On Fri, 19 Dec 2014 16:49:47 +0000 (UTC), Denis McMahon
<denismfmcmahon@gmail.com> declaimed the following:


>Hmm, he sent me a plaintext / adacrypt pair, the adacrypt of which is (if 
>I understand correctly):
>
>(820, 4889, 4221)
	<snip>
>(809, 4947, 4477)
>
>The string length of the plaintext appears to match the number of integer 
>triples.

	Ah, only a 6X expansion factor presuming the real values are 16-bit
integers (they're too large for a byte, but none have gone high enough to
require more than 16-bits... Based on the visual scan, 13-bit unsigned is
sufficient). I'll ignore the ~15X expansion for the decimal ASCII he is so
enamored of...
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Ada Connections to this Crypto.

[MM]

On Saturday, 20 December 2014 18:57:27 UTC+2, Dennis Lee Bieber  wrote:
> 	Ah, only a 6X expansion factor presuming the real values are 16-bit
> integers (they're too large for a byte, but none have gone high enough to
> require more than 16-bits... Based on the visual scan, 13-bit unsigned is
> sufficient). I'll ignore the ~15X expansion for the decimal ASCII he is so
> enamored of...

No, they are regular integers. The reduction in length is cunning choice
of encryption parameters resulting in a desired short output from a regular
ada.integer_text_io.put()n usage.

He's not nearly good enough of a programmer to constrain his output to
GF(2^8) or anything sane like that.

M
-- 

Re: Ada Connections to this Crypto.

[Denis McMahon]

On Tue, 16 Dec 2014 00:53:03 -0800, Austin Obyrne wrote:

> I don't profess to be anything in the way of an Ada developer or a
> cryptography developer but when one comes up with an algorithm that is
> demonstrably irreversible then that's it...

No, that's not it.

A fairly basic analysis of adacrypt shows that irrespective of whether it 
is a secure encryption system or not, it fails to meet common user 
requirements for encryption in at least 5 very fundamental ways:

----------------------------------------------------------------

(1) Key management.

It appears that your adacrypt incoporates the key in the compiled program 
as a piece of ada code. This means that any two people who wish to 
exchange data using this encryption both need to compile their code 
against the same key files (you appear to call these four files 
Alices_Digital_Signature.adb, Alices_Encryption_Numbers.adb, 
Alices_Digital_Signature.ads, and Alices_Encryption_Numbers.ads).

This is a wholly unacceptable means of operation of an encryption system, 
as the number of copies of the encryption and decryption programs that 
each user has expands as the number of people using the encryption.

You should re-write your code in such a way that each user only needs a 
single copy each of the encryption and decryption code, and specifies the 
appropriate key file(s) to use at run time.

(2) The Authenticity Concept

Current encryption methods support proof of authenticity as well as 
protection from eavesdropping, using the public / private key pair. For 
example, if Alice encrypts data using Bob's public key and Alice's 
private key, then the data can only be unencrypted using, in the correct 
order, Bob's private key and Alice's public key. This means that only Bob 
can recover the data (by using his private key), and that he knows it was 
genuinely from Alice (as he also required her public key, proving it was 
encrypted with her private key).

It appears that adacrypt uses a single key per user, so that if Jim 
exchanges encrypted data with Alice using Alice's key, and with Bob using 
Bob's key, he can then pretend to be Alice to Bob, or pretend to be Bob 
to Alice.

The only solution to this in Adacrypt is for each pair of people to have 
a separate key, which creates another key administration issue, namely 
that every pair of people have to agree on a unique to that pair key, 
instead of each person having a two part public / private key, the public 
part they can share with all and sundry as long as they keep the private 
part secret to themselves.

(3) Character Set Limitation

Current encryption systems support data where each character is in the 
ascii range 0 .. 255 inclusive. Your adacrypt code is currently limited 
to data where each character is in a restricted subset of this range, 
apparently 30 .. 129. As has been explained to you in the past on 
multiple occasions, in this area your code represents a retrograde step 
when compared with existing cryptosystems, and until you can resolve this 
issue the only person who it appears will be using your code is yourself.

(4) Streaming Communication

Current encryption requirements are generally internet based, and relate 
to the encryption of data streams between two users. Until such time as 
you are able to write your code to provide for such a usage case, your 
encryption system, no matter how wonderful it is, will be of little or no 
interest to anyone who wants to encrypt data.

(5) Data Expansion.

On a small sample of data provided by you, an expansion factor in the 
volume of data to be transmitted and hence the bandwidth required of 14 
was observed. This is wholly unacceptable to the majority of users. 
Modern cryptosystems tend to have an overhead of the order of less than 
10% of the amount of data to be transmitted, rather than 1300%. Again, 
should you wish your cryptosystem to be adopted you need to address this 
issue, rather than just saying in a rather dismissive manner "buy more 
bandwidth / hard disks".

----------------------------------------------------------------

Note that these are 5 very fundamental issues (and there may well be 
others) that will prevent the uptake of adacrypt either commercially or 
through the FOSS movement, and are wholly irrelevant of whether it is a 
secure encryption system or not. Only if you can successfully address 
these issues are people likely to be interested in even considering 
whether it is a viable encryption system or not.

Your continued dismissal of these issues is ensuring that adacrypt will 
never be recognised as an encryption system. The solution to this issue 
is in your hands and your hands alone, you must address and resolve these 
issues to make adacrypt an encryption system that has the usability 
features that encryption users insist upon.

-- 
Denis McMahon, denismfmcmahon@gmail.com