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
******************************
