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 |