Re: A revision of my text stego scheme



Am 24.05.2011 05:04, schrieb Jeffrey Goldberg:
On 11-05-23 11:43 AM, Mok-Kong Shen wrote:
Am 23.05.2011 18:05, schrieb Jeffrey Goldberg:

In my last sentence I was saying that the choice of a system that the
user fully understands is likely to be a mistake. I would have thought
that the example I provided of something using a Caesar cipher of his
own invention instead of using any of the AES finalists which he'd been
encouraged to use was a mistake.

Why is it "likely to be a mistake"? Suppose a system is designed to be
so complicated that few people in the world could understand it, then
it is IMHO inadequately designed in the first place for security use,
since here transparancy is extremely important.

I fully agree that obscurity is not a goal. Other things being equal,
the simpler the system the better. So I am not arguing with you on that.

What I am saying is that is that the systems that non-specialists can
understand tend to be weak (with the exception of the one time pad).

I can't avoid of course being subjective. But I surmise that the design
of AES, with the exception (perhaps, for I am not informed of the
current curricurum) of the use of finite field), should be easily
readable by anyone with a not too poor grade in math in college. A
continuation of thought from this is that in future crypto designs
should strive to be readily understandable (by persons with college
education as a 'test'), for this means that the algorithms will be
subject to the examination of a very wide circle of people. Note that
even experts are human, they may eventually overlook something because
they are too deeply immersed in certain prevalent school of thinking.
Cf. the hackers, who are often "simple" young guys but whose malware
may be hard to be dealt with by top grade researchers. That is, one
shouldn't neglect the benificial potential of reviews from the wide
common public.

The systems that people understand tend to be far weaker than the
systems that they don't. Again look at my example of a Caesar cipher
(understood by the user) and AES, understood by far fewer people.

AES would be at the upper limit of complexity of what one would
tolerate in the sense I meant above, i.e. I would wish to have instead
something simpler (something that one having a college education would
have no essential problems to readily understand).

That would be nice. Unfortunately things haven't turned out that way. I,
too, wish that strong systems were easier to understand.

One thing to keep in mind, however, is that we should assume that the
people who try to break the systems we use are smarter than we are.
Non-experts who insist on using systems of their own devising instead of
following expert advice are, effectively, thinking that they are smarter
than the expert community.

See above where I touch on the capabilities of hackers. BTW, I wonder
whether one shouldn't correctly "officially" recognize the hackers as
expert scientists in information security research :)

You don't need to understand how hash functions do what they do, but you
do need to understand what they do.

But then one has to depend on "believing". Personally I don't mind
believing rightaway that Wiles's proof of FLT is ok, because it
wouldn't hurt me anyway even if it were wrong. But in matters of
security, that's different IMHO.

The same is true with aircraft design. I don't know how to build an
aircraft, but I trust my life to them several times a year. With
automobile design and architecture I do the same thing much more frequently.

With encryption technologies I trust the results of the AES process
because it was so open. Even though I don't have the skill to evaluate
the candidate algorithms, enough people did openly examine them that
some were rejected in the process.

The finalist algorithms survived a great deal of public scrutiny, and
anyone who detects a weakness today can publish those freely. We are
well ahead of the days when only secret government agencies really
understood how the algorithms work.

"Anyone" living in the modern world "must" have certain amount of trust
in certain contemporaries. There can be "absolutely" no questioning of
that. Very essential is IMHO that one "wisely" decide how much one
should/could trust whom in which situations. (BTW, top politicians
are among the persons whom I least trust, due to bad past experiences.)
One thing one should never forget in this connection is that it is
not the probability of occurence of risky accidents as such that counts
but it is the "product" of that probability multiplied with the value
of the corresponding damage that really matters. Example: The
probability of an extremely strong earthquake may be negligibly small
but its product of multiplication with the associated potential damage
may nonetheless be enormous, as one unfortunately saw recently in Japan. And one should never forget Murphy's Law being universal. In
particular, where human factors are involved, one should be
"especially" cautious in asking oneself whether one might not have
overlooked something potentially highly risky and grave.

[While I am writing these lines, my subjectivity led once again to the
resurgence in my mind of a recent favourite topic of mine, which I like
now to summarize as: How much should/could one continue to trust
digital signatures in the current status (given the apparently highly
"complex" ensemble of CAs and the not publically verified software they
are using)?? As mentioned previously, I have in this connection in vain
contacted (among others) the local authorities concerned.]


I've started reading Understanding Cryptography.

http://crypto-textbook.com/

It is great. It is slow going for me, and I have to spend time on the
exercises. I'm halfway through chapter 4 (on AES). Will never fully
understand every design decision in it specifically because I don't
fully grok the kinds of attack methods that are known.

You might enjoy this summary however:

http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html

Again, I am not saying that complexity is a virtue in and of itself.
It's just that simple to understand systems (other than the one time
pad) happen to be easy to break. Most of AES actually is simple once you
understand how to do multiplication in Galois fields.

IMHO, your last sentence above is not quite in harmony with what you
wrote as a whole about simplicity/complexity. (Do you count AES as
simple or complex?)

There is the line, probably from Bruce Schneier as he likes to say
things like this. "Anyone can invent a crypto system that they
themselves can't break."

Please try to understand the full implication of that.

I think that one of the big values of this group is to have some
discussions of existing and new, eventually useful, ideas of crypto.
Unfortunately the atmosphere in my humble view is "sometimes" less
favourable than what I would have liked (I mean when compared to
disussions with colleagues at work).

Returning to the topic of this thread, stego belongs to crypto (if
one adopts a wide enough definition). The sentence of BS applies to
me, of course. I can't break my scheme, for I know no way myself.
It is exactly the motivation, however, of initiating this thread
to collect ideas/informations that could contribute to breaking
the scheme. I sincerely hopw that these will be forthcoming.

Could you please be
kind enough to find some minutes to do an experiments on, say,
5 text lines, to compare the two schemes and tell us of their
actual comparative merits? (Please also email me the code used
so that I could repeat your experiment.)

Sorry no. The portion of the program needed to generate modifications of
the text would be time consuming to write. Ideally it should be
interactive and display a bunch of choices with the right properties to
to user to chose among. I am not advocating this as a steganographic
tool, I am advocating this is an improvement on yours.

So you would say that that improvement is "impractical" (at least for
normal users), no?

No. I am saying that the fun part of writing that code would be
outweighed by the tedious part. Also this isn't a scheme I'm
particularly inclined to develop, so I would write the code for fun
only. If I want a steganographic system, I will look at what has already
been developed by people who are much smarter than I am.

If I understand right, at least you personally don't consider it
fun to write software code for the stego scheme with hash. Neither do
I, particularly because what jbriggs444 wrote hithertofore is in
my (personal) view not yet detailed enough as a good specification for
coding (among others, what kind of interactions (guidance etc.) with
the user should there be?) That's why I think that very clearly the
best is that the inventor of the scheme presents his code for people
of the group to examine and evaluate.

M. K. Shen

.



Relevant Pages

  • Re: Encryption and hashing
    ... AES and SHA are US federal standards and if you use them and something ... SHA-2 has been designed by the National Security Agency (NSA), ... But I'm sure that many people will avoid use algorithms recommend by ... and we must trust on them. ...
    (comp.lang.python)
  • Re: Are These Algorithms Good?
    ... for today but most would start at 128-bit AES if they could. ... would be the listed most would trust if 80-bits were not enough. ... getting old in the tooth) algorithms available, super reliable, and ... We are talking reliable and secure, and if you are trying to tell me ...
    (sci.crypt)
  • Re: FUD about CGD and GBDE
    ... easy selection of other algorithms. ... > which happens in CGD will not materially aid any attacks that may ... definition of CBC mode. ... You are claiming, in essence, that AES 256 isn't good enough for you, ...
    (freebsd-hackers)
  • Re: Complexity Theoretic Cryptography
    ... AES, RSA, PGP, Discreet Logarithm, the lot. ... the same sentence of algorithms that are "relying on an insufficiency ...
    (sci.crypt)
  • Re: IPsec/L2TP and AES
    ... > The requirement comes from the certification level we need for the data>. ... AES is the only method that will give us the level we need. ... With all the other>> mature algorithms and rekeying also supported, current Windows IPsec is ...
    (microsoft.public.windows.server.security)