Key SetUp
WTShaw
the key without having to write it down, and it should be easy to
change to a different key, " and "...the system should not cause
mental strain, and should not require following a long and complicated
procedure." To clarify the last quote for those referencing the
source, for encryption and/or encryption to occur, key(s) setup is
part of those processes although setup can be handled separately from
them, and should of course meet the same above criteria for relative
hands-on simplicity.
Savard reminds us of what is generally accepted, "That the security of
a cipher system should depend on the key and not the algorithm." Also
he states, "...it seems that for a cipher to remain unbreakable by
today's standards, the algorithm used would have to be intricate and
complicated."
The disconnect here is that a relatively simple encryption method can
be utilized quite effectively if the products of a key setup algorithm
are adequate to hide the key(s) source(s), the generated keys being
made easy to modify at the setup level as the qualifying encryptive
algorithm adequately protects the operational key produced by that
setup. This may sound in itself complicated but computers can take
care of the details so that a moderately intelligent user can easily
follow through.
Of several families of key generation methods, a good one is to hash
texts to produce stacks of permutations for use as keys. Those that
pretend that they can solve anything are generally unfamiliar with
deranged sets, hashed texts, and the chaining that can be used
effectively therewith nor of higher ways to mask such keys. Several
options remain in these matters available to the programmer. An
extensive key can be made simple to remember, but not if you are
unaware that a specific protocol in play or of facilitating functional
programs of which there are almost no hard limits. Those that argue
for algorithm transparency may demand key setup transparency as well
but I would rather use that common prejudice that defines these as
different processes to lever folks into the situation of saying
something is unimportant while sneakily begging for the details of it,
logical fun for all.
Using a more complicated encryptive algorithm can be further enhansed
with better key setup as well, but that is beyond this posting,
excessive, defiant, and daring piling on.
As to encryption programming methods, the options should be as
universal as possible whereas modern computers likely can handle a
variety of source codes. My preferences these days include
javascript. Savard likes BASIC but even as I have used in it in a
compiled form foreign to Microsoft users, it lacks a universal nature.
Some arguments are for Python. I am sure that the future can furnish
more good choices if efforts to dumb-down such means are resisted.
Tom St Denis
> Savard reminds us of what is generally accepted, "That the security of
> a cipher system should depend on the key and not the algorithm." Also
> he states, "...it seems that for a cipher to remain unbreakable by
> today's standards, the algorithm used would have to be intricate and
> complicated."
If he actually wrote that [citation please?] he's certainly wrong.
RC5 is really easy to memorize and for all practical considerations
the 16-round 32-bit word variant is secure against all known attacks.
XTEA was another such algorithm. So is RC4, and IDEA. On the
asymmetric side, DSA, ElGamal, and RSA aren't that complicated.
We as practitioners don't tend to implement things one-off from memory
because that would be ridiculously error prone.
But as a general truth, ciphers do NOT need to be complicated to be
secure.
Tom
adacrypt
Scrambling the raw data before the encryption transformation is in my
view to be recommended and then the encryption algorithm becomes
almost benign - there is no doubt in my mind that when ASCII and
computing arrived almost simultaneously that was a pivotal monent that
caused cryptography to become intensely number-theoretic -
cryptographers should have made immediate use of the immense power of
computing but didn't - they turned instead to asymmeteric methodology
and never questioned the wisdom of using the highly transparent number
base of integers. - I agree ciphers do not need to be comlicated -
almost nothing in mathematics does and if it seems that way then some
one needs a foundation course in the topic concerned - Adacrypt
Tom St Denis
> On Dec 28, 1:06 pm, Tom St Denis <t...@iahu.ca> wrote:
>
>
>
> > On Dec 27, 6:53 am, WTShaw <lure...@gmail.com> wrote:
>
> > > Savard reminds us of what is generally accepted, "That the security of
> > > a cipher system should depend on the key and not the algorithm." Also
> > > he states, "...it seems that for a cipher to remain unbreakable by
> > > today's standards, the algorithm used would have to be intricate and
> > > complicated."
>
> > If he actually wrote that [citation please?] he's certainly wrong.
> > RC5 is really easy to memorize and for all practical considerations
> > the 16-round 32-bit word variant is secure against all known attacks.
> > XTEA was another such algorithm. So is RC4, and IDEA. On the
> > asymmetric side, DSA, ElGamal, and RSA aren't that complicated.
>
> > We as practitioners don't tend to implement things one-off from memory
> > because that would be ridiculously error prone.
>
> > But as a general truth, ciphers do NOT need to be complicated to be
> > secure.
>
> > Tom
>
> Scrambling the raw data before the encryption transformation is in my
> view to be recommended and then the encryption algorithm becomes
Good thing nobody asked for your opinion.
Tom
amzoti
> According to Auguste Kerckhoffs, "...it should be possible to memorize
the key without having to write it down, and it should be easy to
change to a different key, " and "...the system should not cause
mental strain, and should not require following a long and complicated
procedure."
My guess is that during his time period, this made sense.
It ceratinly does not today.
Although not definitive, see the six items:
According to Auguste Kerckhoffs, "...it should be possible to memorize
the key without having to write it down, and it should be easy to
change to a different key, " and "...the system should not cause
mental strain, and should not require following a long and complicated
procedure."
I think most of those are as true today as they were back then - but
some are probably less relvant today and new concerns exist.
Do you think he thought of side channel attacks, tamper, statistical
analyses, reverse engineering and tons of other such things?
Maybe some of them - but it was a different era with much different
concerns than the 1800-early 1900's.
Not sure that helps.
WTShaw
The relative post here was not that many months ago. I'll try a
search.
WTShaw
It was more than a year ago, Oct 99, and I have the complete posting
however this link does not work any more: http://www.ecn.ab.ca/~jsavard/mi0611.htm
Suppose that we all make mistakes but this guy is definitely
ultimately a mentor to many. The general thoughts are still relevant
to seekers.
Mok-Kong Shen
> According to Auguste Kerckhoffs, "...it should be possible to memorize
> the key without having to write it down, and it should be easy to
> change to a different key, "
> Savard reminds us of what is generally accepted, "That the security of
May I ask a few questions:
(1) Isn't it that the 2nd quote stems also from Kerchhoffs? (I guess
it's even better well-known than the 1st.)
(2) What an average person can remember without having to write it down
is presumably quite limited in terms of 'entropy' and thus susceptible
to brute-force in principle, isn't it?
(3) Isn't key setup a procedure that properly belongs to the encryption
algorithm as such and hence is assumed to be known to the analyst
according to the 2nd quote above?
Thanks,
M. K. Shen
Maaartin
> (1) Isn't it that the 2nd quote stems also from Kerchhoffs? (I guess
> it's even better well-known than the 1st.)
http://en.wikipedia.org/wiki/Kerckhoffs'_principle
"It must not be required to be secret, and it must be able to fall
into the hands of the enemy without inconvenience;"
> (2) What an average person can remember without having to write it down
> is presumably quite limited in terms of 'entropy' and thus susceptible
> to brute-force in principle, isn't it?
IMHO nearly everybody can train to remember a password of hundreds
bits, but it's not easy. Using tips from e.g.,
http://world.std.com/~reinhold/diceware.html
makes it easier. My problem is remembering many good passwords, which
I solve using a password store protected by a good master password.
> (3) Isn't key setup a procedure that properly belongs to the encryption
> algorithm as such and hence is assumed to be known to the analyst
> according to the 2nd quote above?
IMHO it surely is.
WTShaw
> WTShaw wrote:
> > According to Auguste Kerckhoffs, "...it should be possible to memorize
> > the key without having to write it down, and it should be easy to
> > change to a different key, "
> [snip]
> > Savard reminds us of what is generally accepted, "That the security of
> > a cipher system should depend on the key and not the algorithm." [snip]
>
> May I ask a few questions:
>
> (1) Isn't it that the 2nd quote stems also from Kerchhoffs? (I guess
> it's even better well-known than the 1st.)
Savard "REMINDED US" of a truism that seems true if not exclusive as
the statement might imply.
>
> (2) What an average person can remember without having to write it down
> is presumably quite limited in terms of 'entropy' and thus susceptible
> to brute-force in principle, isn't it?
That is unlimited by patience and practice and the willingness to
follow through.
Given the world at large, the average person can't even tie their own
shoes,,,many prefer velcro, slip-ons, or no shoes at all.
Rather long passages can be remembered and quotations can have special
included errors.
>
> (3) Isn't key setup a procedure that properly belongs to the encryption
> algorithm as such and hence is assumed to be known to the analyst
> according to the 2nd quote above?
>
Note the word "SHOULD." It's a dumb thing to assume anything and give
otherwise important facts to someone who might not know them. Better
yet is to lead the opponent astray with misleading clues. Doing the
unexpected can mean getting it right.
> Thanks,
>
> M. K. Shen
WTShaw
>
> IMHO nearly everybody can train to remember a password of hundreds
> makes it easier. My problem is remembering many good passwords, which
> I solve using a password store protected by a good master password.
Even that is too much information to give away. Make your protocol
your own
>
> > (3) Isn't key setup a procedure that properly belongs to the encryption
> > algorithm as such and hence is assumed to be known to the analyst
> > according to the 2nd quote above?
No, not at all. There may be endless way to construct a key, each one
public, and most not or at least obscure. An analyst would like to
know how keys are made but it is the job of crypto designers to keep
rows of clerks and hairless computer gurus awake at night trying to
figure out what is actually going on.
On the subject of misleading people is propaganda that is purposeful
or missevaluated ideas that are essentially wrong...take your pick. I
remember one daylong ago when I read in Scientific American about what
was be advanced about DES. It was a day that I laughed louder and
longer than about any other. At least I knew better when there was no
inclusion in it to combat the first flaw in binary text files, the use
of ASCII values as is in binary form.
The end result of that mistake is that a surfer crypto hero of ours
could mass enough money to build a specialized computer to break DES.
He only needed to solve two or three blocks of text to have it.
Imagine his problem if the characters were in a deranged set to begin
with. With proper steps, it might take many more blocks to solve DES,
he might not have afforded it, and the dog and pony show that has
followed would not have been necessary, i.e. the same trick could have
been openly added to DES even as it might have been privately.
If the powers that think they have everybody fooled are getting that
message along with the rest of you, they might need to find a clean
pair of underwear about now. Ain't crypto fun? Now, add it to AES for
grins.
Maaartin
Ooops, did you mean the key schedule (as I understood it) or the way
the user chooses their password (e.g., by using diceware)?
I saw some good arguments for considering the password generating
algorithm to be known to the analyst, but I'm not convinced. Even if I
choose diceware, I'm free to do some simple modifications to the
result (adding, dropping, swapping, or changing single characters). As
long as I know what I'm doing, I can be sure this doesn't make it any
weaker. It can may it stronger (maybe not much but maybe the attacker
has no clue what crazy thing I'm using) and it can make it easier to
remember and/or to type. I would never modify a cipher in order to
make it stronger (because I know I'm not good enough), but there's no
risk in making my own variant of e.g., diceware (because this is easy
enough).
Mok-Kong Shen
>> Mok-Kong Shen wrote:
>>> (3) Isn't key setup a procedure that properly belongs to the encryption
>>> algorithm as such and hence is assumed to be known to the analyst
>>> according to the 2nd quote above?
>
> No, not at all. There may be endless way to construct a key, each one
> public, and most not or at least obscure. An analyst would like to
> know how keys are made but it is the job of crypto designers to keep
> rows of clerks and hairless computer gurus awake at night trying to
> figure out what is actually going on.
Sorry that I have not yet fully understood you.
I had in the quote of mine above understood your "key setup" to be what
is usually also referred to as "key scheduling" in block ciphers. (See
also Post of Maaartin 30.12. 17:56) But it was a misunderstanding and
you apparently use that term to mean instead the "method" a user
"generates" his key to be used e.g. for a block cipher.
Referring to the first quote of Kerchhoffs, it seems that you mean a
user starts with something that he can easily memorize and then use
certain procedure (which you call key setup) to generate a key (which
is difficult to memorize) to be used e.g. as the key for a block
encryption. But then this "key setup" procedure (algorithm) could
apparently by its nature be integrated together with the block cipher
and thus be considered as one single (bigger) encryption algorithm. Or
are there any essential arguments against this view? If no, one would,
I am afraid, have difficulties with the 2nd quote of Kerchhoffs. For
now the (whole) algorithm isn't entirely public; it has a secret part,
namely the "key setup" procedure.
Thanks,
M. K. Shen
Maaartin
> Referring to the first quote of Kerchhoffs, it seems that you mean a
> user starts with something that he can easily memorize and then use
> certain procedure (which you call key setup) to generate a key (which
> is difficult to memorize) to be used e.g. as the key for a block
> encryption. But then this "key setup" procedure (algorithm) could
> apparently by its nature be integrated together with the block cipher
> and thus be considered as one single (bigger) encryption algorithm. Or
> are there any essential arguments against this view? If no, one would,
> I am afraid, have difficulties with the 2nd quote of Kerchhoffs. For
> now the (whole) algorithm isn't entirely public; it has a secret part,
> namely the "key setup" procedure.
You can go the other way, start with something hard to memorize and
make it easier, e.g., by using associations or rhyming. It doesn't
need to be an algorithm at all.
Using diceware I generated
"sad awful hk watch finny cannot"
That's terrible for me to remember, so I transformed it to something
like
"Sad awful Hulk watched by Finny cannot be Hogen."
This is too much to type and I hate caps, so I shortened it to
"sadawf hulk watch'dby finnycan behogn"
This may sound completelly crazy to you but this doesn't matter at all
as I'm the only one concerned.
If English were my first language it could be less strange, but who
cares.
There're only two things that count: Enough entropy at the end and the
ability of the single user to memorize it.
I don't think something like this "algorithm" will become a part of
the next encyption standard.
Mok-Kong Shen
> You can go the other way, start with something hard to memorize and
> make it easier, e.g., by using associations or rhyming. It doesn't
> need to be an algorithm at all.
>
> Using diceware I generated
> "sad awful hk watch finny cannot"
> That's terrible for me to remember, so I transformed it to something
> like
> "Sad awful Hulk watched by Finny cannot be Hogen."
> This is too much to type and I hate caps, so I shortened it to
> "sadawf hulk watch'dby finnycan behogn"
> This may sound completelly crazy to you but this doesn't matter at all
> as I'm the only one concerned.
> If English were my first language it could be less strange, but who
> cares.
> There're only two things that count: Enough entropy at the end and the
> ability of the single user to memorize it.
>
> I don't think something like this "algorithm" will become a part of
> the next encyption standard.
My point is: It is the 'entropy' of the stuff that one "actually"
memorizes (has in one's mind) in order to generate (or re-generate at
later occasions) the key of, say a block algorithm, that counts. All
the procedures (algorithms), if any, that intervene between this
memorized stuff and the final key to be input to the block algorithm
should be counted together with it as "the" entire encryption algorithm
used and hence should be considered to be known to the analyst
according to Kerchhoffs. If the said intervening procedures
(algorithms) are thus public, then they can't give rise to additional
'entropy', if I don't err. So the issue boils down to: Should one keep
part of one's "algorithm" secret? (It is said that some angencies
do keep parts of their algorithms secret, thus against Kerchhoffs'
opinion.)
M. K. Shen