On 11/02/2012 13:34, adacrypt wrote:
> Thanks for your advice re. LyX and MikTex – I have installed these now
> and will start familiarising myself with it straight away.
OK - be careful not to assume that has much in commom with standard
WYSIWYG word processors. It is NOT WYSIWYG; layout and font decisions
happen at print time, not edit time. If you get used to the idea that
LaTeX has more in common with programming than editing, where LyX
disguises this just a bit, then you'll be OK.
Amazon sell a few LaTeX books; there are a bunch of them that are often
sold together; Lamport, Goossens and Kopka are three books that are on
many LaTeX-users' shelves, and the combined price is not bad.
> Re “Skew Line Encryptions” – I could change your mind in the space of
> just one hour of one-to-one if that was possible
I would be happy to listen, if this was to be a dialogue, not a lecture;
IE I also get to have my input taken seriously.
> *This is extremely difficult to discuss from a distance.
Not my experience; if one listens as much as one speaks, long-distance
discussion does not have to be especially hard.
> For instance, the first step in disseminating this crypto is for me to
> sell the new mathematics to professional mathematics over here. That
> has only just started. Trying to convince somebody such as your self
> from a distance is just too much.
Have professionals not already explained what they need? Have you taken
any of their comments into account?
What do the "buyers" actually want? have you researched your
marketplace?
> The application of this to cryptography is very convincing once you
> understand it.
Careful of circular logic:
Premiss 1: If you understand this cryptography, you will
understand how good it is.
Premiss 2: You think this cryptography is bad.
Conclusion: You don't understand this cryptography.
The premisses and the conclusion rely on a fallacy and a highly
questionable hidden premiss:
Premiss 0: This cryptography is undeniably good
First demonstrate premiss 0. So far this is an assertion, and you are
ignoring counterevidence.
Then tackle Premiss 1; it is a "poisoning the well" fallacy; you are
setting yourself up to discredit anyone who disagrees with you as
simply not understanding you, and dismissing the notion that they
may have valid objections.
It it not my responsibility to understand it, it is yours to prove it,
and dismissing inconvenient counter-evidence is not the way to do this.
> Randomness is secondary really.
Your code and argument heavily use a strange understanding
of randomness; if, as you say above, this is seconday, why not
remove it altogether and just expose the primary debate?
> You are looking at the wrong ciphers at your end.
>
> See the package “Free Software - Gnu General Public License – Skew
> Line Encryptions. etc -
Er, thats what I am looking at.
> See in particular the Ada packages there regarding keysets such as,
> encryption numbers, change-of-origins etc for your analysis but note
> well that this cipher does not depend on randomness alone although it
> is important in a secondary role to obviate statistical mapping of the
> ciphertext as the last ditch attack by a cryptanalyst.
You are trying to show "vector cryptography" right? For me to look at
that, I have to download some 10's of MB of stuff, the HUGE majority of
which I delete straight away.
I don't need an Ada compiler, I have one! Put that up for download by
all means, but please don't pad every darn zipfile with it; let folks
download it _once_if_they_need_it_.
Remove all the generated files (*.exe *.ali *.o *.c), and please remove
duplicate files. All the *_mark*.adb files with only comment or other
minor differences are a waste of my time to read.
The reason for the "tutorial" directory is unclear; it looks like more
duplicates and padding; more near identical code to plough through,
looking for (sometimes non-existant) differences.
PLEASE PLEASE PLEASE simplify the code, DRASTICALLY; if you want me to
read it and appreciate your work, please don't make it hard for me:
o Write proper documentation.
o Separate out functions into separate files, AND reuse these
instead of copying them the whole time.
o Pick a code style and stick to it; haphazard code is hard to read.
Write idiomatic code; your "key function" class things are simply
bizarre; rewrite those as static arrays - that way they are faster
and simpler.
o Remove all code that isn't demonstrating your core concepts. In
fact review the lot and remove all "do-nothing" code, its only
acting as a barrier to acceptance.
o Abstract properly; writing a simple vector class is no harder than
what you've already done; I did it in 20 lines or so.
o Use variables that correspond to the documentation, and that
otherwise make sense. Use them in a consistent way.
o Drop "baggage"; your ASCII-only fixation, for example.
> I cannot keep up any tit-for-tat correspondence on this stuff because
> it inevitably becomes acrimonious after a few exchanges because of the
> misunderstandings that must always inevitably arise.
Do you want help from people? They (we!) are doing this for free in
valuable spare time. Please show some respect by not making it hard,
entering into dialogue and listening as much as you talk.
> This requires a lot of chalk and talk in a classroom - there is no
> alternative which is why I am try to learn desk top publishing hoping
> that this might solve the problem.
A problem is that your program and your existant explanation do not
correspond; your documentation talks about vectors; your program spends
99% of its code on shuffling arrays, and obfuscates the vector
code so severely that it takes a VERY bored person[*] to be interested
enough to figure it out. The fact that you are happy with the code is
one thing; you now want other people to accept it; have the good grace
to present them with polished work, not the current overwhelming mess.
I've rewritten the skew-line encryptor using most of the above code
improvements. It produces the same output as yours (your decryptor can
decrypt its output), and it clarifies the vector work into about 5 lines
of easy-to-find code.
Would you like to see this?