An Honest and Simple Question.
in [Cryptography]
|
From: Gordon Burditt on 17 Jul 2010 22:57 >What do think prompted the notion of being asymmetric in the first >place - was'nt it that the decryption process being by a diffferent >mathematical means to the encryption process albeit bot process >belonged in the same branch of mathematics. > >It seems now that this another piece of the RSA gimmickry that has >become corrupted into a must have class. You don't like to *LISTEN* to the requirements of users of cryptography, do you? You decide what you think they ought to want, and insist that your cryptography will fit that need, even though there are critical needs your cryptography does not meet. E-commerce has several requirements: 1. It must be possible for anyone to verify a signature on a web site certificate using only public information (which includes the web site certificate transmitted in the SSL protocol, and a file of trusted certificate authorities distributed with just about every web browser on the planet). This is required so one web site cannot impersonate another web site even if they manage to intercept the packets (say, by DNS hacking, tampering with routers, or simply registering a slightly mis-spelled domain name from a genuine one). 2. It must be very difficult for anyone to create a signature on a web site certificate for a certificate authority unless they have the private key of the certificate authority. If just anyone can fake a certificate with an authentic-looking signature of a well-known certificate authority, they are useless. These requirements are not "RSA gimmickry", and they can be satisfied by ciphers other than RSA, but not any symmetric cipher. If you think of the term "certificate" as "RSA gimmickry", just think of it as a form of ID that's difficult to forge, so the holder of it can use it to identify himself as certified by someone else (perhaps a government agency or bank) but can't easily forge it to claim he's someone else. Physical analogies include increasingly complex plastic cards for things like driver's licenses and tamper-proof smart cards. I claim it is theoretically impossible for a symmetric cipher alone to satisfy those requirements. Either you've got the key or you don't (a symmetric cipher has *ONE* key). If you make the key public, (2) fails. If you don't make the key public, (1) fails. 3. It must be possible for a client (someone with a web browser) to set up a secure connection with a server (web site), using *NO* pre-shared secret information and *NO* secure channel, not even a once-in-a-lifetime secure channel and certainly not a once-in-a-lifetime for each person you wish to communicate with. Anything which requires a web site to mail out (unique, different for everyone) DVDs full of random numbers to any potential customers before they can buy anything is not acceptable and too expensive. Setting up such a channel should be extremely easy for a naive client, and most of the time the client should not even be aware it's happening. I claim it is theoretically impossible to do this with a symmetric cipher alone to meet this requirement. If you make the key public, it's not a secure connection. If you don't make the key public, you don't have a connection at all. You could do this with a Diffie-Hellman key exchange (which isn't a symmetric cipher) followed by using that key in a symmetric cipher. Your cryptography requies SPECIALIST MANAGEMENT and a hardware secure channel which is not, in general, available at all to set up a key (even if it is once in a lifetime). >It matters not that the mathematics is asymmetric or symmetric - its >the overall security that counts No, ease of use counts for a lot. Not having any SPECIALIST MANAGEMENT on the user end to make it work counts for a heck of a lot more. >- both cases depend on either >randomness or a mathematical one-way function (same thing virtually) A mathematical one-way function is one that is difficult to invert *EVEN WITH THE KEY*. That's not what you mean here. Stop mis-using this term. >inthe keys sets.- this is independent of the process - asymmteric is >not a historic mathematical term No, it isn't, because the invention of asymmetric ciphers is fairly recent. It is a cryptographic term. I'll point out that "plaintext" and "ciphertext" aren't mathematical terms either. I'm talking about "symmetric ciphers" and "asymmetric ciphers". I said nothing about "symmetric mathematics" or "asymmetric mathematics", and I don't believe such a thing exists. In any case, it's not relevant here. 4. SSL must be able to handle multi-media files. Adacrypt says his cryptography will only handle the printable subset of ASCII. It is also necessary to handle other character sets for things like the name and address of the customer. >Images won't be a problem - adacrypt says they will be. >why do you say UTF 8 as if it wasn't >already coverd by the generic class Unicode? You claim your crytography won't do Unicode either: just the printable subset of ASCII, for extremely stupid reasons, which seem to include a complete refusal to consider customer requirements for a particular application (like e-commerce). Note that I consider it perfectly acceptable to take Adacrypt's Vector Cryptography, slap a base-96 encoder on the front of the encryption program, and a base-96 decoder on the back of the decryption program, and call it Adacrypt's Vector Cryptography Plus, which is capable of doing bytes-in-bytes-out encryption. Then shut up about the "printable subset of ASCII" and Adacrypt's Vector Cryptography and only talk about the Plus version, except when discussing the internal workings of your cryptography. You'll have to write the base-96 encoder in something that can read raw bytes, and you don't seem to know enough ADA to do that. 5. It would be really nice to have strong cryptography, even theoretically unbreakable cryptography, but you may not violate requirement (3) in order to get it. I claim it is theoretically impossible to meet requirement (3) and have a theoretically unbreakable system. I also suspect it is theoretically impossible to have a theoretically unbreakable *asymmetric* cipher, where breaking the cipher includes calculating the private key from the public key. I do not have a proof of this.
From: Gordon Burditt on 17 Jul 2010 23:27 >Do you think that the percieved benefits of asymmetry wiould carry >forward to any other cipher-type that also uses asymmetric mathematics >but is secuired by randomness - adacrypt I assign no meaning to the term "asymmetric mathematics". An asymmetric cipher has a public and a private key (generated with randomness but it is not necessarily possible to use raw random bits for the key), with the following properties: 1. You can encrypt messages with the public key. 2. You can only decrypt the messages encrypted in #1 above with the private key (or some difficult cracking procedure). 3. It is difficult to derive the private key from the public key. This has the practical effect that I can post my public key, and anyone who gets it can send me encrypted messages. Posting the public key does not threaten the security of the messages (although someone else posting a FAKE key in my name does, that's where certificate authorities come in). Even the sender can't decrypt the messages he sent. You don't need one key for each pair of people. I need only one private key (for me) and the public keys of all my friends, which they can post, send in the clear, or register at a key-server. Requirement #3 prevents some trivial key-diddling from qualifying as an asymmetric cipher such as: KeyPublic = KeyPrivate + 1 Encrypt: ciphertext = encrypt(plaintext, KeyPublic) Decrypt: plaintext = decrypt(ciphertext, KeyPrivate - 1) (where encrypt() and decrypt() represent some symmetric cipher) because KeyPrivate is trivially computable from KeyPublic. I believe it is theoretically impossible to have an asymmetric cipher secured only by randomness - the public and private keys have to be related somehow or the decryption won't work. Go ahead and try to prove me wrong: if you succeed, you will have the world beating a path to your door.
From: Gordon Burditt on 17 Jul 2010 23:47 >> 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. That requires SPECIALIST MANAGEMENT. For Windows users, you didn't mention the mouse even once, much less give them click-by-click instructions. And if you ask them to use the keyboard, be sure to include instructions so they can identify which one of those things on their desk or in their lap *is* the keyboard. It gets even more complicated since you've got two users who need to cooperate for a 2-way connection. There wasn't even one screen shot in any of those posts. >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 Nice techie description, which takes SPECIALIST MANAGEMENT to follow. >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. A computer user requires *simple* instructions, like click on the key generation icon, insert the hardware random number generator in the USB port (along with instructions of where to buy one and how to tell the difference between a USB port and an AC power socket), how to enter which correspondent you're going to use this key for, etc. >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 - It requires SPECIALIST MANAGEMENT to tell users that posting the key (or, for that matter, credit card number) on YouTube or on their Facebook page is not secure. Where do they purchase a secure channel? How do they tell if what they've got *is* secure? >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 That's a pretty silly definition of "life of the system". The key file, like any other file, can get destroyed by a virus, lost by a hard disk head crash, or be compromised. Or the other end of the communication loop could have that problem. How do you diagnose an out-of-sync database problem? That requires SPECIALIST MANAGEMENT. It's easily caused by viruses or a flakey hard disk. You also need to deal with how a user might identify which key goes with which person, even if it's just suggesting a naming convention for key files.
From: Tom St Denis on 19 Jul 2010 06:56 On Jul 17, 12:30 pm, adacrypt <austin.oby...(a)hotmail.com> wrote: > Dou you mean that whitfield Diffie was ahead of the RSA team (was that > why you state 1976 i.e. predating RSA - if not, what other cipher > demonstrates asymmetry ?) - he was unable to find an asymmetric cipher > himself so he hopped the ball in US academia - the result was the RSA > cipher ? - why did he call it asymmetric - I was not a bit impressed > with the popular accounts of his so-called 'discovery'. If you actually read about Diffie-Hellman and don't understand why it's called asymmetric, you're clearly not meant to be a cryptographer. Also RSA is not really related to DH other than its also an asymmetric scheme. DH for example, only really allows key exchange, whereas RSA allows signatures and encryption of messages. Without stating the obvious too forcefully you need to buy yourself a gigantic foam clue bat and beat yourself in the head mercilessly with it. > For my information do you know of a previous use of asymmetric > algoritms ? Prior to DH? None existed in the public. Apparently the British government had invented the same DH scheme prior to them but was kept secret. > Do you think that the percieved benefits of asymmetry wiould carry > forward to any other cipher-type that also uses asymmetric mathematics > but is secuired by randomness - adacrypt What does "secured by randomness" mean though? For it to be cryptographic it cannot be truly random. If you stuff a bunch of numbers in a table and then share the table, the table isn't random [especially if you re-use it]. blah blah blah.... Since you don't have any clue whatsoever about computer science, history, software, cryptography, or math I suspect that when you're reading this post you're dreaming about unicorns or whatever you insane folk daydream about... Why not take a hike and go find another usenet group to be insane in.
From: rossum on 19 Jul 2010 13:13
On Mon, 19 Jul 2010 03:56:15 -0700 (PDT), Tom St Denis <tom(a)iahu.ca> wrote: >Apparently the British government had invented the same >DH scheme prior to them but was kept secret. See: http://web.archive.org/web/20030610193721/http://jya.com/ellisdoc.htm Like NSA, GCHQ likes to keep its secrets. rossum |