Digestifier
Sat, 02 Dec 2000 12:02:03 -0800
Cryptography-Digest Digest #259, Volume #13 Sat, 2 Dec 00 15:13:00 EST Contents: Re: SRP - not good enough? (John Savard) Re: AIM Password Decoding for the Inquisitive v1.02 (full text) (John Savard) Re: keysize for equivalent security for symmetric and asymmetric keys (John Savard) Re: Newbie (John Savard) Re: IBM's new algorithm (John Savard) Re: keysize for equivalent security for symmetric and asymmetric keys (John Savard) Re: keysize for equivalent security for symmetric and asymmetric keys (John Savard) Re: JOB: Software Engineer : Security - Ohio (Bob Silverman) Re: File Deleter/Nuker ? (Kent Briggs) Re: Encrypting messages in images?? (John Winters) Re: keysize for equivalent security for symmetric and asymmetric keys (Richard Heathfield) Re: Trivial Encryption Algorithm (TEA) (Gregory G Rose) Re: File Deleter/Nuker ? (Neil Sluman) There was an interesting sting operation in 1999 in Europe, U.S.A., etc. that captured tens of Jews dressed as Orthodox Jews dealing cocaine ... (Markku J. Saarelainen) Re: Secrets ? (John Savard) Re: keysize for equivalent security for symmetric and asymmetric keys (Roger Schlafly) ---------------------------------------------------------------------------- From: [EMAIL PROTECTED] (John Savard) Subject: Re: SRP - not good enough? Date: Sat, 02 Dec 2000 15:02:39 GMT On 01 Dec 2000 22:18:47 -0800, Thomas Wu <[EMAIL PROTECTED]> wrote, in part: >So the >final answer might be that strong password protocols ARE in fact "good >enough" by your requirements. I think they aren't, but I can't prove it. Basically, the assumptions I started with are that: 1) at the start, the client has an opportunity to communicate securely with the host, and the host is informed of the client's password, or a function of it; 2) neither the client's computer, nor the host's computer, is considered to be vulnerable to compromise of the actual computations performed to carry out the protocol; 3) both the client's computer and the host's computer may have some information stored persistently between sessions, _but this information is vulnerable to compromise in both cases_. This does mean that an attacker can simulate everything both computers do, and so test the protocol by trying passwords. So it _seems_ like I can't avoid plaintext equivalence of some of the persistent data - it seems like I can't be immune to a dictionary attack. However, I was thinking I _might_ be missing something nonobvious, involving things like setting up encryption with nonces, functions with one-sided collision resistance, and so on. Now, Kaliski-Ford is one way to achieve a 'good enough' security by changing the assumptions - but only slightly, and in a robust way. I thought in more pedestrian directions, and noted how a specific secure box, which acted like a *good password typer* at the host end could be used. There are other possible variations. Perhaps in addition to a short password for each account, the user might keep a good key on his system in storage protected by one passphrase...i.e., the host computer could retain the password hash of each user _encrypted by his PGP public key_. This way, the user is memorizing a good pass phrase, but not a different one for each computer he uses. Doing encryption inside a secure 'cryptoprocessor' at one or both ends could also solve the problem because all that's needed is secure storage of one private key for each user. So the second question would be, if the assumptions need to be changed, what is the most convenient way to change them, without losing most of the advantages of these schemes? If we can't get exactly what we want, how can we come the closest? Kaliski-Ford is one good answer to that. John Savard http://home.ecn.ab.ca/~jsavard/crypto.htm ------------------------------ From: [EMAIL PROTECTED] (John Savard) Subject: Re: AIM Password Decoding for the Inquisitive v1.02 (full text) Date: Sat, 02 Dec 2000 14:36:50 GMT On Fri, 01 Dec 2000 19:41:03 -0800, Stephen Anthony Uy <[EMAIL PROTECTED]> wrote, in part: >In retrospect, I think it may have been more courteous of me to simply >post my text... please accept my apologies if I'm being annoying. Not at all. But giving the URL is enough, because it is no trouble for those interested to simply visit your site, so there was nothing discourteous about that. Some posts with URLs in them are objected to, but that's because the URL is not likely to be of interest: the post is merely an advertisement of some kind. John Savard http://home.ecn.ab.ca/~jsavard/crypto.htm ------------------------------ From: [EMAIL PROTECTED] (John Savard) Subject: Re: keysize for equivalent security for symmetric and asymmetric keys Date: Sat, 02 Dec 2000 15:17:50 GMT On Fri, 01 Dec 2000 10:56:24 +0000, Richard Heathfield <[EMAIL PROTECTED]> wrote, in part: >Now (and here my poor understanding of cryptography might show through). >N might be slightly larger for asymmetric keys rather than symmetric >keys, because asymmetric keys have some redundant bits (i.e. we know >they're the product of two large primes, so we know, for example, that >the rightmost bit is always 1), but the point is that, at that level of >paranoia, where we are pushing right up against the theoretical limits >of computation, it /doesn't matter/ that N is slightly larger for >asymmetric keys. In percentage terms, the difference is minimal. It is actually considerably worse than that. If we have a good symmetric algorithm, then indeed brute-force search is the best attack. But factoring an RSA modulus is not just, say, 32 times faster than a brute-force search because there are a few redundant bits of information in it. A public-key algorithm can't have layer upon layer of complexity added to it the way a symmetric-key algorithm can: in order to work, it has to consist of essentially a single mathematical step. So the N for an asymmetric key could well be 10 times larger than for a symmetric key. Or the ratio could even be worse: N asymmetric might be proportional to N symmetric squared or something like that. Worse than that, we don't _really_ know *what* the ratio might be, because new, faster methods of factoring are still being discovered. My inclination is, when possible, to exchange secret keys - but also use public-key methods as a kind of backup against compromise of the secret key. But there will always be situations where relying on public-key methods is unavoidable. In either case, public-key cryptography is important and useful, even if I don't find it warm and fuzzy. John Savard http://home.ecn.ab.ca/~jsavard/crypto.htm ------------------------------ From: [EMAIL PROTECTED] (John Savard) Subject: Re: Newbie Date: Sat, 02 Dec 2000 15:06:32 GMT On Sat, 02 Dec 2000 05:27:33 GMT, "Michael" <[EMAIL PROTECTED]> wrote, in part: >I would think a (fast) computer would be perfect for brute forceing it. >But, I have no concept of just how fast the computers 'they' have are. >Mine is not up to the task! The idea is, though, that it's so trivially easy to use a bigger key, it shouldn't be too hard not to have to worry about what computers 'they' have. Unless they can do what Scotty couldn't, but the scriptwriters could and did every week: change the laws of physics. John Savard http://home.ecn.ab.ca/~jsavard/crypto.htm ------------------------------ From: [EMAIL PROTECTED] (John Savard) Subject: Re: IBM's new algorithm Date: Sat, 02 Dec 2000 14:41:32 GMT On Fri, 1 Dec 2000 21:08:53 -0800, "Scott Fluhrer" <[EMAIL PROTECTED]> wrote, in part: >Actually not. No, I forgot those algorithms vulnerable to the bit-flipping attack. I should have said that _many_, not all, secret-key algorithms provide authentication for free - in a sense, but, as I later noted, not the sense applicable to this announcement. John Savard http://home.ecn.ab.ca/~jsavard/crypto.htm ------------------------------ From: [EMAIL PROTECTED] (John Savard) Subject: Re: keysize for equivalent security for symmetric and asymmetric keys Date: Sat, 02 Dec 2000 15:19:55 GMT On Thu, 30 Nov 2000 15:21:28 -0800, David Schwartz <[EMAIL PROTECTED]> wrote, in part: > Moore's Law does not need to continue to hold for your argument to be >correct. The rate of growth of computing power just has to stay the >same. Moore's law is a statement of the rate of growth of computing power. Or maybe you're just saying that he is being imprecise, because computing power might grow in other ways than by putting more transistors on chips... John Savard http://home.ecn.ab.ca/~jsavard/crypto.htm ------------------------------ From: [EMAIL PROTECTED] (John Savard) Subject: Re: keysize for equivalent security for symmetric and asymmetric keys Date: Sat, 02 Dec 2000 15:27:57 GMT On Fri, 01 Dec 2000 23:38:45 -0500, "Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote, in part: >assuming that there are any classical computers in existence in 2100 Barring global thermonuclear war or an asteroid strike, I'd say that's not much of an assumption. Quantum computers have an advantage only for one kind of problem - the kind which requires massive parallelism, but only one of the results. Most problems aren't like that, so a classical computer would continue to be the best approach to solving them. Doubtless, other architectures - conventional parallelism, large neural nets, associative memories - will take on increasing importance as well in the future. Cost considerations might well mean that - even in a few decades - the typical desktop PC will no longer be a true Von Neumann architecture. Maybe we've already crossed that threshold, with the ubiquity of MMX and its Motorola counterpart AltiVec, and just weeks ago, I read news items about single-chip SMP devices. Well, 2100 is a long way away. Perhaps indeed by then most computers will have an on-chip quantum coprocessor...but I think they will still be spending most of their time computing clasically. John Savard http://home.ecn.ab.ca/~jsavard/crypto.htm ------------------------------ From: Bob Silverman <[EMAIL PROTECTED]> Subject: Re: JOB: Software Engineer : Security - Ohio Date: Sat, 02 Dec 2000 15:45:57 GMT In article <908g0a$9vf$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > Our client is growing and as a result has a need for a talented, > Software Engineer who has some expertise in Software Security and > Cryptography. > > This is a senior level software and systems engineering position. The > individual will be responsible for the investigation and implementation > of such software and hardware components that ensure the secure > transfer and storage of sensitive financial institution and individual > customer data. This will include, but not be limited to, transfer and > holding of customer PIN's cryptography keys and algorithms. The > > on current industry trends, to various internal software groups. Will > ensure that algorithms and techniques used for data security meet > government and industry standards specifications. So you need someone who knows FIPS standards as well. Why don't you mention this in your list of required qualifications? This is much more important than knowing an OS or language {which you do specify) > > Qualifications > * A BSEE or BSCS or equivalent degree with 5 to 7 years of > programming experience > * Experience in cryptography and other PC security projects > * Experience with data communications standards and trends > * Experience with C, C++ and general software and system > development practices > * Experience in Windows NT, Windows 98, OS/2 required, Linux and > Unix helpful Your "requirements" are totally screwed up and show that you and you client do not really understand the skills need for such a job. Issues surrounding secure storage of PINS calls for deep understanding. Someone with "some experience" isn't who you want for this. You need a security expert. "some experience" won't cut it. Further, mentioning a specific language/platform/OS, etc. is ridiculous. The person you need will have such knowledge or can easily acquire it. What you need is someone with deep skills in computer science and expertise in security. Period. Such a person may be automatically assumed to have the coding skills needed for the job. And why "5 to 7 years" experience? Are you afraid you might have to pay someone with more experience more than you are willing to pay? You won't find someone with "5 to 7 years" experience who has the required security background. -- Bob Silverman "You can lead a horse's ass to knowledge, but you can't make him think" Sent via Deja.com http://www.deja.com/ Before you buy. ------------------------------ From: Kent Briggs <[EMAIL PROTECTED]> Subject: Re: File Deleter/Nuker ? Date: Sat, 02 Dec 2000 16:13:05 GMT Mark Harrop wrote: > Could some kind soul pls point me in the direction of a Freeware/Shareware > File Nuker ? Or if there are no free types, post the name of your favorite > package. please. I make a shareware program called Directory Snoop. In addition to the regular file wiping function, it can also purge "erased" file names directly out of the directory structure. Works with Win 95/98 systems: http://www.briggsoft.com/dsnoop.htm -- Kent Briggs, [EMAIL PROTECTED] Briggs Softworks, http://www.briggsoft.com ------------------------------ From: [EMAIL PROTECTED] (John Winters) Crossposted-To: comp.security.misc,alt.2600.hacker,alt.security Subject: Re: Encrypting messages in images?? Date: 2 Dec 2000 16:05:56 -0000 In article <j20W5.2045$[EMAIL PROTECTED]>, MindHunter <[EMAIL PROTECTED]> wrote: >It's called Stenography I believe and there are several win based programs >that do it. Look in a search engine Stenography is the process of talking something down in shorthand and then transcribing it back to the original. I think you're thinking of Steganography. John -- John Winters. Wallingford, Oxon, England. The Linux Emporium - the source for Linux CDs in the UK See http://www.linuxemporium.co.uk/ ------------------------------ Date: Sat, 02 Dec 2000 16:34:24 +0000 From: Richard Heathfield <[EMAIL PROTECTED]> Subject: Re: keysize for equivalent security for symmetric and asymmetric keys Tom St Denis wrote: > > > > > You appear to be violently agreeing with me, since you've just neatly > > summarised the point of view I was expressing. > > Perhaps I was mistaken, I thought you said that the cost of encryption > and attacking went up linearly proportional to each other. That simply > is not true. Then I can't have explained very well. I was trying to say that the difference in the cost (of a given amount of security) between asymmetric and symmetric encryption diminished in percentage terms as the key length increases, and that a point would come where there was no conceivable point in increasing key length further (i.e. there is an upper theoretical limit on the amount of computation which the universe can perform, and you don't need a very large key before you've ensured that this limit means your key cannot be bruteforced). The cost of attacking is exponentially (I think!) more expensive than the cost of encryption, and this is precisely the point I was trying to make - that there is a key length where both symmetric and asymmetric key lengths cannot be bruteforced, EVER, and that therefore there will come a time when the difference between them pales into insignificance. -- Richard Heathfield "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999. C FAQ: http://www.eskimo.com/~scs/C-faq/top.html K&R answers, C books, etc: http://users.powernet.co.uk/eton ------------------------------ From: [EMAIL PROTECTED] (Gregory G Rose) Subject: Re: Trivial Encryption Algorithm (TEA) Date: 2 Dec 2000 08:50:48 -0800 In article <[EMAIL PROTECTED]>, Paul Rubin <[EMAIL PROTECTED]> wrote: >TEA uses some 32-bit shifts, but no multiplication. Maybe you're >thinking of RC6 or IDEA. Thanks, I stand corrected. Although I do note that in the paper it mentions a version with multiplication, so perhaps I saw some early version and remembered that. Greg. -- Greg Rose INTERNET: [EMAIL PROTECTED] QUALCOMM Australia VOICE: +61-2-9181 4851 FAX: +61-2-9181 5470 Suite 410, Birkenhead Point http://people.qualcomm.com/ggr/ Drummoyne NSW 2047 B5 DF 66 95 89 68 1F C8 EF 29 FA 27 F2 2A 94 8F ------------------------------ From: Neil Sluman <[EMAIL PROTECTED]> Subject: Re: File Deleter/Nuker ? Date: Sat, 2 Dec 2000 18:08:06 -0100 Mark Harrop <[EMAIL PROTECTED]> wrote: > Hi all... > Could some kind soul pls point me in the direction of a Freeware/Shareware > File Nuker ? Or if there are no free types, post the name of your favorite > package. please. > I am after the kind that write over the disk sector (?) many times to stop > retrieval. > PS. I _AM_ a Newbie, so pls no flames on this tender soul ;-) A related question for others - How do these things work. Is it simply a matter of generating random numbers and writing them to the same place repeatedly or is it more complicated than that? Do most filesystems move data around, and risk leaving traces in the old locations or anything awkward like that. Is a predictable random pattern a bad thing in this case? -- Squigs ------------------------------ From: Markku J. Saarelainen <[EMAIL PROTECTED]> Crossposted-To: comp.security,alt.2600,alt.security Subject: There was an interesting sting operation in 1999 in Europe, U.S.A., etc. that captured tens of Jews dressed as Orthodox Jews dealing cocaine ... Date: Sat, 02 Dec 2000 18:13:21 GMT This is just one example how Jews are often using their religion as their protection against the law enforcement. I have heard and seen many other similar cases. Basically, the U.S. law enforcement has been brainwashed to protect interests of Jews and violations by Jews are often overlooked and ignored, which is very wrong. Actually the U.S. police is more attacking Muslims and other religions than Jews. Sent via Deja.com http://www.deja.com/ Before you buy. ------------------------------ From: [EMAIL PROTECTED] (John Savard) Subject: Re: Secrets ? Date: Sat, 02 Dec 2000 18:32:12 GMT On Sun, 03 Dec 2000 01:44:34 +1100, Mark Harrop <[EMAIL PROTECTED]> wrote, in part: >I thought that the UK, and the USA Classified Info becomes declassified >after a certain time ? ie, after 30 or 50 years ? 50 years, but cryptography is exempt from _automatic_ declassification in both countries. Presumably, too, Bruce may be referring to literature that came some time _after_ the first discoveries of Claude Shannon. John Savard http://home.ecn.ab.ca/~jsavard/crypto.htm ------------------------------ From: Roger Schlafly <[EMAIL PROTECTED]> Subject: Re: keysize for equivalent security for symmetric and asymmetric keys Date: Sat, 02 Dec 2000 12:01:22 -0800 Bob Silverman wrote: > And as I told them it still left keys vulneable to being deliberately > constructed so that they were vulnerable to yet other attacks. Yes, so the requirement does not achieve what they want. > Basically, the "bankers" had heard recommendations (now obsolete) > that strong primes be used in keys. These recommendations were > 20 years old, but the bankers refused to acknowledge that newer > algorithms made the requirement irrelevent. So now we are supposed to believe an RSA/ECC tradeoff because it was inferred from some tables that the bankers signed off on? I don't think so. ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: [EMAIL PROTECTED] You can send mail to the entire list (and sci.crypt) via: Internet: [EMAIL PROTECTED] End of Cryptography-Digest Digest ******************************