From: Gordon Burditt on 4 Jul 2010 23:01 >There will always be a need for the cheapest cryptography available >that will serve the needs of commerce at some right price and give the >required degree of security for the required cover time. E-commerce, especially over the Internet, needs public-key cryptography. Your cryptography, theoretically unbreakable or not, does not provide that. A lot of the job of web-based SSL is to communicate your credit card info to the thief you are doing business with before the other thieves get hold of it. SSL also needs to encrypt images, which for some odd reason your cryptography won't do, due to a silly design decision. There's no inherent reason it can't be modified to do raw binary. >Anything more >than the required degree of security and the required cover time in >commerce is redundant cover and can be a very expensive waste. Your cryptography is far too complicated to use for the average web-user, especially in terms of setting up and keeping track of keying material set up with many, many correspondents. The typical web user does not have a secure channel, and they don't know much about key handling. Their computers, however, may be infected with viruses which will likely be written to steal keys should your cryptography be used in SSL. >In the >case of national security however cover time is never-ending and the >degree of security should be nothing less than theoretically >unbreakable � i.e. perfect secrecy of communication of information at >least. For at least *some* situations, e.g. embassy to home government or military base to military base, the required secure channel for sending keying material is available (at least before all hell breaks loose) and existing practice (e.g. diplomatic courier pouches). However, your cryptography is vulnerable to corrupted messages, messages received out of order, or missing messages, something likely to happen when all hell breaks loose, accompanied by weapons systems blowing things up, deliberate jamming, and EMP from nuclear weapons. This is just the time when the secure channel (diplomatic couriers) will prove to be too slow and unreliable. Your cryptography does not even preserve line lengths, and you (according to you) insert line breaks every 77 characters (a particularly stupid choice). This I believe, if deployed in a military situation, will eventually cost lives by changing the meaning of the message. >At present, national governments are in the parlous state of never >knowing if hitherto �practically� unbreakable ciphers have indeed >being broken in the meantime by enemy powers who are now quietly >reading their intercepted secret messages. The only antidote to that >event is for national governments to use theoretically unbreakable >security as the minimum degree of security at all times. No, that's not an antidote. Theoretically unbreakable cryptography may be broken by practical means, such as stealing a copy of the key, rubber hose cryptography, torture, or even exotic means used by the press such as detecting a spike in nighttime pizza delivery orders in areas around the Pentagon. And that probably *can't* be fixed by encrypting pizza orders from the Pentagon to pizza-delivery places. >Only that >will always ensure that their secret communications to other countries >are completely safe. That kind of security is not available to any >country however at the present time. If theoretically unbreakable cryptography provides "secret communications that are completely safe", then the One Time Pad *is* available today for this purpose. It has a simple proof of security that yours doesn't. Practical considerations may result in a choice not to use it. Embassies are one setup where it may be practical to deal with the issue of handling large keys. >The aim here therefore, is to create theoretically unbreakable >cryptography at any cost for national security and hope that this cost >will be acceptably low at the same time for commerce to be able to >afford it also in all day-to-day running, otherwise commerce is just Your cryptography has a constant extra cost because of your shoot-self-in-foot decision to not permit (and *silently* corrupt) encryption/decryption of arbitrary binary patterns such as images, audio recordings, word processing documents, and intercepted emails in foreign languages that don't stick to the printable subset of ASCII. >as well off staying with existing cryptography that is being called >�practically� unbreakable. Although only �practically� unbreakable in >name that cryptography is virtually unbreakable in practice. The only >disturbing thing about �practically unbreakable� cryptography is the >fact that nobody knows what trumps the enemy is holding in the way of >secret advances they may have made in cracking ciphers such as the RSA >cipher and AES that hitherto governments regarded as unbreakably safe. >Only theoretically unbreakable ciphers can be considered totally safe >in this respect. And those are also vulnerable to spies and ways of stealing the key. If the spy is careful, you won't know the key was stolen. >There is no selfish pursuit of greedy material gain by me in this >respect in the cryptography that I am promoting as either vector >cryptography http://www.adacrypt.com or modular cryptography >http://www.scalarcryptography.co.uk that both operate by mapping >plaintext to widely dispersed points in space thus putting >cryptanalysis beyond the pale of all mathematics in terms of inversion >methods. >These cipher designs both use mutual database technology to >implement the mathematical one-way functions and randomness that are >the securing basis of these crypto types. "mutual database technology" is vulnerable to getting out of sync if you decrypt a message twice, receive messages out of order, a message goes missing and you try to decrypt later ones, or messages are corrupted. Your use of the term "one-way functions" here is not standard cryptography terminology. One-way functions have no easy inversion, *with or without* a key. >Mathematical inversion of >ciphertext is totally disabled by this design of cryptography. >The ciphers to hand are intended to be nothing more than feasibility >models that say �the proof of the pudding is in the eating� i.e. they >demonstrate the realisation of the mathematical claim into de facto >ciphers. I have no pretensions to software engineering or >infrastructure management but my claim is that only when the >mathematical core is demonstrated as being theoretically unbreakable, >is all else then made possible and not before this. "theoretically unbreakable" has a high cost in terms of the amount of shared key required (the sum of the length of all the messages you will ever send). For some applications, this is too high a cost. Some applications need to send and receive raw binary data. Your cryptography does not handle that (for a silly reason of yours - there's no reason it couldn't be modified to handle this). >It is fully understood by me that clever software engineering by these >experts will greatly enhance all aspects of the working efficacy of >the software per se that is to hand as up and running programs, as >well as optimising the portability of the software as it stands and >also, an input of experienced infrastructure management will work >wonders on both the considerable tertiary system security and the >electronic transmission efficacy of the overall crypto schemes. > >Even as it stands, either of these crypto scheme types is quite viable >as a home-grown DIY crypto scheme that any non-specialist management >group like say a corporate commercial company wanting to set up and >manage their own crypto network could do on thier own, with minimal >knowledge of cryptography. It is well within the capability of an >average office administrator to do this. > >I am confident that the running costs of this simple transparent >scheme that provides maximum security i.e. theoretically unbreakable >class of security, is eventually going to be so cheap as to become the >first choice for both commercial and national secure communications in >time. No on-site specialists are needed for the day-to-day running of >a scheme apart from say an initial systems-analyst/cryptographer input >at the outset just to get it all working. I envisage such a scheme as >having about the same daily management complexity needs as say a >typical on-line banking scheme. In other words, you don't want to talk about all the problems about exchanging keys securely, not getting out of sync when communication screws up, and that hidden secure channel you try not to talk about. You will constantly need tech support to explain why word-processing documents, images, and other similar raw-binary files are silently corrupted. Soon you'll need to handle a larger character set such as UTF-8. Disallowing stuff outside the printable characters of ASCII will be no more tolerable than disallowing vowels. >There is no argument for continuing current crypto schemes that >require a lot of user-assistance and are only practically unbreakable >at the end of the day unless they are very much cheaper than what�s on >offer here - I doubt this very much - adacrypt The cost of a crypto scheme is infinite if it fails to work for the application. Your cryptography fails: - It can't do public-key cryptography. - It can't work without a pre-shared key or secure channel transmitting at least as much volume as the message traffic (why not just use the secure channel?) - It only does the printable subset of ASCII and corrupts line length and any characters outside the printable subset of ASCII (like most of adacrypt's Usenet posts). - It is vulnerable to getting out of sync (denial-of-service) if messages are lost, duplicated, received out of order, or you try to decode a fake message from the enemy.
|
Pages: 1 Prev: My Cryptography that is Currently on the Table. Next: Recommend AES Program, Please |