From: adacrypt on 27 Apr 2010 08:02 The case has been made earlier for using mutually identical database technology and ciphertext that acts as a mark-up language that uniquely indexes the arrays of these databases so as to give the message-text the required structure that converts it into the meaningful message that Alice wants Bob to know. The notion of mutual database technology is very easy to understand but it would be a mistake to think that this cryptography is easy to design. Instead it is very, very intellectually challenging and no less difficult than traditional ciphers to create. The ciphertext acts as a mark-up language that is useless on its own (to an adversary) but is hugely secure when applied in conjunction with the uniquely scrambled-and-sliced databases to which it relates. Only Alice and Bob are privy to these databases. The truth of modern ciphers is that it is a mistake to encapsulate the plaintext directly within the ciphertext in any shape or form because the ciphertext will always retain enough residual structure of the original raw plaintext to attract the attention of some very clever cryptanalysts who have the same mathematics available to them as the cryptographers. In principle, all conventional modern ciphers are a complete and utter mistake that may be likened by analogy to sending cash through the post when a cheque is better. If the prognosis for long term future is ever to be mutual database cryptography in mainstream cryptography, then it would very appropriate to call the markup style ciphertext that characterises it, a scripting ciphertext language, that is created by a scripting cipher. Future crypto design theory will be in creating markup ciphertext using scripting ciphers rather like Javascript uses html. Each ciphertext string is then its own unique scripting language. There is no end to the research possibilities for the suitably equipped research cryptographer to make new contributions to this fascinating science in all branches of mathematics. - adacrypt
|
Pages: 1 Prev: bad client public DH value Next: Public Key Size in ECDSA |