An Honest and Simple Question.
in [Cryptography]
|
From: Mark Murray on 16 Jul 2010 17:48 On 16/07/2010 20:36, adacrypt wrote: > Hi, >> What do you mean by "batch" here? It clearly doesn't mean what other >> folks understand it to mean. > Just simply "created at another time and place also, possibly" So any data stored in a file? M -- Mark "No Nickname" Murray Notable nebbish, extreme generalist.
From: David Eather on 16 Jul 2010 21:41 On 17/07/2010 5:59 AM, Bruce Stephens wrote: > adacrypt<austin.obyrne(a)hotmail.com> writes: > > [...] > >> that is by being used in the hands of a non-specialist office worker >> with minimal training (that means no user-assistance whatever). >> 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. 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. > > Be more specific. What "specialist management", precisely, do you think > is required? > > As I mentioned before, just about everybody who uses a computer uses RSA > and some symmetric cipher (more commonly RC4, I'd guess) routinely and > mostly without noticing. Everybody who uses gmail uses RSA and RC4 (or > some other symmetric cipher, if they're sophisticated enough to change > it) every time they check for email. Everybody, every time they use an automatic bank machine uses a full suite of encryption. > > Fewer will use encryption for other purposes, but I see no reason to > expect that they'd find S/MIME or GPG (using RSA, DSA, etc.) > particularly problematic---it's just that few people see a particular > desire to use those. > > Almost all office workers who work from home for some of the time > currently use cryptography in connecting to the office, again without a > particular problem as far as I can tell---not one that would be helped > by your software, anyway. Many will use TLS even inside the office to > connect to mail servers and things inside the office, just because > that's how things are set up (rather than for any particular security > reasons). > > And please stop mentioning RSA: RSA does things which your software > doesn't attempt to do. Asymmetric systems are a different category to > symmetric systems, and yours is symmetric. > > [...] >
From: adacrypt on 17 Jul 2010 02:46 On Jul 16, 10:48 pm, Mark Murray <w.h.o...(a)example.com> wrote: > On 16/07/2010 20:36, adacrypt wrote: > > > Hi, > >> What do you mean by "batch" here? It clearly doesn't mean what other > >> folks understand it to mean. > > Just simply "created at another time and place also, possibly" > > So any data stored in a file? > > M > -- > Mark "No Nickname" Murray > Notable nebbish, extreme generalist. Hi , So far, I have only considered securing textual data - i.e. data as used directly by inspection as readable, humanly understandable information - keyed in by human hand say. On quick reflection I believe I can manage any other data also - say strings of binary (recorded in bytes - probably as analogue binary representations of physical properties) collected from say some embedded system or even a conventional control engineering system in open or closed loops - don't go rabid over this, its just an embryo of an idea at present - may even reversley compress this by means of the ASCII printable subset and then treat it as pseudo plaintext for encryption/decryption by my esatblished methods. purposes. A thing that comes across to me over here is the very narrow breadth of thinking at your end on the other side of the pond - all creative imagination has been frozen by the existing cryptography that you agree is on the way out and indeed should be no matter how popular it is at present - progress requires that as a basic tenet - you guys come across as being a bit insular - if I say cryptography you dont hear general cryptography but instead AES or RSA depending on which camp you follow. If I talked opera would you focus on Porgie and Bess alone cos' that's what your doing in cryptography. Also, Mathematics in Cryptography should mean the whole of mathematics as applied to cryptography not the one-off failed application (i.e. the gimmicky Alice's public key and 'private' key being made to fit an application of Euler's Theorem fiasco in modular arithmetic) but that's what you get in the same way's another example of scientific insularity. This smallmindedness is choking progress - adacrypt
From: adacrypt on 17 Jul 2010 03:10 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, >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. 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. 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) 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. Images won't be a problem - why do you say UTF 8 as if it wasn't already coverd by the generic class Unicode? - cheers - adacrypt
From: adacrypt on 17 Jul 2010 04:04
On Jul 17, 8:10 am, adacrypt <austin.oby...(a)hotmail.com> wrote: > 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, > > >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. > > 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. > > 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) > 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. > > Images won't be a problem - why do you say UTF 8 as if it wasn't > already coverd by the generic class Unicode? > > - cheers - adacrypt- Hide quoted text - > > - Show quoted text - PS. >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 both process >belonged in the same branch of mathematics. Should have stated that they do not have to belong in the same branch of mathematics but it is most likely to work best if it is - being asymmetric is just incidental - adacrypt |