Prev: My Recent Posts and the Fallout Aggro.
Next: A new prime number pattern
From: Mok-Kong Shen on 9 Jul 2010 06:51
I wish to learn herewith experts' opinions on the following humble
thoughts of mine concerning the desirability and feasibility in
'practice' of employing comparatively simple encryption algorithms.

(1) Through employing distinct message keys, or if needed frequently
enough dynamically changed keys during the processing of a single
message, the amount of materials processed with any particular key
of an algorithm can be reduced to allow corresponding significant
reduction of security requirements posed on the encryption algorithm
being used. Cf. the results of analysis of some well-known block
ciphers that indicate the necessity for a break of huge amounts of
materials, which implies that these algorithms are an overkill if the
actual materials processed with a certain particular key is restricted
to be of only several orders of magnitude less, which is a condition
that naturally holds, if I don' err, if distinct message keys are
used. (Consider also, as an extreme case, the practically mostly
feasible/tolerable possibility of using a different key for each
single different block of a message.)

(2) It is valuable to be able to exploit the trade-off between
simplicity and security of an encryption algorithm. For, if a simpler
algorithm is viable for use by virtue of the argument above, it can at
least be usefully employed when the more complex algorithms are
unavailable for whatever reasons (including the now in my view almost
irrelevant, but once ponderable, cause: export regulations). For a
sufficiently simple algorithm can as a rule also be easily understood
and hence trusted by even the laypersons as users. It can be
implemented, if necessary, on the fly by an average programmer in a
short time span and, what is important, easily verified to be correct.
Cf. the use of foreign software (in particular as binary files), which
is vulnerable to malicious manipulations from the time of generation
of the software up to the time the software is downloaded to one's
computer.

(3) A viable 'starting point' of obtaining such a simple algorithm is
the availability of a 'practically' sufficiently good PRNG. Akin to
(1) it can be seen that, with adequate key management, the stringent
requirements posed on the so-called CSPRNGs are not necessary in
'practice'. Assuming that such a sufficiently good PRNG is available
(I like to postpone my personal opinions on this for the moment,
in order to simplify the discussions), it seems to be desirable, that
the algorithm, instead of employing stream enciphering via xoring
plaintext and output of PRNG, achieves what a block enciphering
commonly performs, namely the avalanche effect within the region of
a block. One straightforward means that suggests itself is IMHO the
("notorious") Hill matrix, which we will (as a proposal to be
discussed) dynamically generate for the processing of each single
plaintext block. This is because, under the assumptions hitherto
mentioned, it is evident that the well-known severe weakness of the
Hill cipher can no longer hurt us. For even in case a particular Hill
matrix could be recovered by certain known plaintext and ciphertext
pairs (I postpone arguments againt this, if needed, for the moment),
that information is useless for decryption of the other yet
undeciphered blocks for the simple reason that, under our asumptions,
the output of the PRNG that generates such matrices is 'practically'
unpredictable and therefore the knowledge of one matrix is of no use
for learning the other matrices.

For comments and critiques I should be very grateful.

M. K. Shen
-------------------------------------------------------------------------------------------

[OT] In an attempt to reduce annoyance to the general readers, I am
unfortunately forced to forgo any opportunities of discussion with
those, who have the unnice impulse (urge, "Drang" in German) to
overload their posts with bandwidth-wasting personal stuffs and/or
bad words, by placing them into my kill-file. Those who dislike my
posts for whatever reasons are requested to kindly put me into their
kill-files as well.

From: Globemaker on 9 Jul 2010 08:16
On Jul 9, 6:51 am, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote:
> I wish to learn herewith experts' opinions on the following humble
> thoughts of mine concerning the desirability and feasibility in
> 'practice' of employing comparatively simple encryption algorithms.

The main problem is the "employing" part. If people want to employ
simple encryption algorithms, they can do that, but most people do not
want to employ any encryption algorithms. Standardized and automated
encryption and decryption is often employed but non-standard
algorithms that require intelligence and mental effort are not
welcomed by most people. They do not have secrets that they want to
send using crypto. I have no valuable secrets to communicate to anyone
using crypto.

Who needs to use simple crypto algorithms? Rebels? Revolutionaries?
Prisoners? Hobbyists? Geniuses? Crooks?
From: Tom St Denis on 9 Jul 2010 08:31
On Jul 9, 8:16 am, Globemaker <alanfolms...(a)cabanova.com> wrote:
> On Jul 9, 6:51 am, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote:
>
> > I wish to learn herewith experts' opinions on the following humble
> > thoughts of mine concerning the desirability and feasibility in
> > 'practice' of employing comparatively simple encryption algorithms.
>
> The main problem is the "employing" part. If people want to employ
> simple encryption algorithms, they can do that, but most people do not
> want to employ any encryption algorithms. Standardized and automated
> encryption and decryption is often employed but non-standard
> algorithms that require intelligence and mental effort are not
> welcomed by most people. They do not have secrets that they want to
> send using crypto. I have no valuable secrets to communicate to anyone
> using crypto.

Have you EVER used HTTPS? Or a chip&pin card? Or a cell phone?
Or ...

Crypto is all over, when it's done well and thought out for the most
part it's transparent. I can talk to some random HTTPS server without
having to *know* that it's RSA [or ECC] behind the scenes.

It's true most people don't use crypto for personal traffic [emails,
etc] and really that should be changed, but to say that's a failing of
crypto is a bit of a stretch. With things like Enigmail you could
easily sign/encrypt all of your email without so much as clicking any
additional buttons [once you spend the five seconds setting it up].
PGP integration into Outlook is similar, etc.

The problem isn't the crypto, or even the implementation thereof, the
problem is the people just don't care. Ask any random person on the
street if they a) use email and b) could benefit from non-
repudiation. They'll have no idea what you're talking about. Crypto
isn't broken and heck people aren't broken. Most people don't
actually need privacy or non-repudiation on their emails. And people
who truly need it will tend to use it.

The great irony here is you still have yet to acknowledge that "gpg -
c" would be a better model usage of crypto than "aes ecb with a zero
key" to get people more educated about the tools out there. Care to
elaborate on why you're so reluctant to develop a clue?

Tom
From: Globemaker on 9 Jul 2010 09:32
Here's an idea, use a stable website as keying material. Find a
website that has a text story of about 20 kilobytes. The text must
remain unchanged for years. Use that as a one time pad OTP to XOR with
the message. The message has a plaintext preamble that give an offset
number that defines which character is the beginning of the OTP. The
preamble also gives the URL of the website.

As an example, look at the "web archive dot org"
http://web.archive.org/web/20060708173816/www.reliefglobe.com/index.html
There are many stable archived stories on that giant website. That is
simple.
From: Tom St Denis on 9 Jul 2010 09:35
On Jul 9, 9:32 am, Globemaker <alanfolms...(a)cabanova.com> wrote:
> Here's an idea, use a stable website as keying material. Find a
> website that has a text story of about 20 kilobytes. The text must
> remain unchanged for years. Use that as a one time pad OTP to XOR with
> the message. The message has a plaintext preamble that give an offset
> number that defines which character is the beginning of the OTP. The
> preamble also gives the URL of the website.
>
> As an example, look at the "web archive dot org"http://web.archive.org/web/20060708173816/www.reliefglobe.com/index.html
> There are many stable archived stories on that giant website. That is
> simple.

And you want to publish a blog on cryptography that people are
supposed to read?

Tom
 |  Next  |  Last
Pages: 1 2 3 4
Prev: My Recent Posts and the Fallout Aggro.
Next: A new prime number pattern