An Honest and Simple Question.
in [Cryptography]
|
From: adacrypt on 17 Jul 2010 04:23 On Jul 16, 9:59 pm, gordonb.xp...(a)burditt.org (Gordon Burditt) wrote: > >In my view a cipher should be able to go solo completely on the back > >of a theoretically unbreakable mathematical algorithm, that is by > >being used in the hands of a non-specialist office worker with minimal > >training (that means no user-assistance whatever). > > Unfortunately, these two parts have nothing to do with each other. > The encryption algorithm is something you can change out with a > software algorithm and the users don't have to care at all. The > strength of the algorithm has nothing to do with the amount of > administration an office worker needs to do. The *type* of the > algorithm (symmetric vs. asymmetric, for example) may affect this. > > That means that if the user clicks on a PDF, MP3, or video file to > attach to an email, you need to handle it correctly, not quietly > corrupt it, and not have to have someone around to explain that > encryption is for the printable subset of ASCII only. > > You will have these problems with user/manager administration using > *ANY* crypto system: > > 1. You have to keep the key secret. Don't fall for phishing requests > for a copy of whatever file a key is kept in. > > 2. For two users to communicate by encrypted email, they need to > set up a key first. New users (e.g. new hires) will enter the > group. Asymmetric cryptography, which yours is *not*, has the > advantage that it can send the public key with a message, so anyone > receiving it can send an encrypted reply using a crypto-aware email > client that stores keys for correspondents. No setup, it Just > Works. Also, you can set up public key registries without blowing > security. > > Now explain how two users set up to communicate by encrypted mail, > using your cryptography. You can't send the secret key with the > message, that would blow all your security. Of course, your answer > is "Duh, that's a management problem". Of course it is, but it's > very relevant to the problem that your crytography (and any symmetric > cipher) takes a lot more administration than an asymmetric one. > > 3. You have to educate users about what must be sent encrypted and > what need not be. You will have cases where you need to send email > to someone who has no key set up (e.g. ordering pizza). A smart > email client can automatically encrypt if a key is available, and > warn if it's about to send something unencrypted, but users have > to understand the warning and deal with the fact that it's OK to > order pizza unencrypted but not send client lists and sales reports > to the home office unencrypted. > > 4. Somehow the user, or email client program, has to figure out > what key to use for what message, both encrypting and decrypting. > Email client programs can be pretty smart but they have to have > something to go on. That includes contending with the fact that > users may have multiple e-mail addresses, and users may have multiple > keys for various purposes (such as "work" and "home"). > > >Clearly that is > >not going to be the case ever with either AES (that you are so > >obsessively single-minded about) and even more so the RSA cipher. > > I didn't mention AES in my post. It deserves mention that it is a > proof-of-concept that you *can* read plaintext as bytes and output > plaintext as bytes, without mangling the message. That code still > works even if AES is broken and can only be trusted for 99-cent app > downloads. > > >These are always going to be costly to run in that they require > >specialist management that must be provided by a highly informed, > >interactive operator. > > Why interactive? Periodic key changes, adding and deleting users, > and updating the email client program and encryption program don't > have to be kept that up to date. > > >The hip-pocket nerve is most sensitive to cost in the world of e- > >commerce security of information. > > e-commerce (and particularly SSL) uses RSA for a very significant > reason: It's an asymmetric cipher. An email client can include > my encrypted mail certificate in my outgoing email, and the recipient > can then reply with no further information. An asymmetric cipher > can also be used to authenticate identity with certificates. A > symmetric cipher cannot do that. RSA beats the snot out of any > symmetric cipher for some very important properties crucial to > e-commerce. > > Remember, SSL needs to be able to encrypt images. > > You *still* haven't explained how two users who want to communicate > using your ciphers set up a key. Especially if the only communication > method they have is the Internet. > > >This a very discerning market that > >unlike the national security arm of cryptography is not a captive one > >and is not bound by so-called 'advanced' 'standard' (neither of these > >is true) - they will kick the 'standard' bit (pardon the pun) into > >touch at the drop of a hat if it is demonstarted to them that they can > >go it alone in managing their own network - that is now a distinct > >possibility. > > They will need an asymmetric cipher. Yours is not one. If you do come > up with a theoretically unbreakable *asymmetric* cipher, the world will > beat a path to your door. Assuming, of course, that it handles images > and UTF-8. > > >I wouldn't take any bets on AES or RSA ciphers being around more than > >another ten years. Old ciphers are as useless as old newspapers. > > True. But a symmetric cipher cannot replace RSA for use in e-commerce. Hi again, > You *still* haven't explained how two users who want to communicate > using your ciphers set up a key. Especially if the only communication > method they have is the Internet. I have done this ad nauseum by way of posts on Mutual database. The key(s) per se is comprised of the very lengthy arrays of random data that make up the database - all of this is thoroughly expounded on my webslite http://www.adacrypt.com At encryption time Alice reads these sequentially (they have already been scrambled and sliced at both ends soa sto eb exactly identical) - at decryption time Bob reads them sequentially again. The transfer of the key is in effect the transfer of an entire database copy from Alice to Bob - that may be done by whatever means is appropriate - this is a once in a lifetime (life of the secure loop that is) requirement - it means that there is no further transfer of any key in the future life of the system - adacrypt
From: Sebastian on 17 Jul 2010 04:27 On 17 Jul., 09:10, adacrypt wrote: > [...] > It seems now that this another piece of the RSA gimmickry that has > become corrupted into a must have class. Judjung by your text it doesn't look like you understand what "asymmetric" is about. > It matters not that the mathematics is asymmetric or symmetric - its > the overall security that counts - both cases depend on either > randomness or a mathematical one-way function (same thing virtually) You have been told that one-way functions have little to do with ciphers. Less than trap-door functions. Unless you pick up a book containing definitions for these terms you'll probably misuse them again and again. > inthe keys sets.- this is independent of the process - asymmteric is > not a historic mathematical term - the whole of mathematics is > intensely asymmetric if it comes to that so where's the distinction in > it being used as a class - this is more of the RSA opportunism - > asymmetric is not a class unless it is nothing more than a descriptive > corruption of a crypto class - saying that it is essential is not > right. You don't get it. Grab a textbook and learn the field you pretend to know / be interested in. Symmetric encryption aka secret-key encryption requires a shared secret (the key) between Alice and Bob. Asymmetric encryption aka public-key encryption is about splitting the key into a private (secret) part and a public (shared) part. No shared secret needed. This is where trapdoor functions come in handy. Both kinds are typically combined in applications like HTTPS, GPG, ... http://en.wikipedia.org/wiki/Trapdoor_function http://en.wikipedia.org/wiki/Symmetric_encryption http://en.wikipedia.org/wiki/Asymmetric_encryption Frankly, this is such basic stuff that not knowing about it while claiming the superiority of your algorithms makes you look like an idiot that doesn't deserve any trust in his algorithms. Cheers! SG
From: Mark Murray on 17 Jul 2010 05:47 On 17/07/2010 09:23, adacrypt wrote: > The transfer of the key is in effect the transfer of an entire > database copy from Alice to Bob - that may be done by whatever means > is appropriate - this is a once in a lifetime (life of the secure loop > that is) requirement - it means that there is no further transfer of > any key in the future life of the system - adacrypt Scenario: Alice and Bob have never met, and they are physically very far apart. For various reasons they cannot meet (eg, they are spies and meeting may blow their cover. They need to communicate securely. How, using your system, do they synchronise their databases without Eve (the eavesdropper) getting a copy too? Lets say that this does not matter, and that for some reason the database is universal, and anybody can have a copy with impunity. How do Alice and Bob communicate exclude Eve from the communication? M -- Mark "No Nickname" Murray Notable nebbish, extreme generalist.
From: Bruce Stephens on 17 Jul 2010 06:19 adacrypt <austin.obyrne(a)hotmail.com> writes: [...] > It matters not that the mathematics is asymmetric or symmetric - its > the overall security that counts You've no idea what asymmetric cryptography provides, do you? [...]
From: adacrypt on 17 Jul 2010 10:50
On Jul 17, 10:47 am, Mark Murray <w.h.o...(a)example.com> wrote: > On 17/07/2010 09:23, adacrypt wrote: > > > The transfer of the key is in effect the transfer of an entire > > database copy from Alice to Bob - that may be done by whatever means > > is appropriate - this is a once in a lifetime (life of the secure loop > > that is) requirement - it means that there is no further transfer of > > any key in the future life of the system - adacrypt > > Scenario: > > Alice and Bob have never met, and they are physically very far apart. > For various reasons they cannot meet (eg, they are spies and meeting > may blow their cover. > > They need to communicate securely. How, using your system, do they > synchronise their databases without Eve (the eavesdropper) getting > a copy too? > > Lets say that this does not matter, and that for some reason the > database is universal, and anybody can have a copy with impunity. > How do Alice and Bob communicate exclude Eve from the communication? > > M > -- > Mark "No Nickname" Murray > Notable nebbish, extreme generalist. Hi, > Alice and Bob have never met, and they are physically very far apart. > For various reasons they cannot meet (eg, they are spies and meeting > may blow their cover. This crypto system of mutual databases requires a one-off secure delivery of the copy database to Bob initially - after that Alice decides on the computer scrambling parameters that she sends to Bob that he must apply to the arrays of keys so as to keep in sync - other wise he cannot decrypt - this ploy produces a fresh permutation of the arrays that is volatile at the end and the database arrays revert to original when the program run is finished - the same scrambling and slice parameters are used each time until Alice changes - they can go as unsecured information along with the ciphertext that may also be unsecured - Alice alone calls the shots - only she can make ad hoc changes to the volatile arrays - she can also make changes by arrangement with Bob to the base state of the arrays ( which of course is permutation in itself also). The secure delivery of the initial copy database from Alice to Bob is something that they should be good at ? - other it is their problem. >Lets say that this does not matter, and that for some reason the >database is universal, and anybody can have a copy with impunity. >How do Alice and Bob communicate exclude Eve from the communication? That's unthinkable - the essence of this crypto scheme is having mutual databases to which they alone are uniquely privy - with mutually shared databases they don't need to exclude Eve - they can even send her a copy of the cipher - the ciphertext simply references the arrays so as to call the keys in correct order and is useless on its own without the databases to which it relates.- the entire scheme has huge disaster recovery also should it ever be needed - Cheers - adacrypt |