Cryptography-Digest Digest #251, Volume #13 Fri, 1 Dec 00 14:13:01 EST
Contents:
Re: Pentium 4 and modular exponential (Francois Grieu)
Re: Working area of SSL ? ("Scott Fluhrer")
Re: Trivial Encryption Algorithm (TEA) (John Myre)
Re: "Minesweeper" algorithm? ("madcow")
Re: A Simple Voting Procedure (Darren New)
JOB: Software Engineer : Security - Ohio ([EMAIL PROTECTED])
Re: "Minesweeper" algorithm? (Darren New)
Re: Working area of SSL ? (Darren New)
Re: Public key encryption in Javascript? ([EMAIL PROTECTED])
Re: JOB: Software Engineer : Security - Ohio ("Trevor L. Jackson, III")
Re: Trivial Encryption Algorithm (TEA) ("John A. Malley")
Re: keysize for equivalent security for symmetric and asymmetric keys (Richard
Heathfield)
Re: SRP - not good enough? (Bill Unruh)
Re: A Simple Voting Procedure (Jerry Leichter)
Re: Cryptosecurity by another name (Mok-Kong Shen)
Re: Cryptosecurity by another name (John Savard)
Re: JOB: Software Engineer : Security - Ohio (Mike Rosing)
Re: SRP - not good enough? (John Savard)
Re: weten we die PIN? ("Erwin Graumans")
----------------------------------------------------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Pentium 4 and modular exponential
Date: Fri, 01 Dec 2000 15:38:30 +0100
Wei Dai <[EMAIL PROTECTED]> wrote:
> What would be nice is if Intel could tell us the optimal
> sequence of SSE2 instructions to multiply two 256 bit numbers together.
The official word on this is probably AP-941: Using Streaming SIMD
Extensions 2(SSE2) to Perform Big Multiplications, available
(with other technotes) at
<http://developer.intel.com/software/products/itc/sse2/sse2_appnotes.htm>
I only glaced at the thing, and noticed they use base 2^29 in order
to circumvent carry propagation issues.
Francois Grieu
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Working area of SSL ?
Date: Fri, 1 Dec 2000 06:48:19 -0800
kihdip <[EMAIL PROTECTED]> wrote in message
news:907ob5$aj1$[EMAIL PROTECTED]...
> A protocol question:
>
> IPsec works on the network layer in ISO's reference model OSI.
> Where does Secure Socket Layer apply the encryption ?? (I think the answer
> would be the presentation layer - correct me if I'm wrong)
I believe it's called the transport layer. In fact, SSL has been recently
redubbed TLS -- Transport Layer Security
--
poncho
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Trivial Encryption Algorithm (TEA)
Date: Fri, 01 Dec 2000 08:10:19 -0700
"John A. Malley" wrote:
>
> Benjamin Goldberg wrote:
> >
> [snip]
> >
> > I've forgotten... why is it important that DES not be a group?
> >
>
<snip>
> Assume the DES applied to messages m in M is a group where permutation
> is the operator on the group and M is the set of elements in the group.
No, when we talk about DES being a group, the group elements
are not the messages but the keys.
> For any two permutations p_1 and p_2 applied to any message m in M,
> there would be a third permutation p_3 such that p_2( p_1(m) ) =
> p_3(m).
Right, where p_1, p_2, and p_3 are the permutations defined
by three keys k_1, k_2, k_3.
> Every multiple encryption (or composition of permutations)
> could thus also be given by a single encryption. So encrypting the
> message, and then encrypting the ciphertext of that encryption, would be
> just as secure as encrypting the message once.
Right.
> The DES as a group would allow Meet-In-The-Middle and
> Cycling-Known-Plaintext-Attacks on the DES, and these are less work than
> brute-forcing the cipher.
That's not it. The really bad result (if DES were a group)
would be that "triple DES" would be equivalent to single DES.
(That is: a 168-bit triple DES key is just three 56-bit
single DES keys; doing triple DES just means doing DES three
times; if DES were a group then any triple DES operation,
which is the composition of three single DES operations,
would be equal to some equivalent single DES operation,
defined by some 56-bit key. Thus an attacker need not ever
know the 168-bit key, because he only needs the equivalent
56-bit key, which he can find by brute force.)
JM
PST: "OTP is a group"
------------------------------
From: "madcow" <[EMAIL PROTECTED]>
Subject: Re: "Minesweeper" algorithm?
Date: Fri, 1 Dec 2000 10:20:26 -0500
Max Polk <[EMAIL PROTECTED]> wrote in message
news:MPG.1490e98a33f4224298969a@news-server...
> We all know of the Windows "minesweeper" game, where you are only told
> how many bombs are adjacent to each square, and where you have to use
> logic to determine where the bombs are.
>
> If we turned a message into bits and formed a grid from these bits, where
> each bit is a "bomb" as if we were playing the "minesweeper" game,
> couldn't we calculate the relative bit density of each square, just as in
> the minesweeper game, to arrive at an encrypted message made up of
> relative bit density counts?
>
> And then we could decrypt by programmatically "playing minesweeper" to
> arrive at the original message.
>
> To add real meat to the encryption, could we take the output of one phase
> of this encryption, and after evening out and scattering the bits with
> some standard intermediate phase, feed it right back in to the same grid,
> but using a different grid width, and calculate relative bit densities
> from that?
>
> If so, the "key" would be which grid width you used on the first phase,
> followed by which grid width you used on the second phase, and so forth.
> By making the grid width highly variable, I feel that this may be
> mathematically complicated to break.
>
> After all, the basis is not the conventional technique of taking blocks
> of data and performing well-known bit manipulation like xor, add,
> subtract, invert, reverse, look-up tables, and so forth, on it.
>
> Instead, it is based on "playing minesweeper" which adds the need for
> game-playing logic to crack it. Can anyone please point out weaknesses I
> am missing?
Yes. A paper has been written on the subject, it is described here:
http://www.mat.bham.ac.uk/R.W.Kaye/minesw/minesw.htm
The paper was to be in the "Mathematical Intelligencer," but I haven't seen
it yet.
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Fri, 01 Dec 2000 15:26:19 GMT
Shawn Willden wrote:
> Actually, he forced them to state *some* vote.
He could force them to state their vote under oath. Some people take oaths
seriously, even without threat of violence.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
There is no "P" on the end of "Winnie the Pooh."
------------------------------
From: [EMAIL PROTECTED]
Subject: JOB: Software Engineer : Security - Ohio
Date: Fri, 01 Dec 2000 15:27:16 GMT
Job Location:
Akron/Canton, OH
Job Summary:
We are on retainer with a premier Fortune high technology manufacturing
company that manufacturers self-service terminals for financial
applications (Automated Teller Machines)
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
individual will provide input, such as software algorithms, information
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.
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
Compensation/Benefits:
Salaries based on candidates experience level. Full
relocation and interview expenses provided.
How to Apply:
For immediate consideration, please e-mail or fax your
resume TOLL-FREE to:
Heidi Kay, President/Certified Personnel Consultant
Kay Concepts, Inc.
Toll-free fax: 800-879-5828
E-Mail: [EMAIL PROTECTED]
Kay Concepts is delighted to receive your resume
via text e-mail, however your unique personality is
better reflected to our clients by your word processor
created resume by fax or e-mailed as an attachment
in Word or WordPerfect.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: "Minesweeper" algorithm?
Date: Fri, 01 Dec 2000 15:43:05 GMT
Max Polk wrote:
> Instead, it is based on "playing minesweeper" which adds the need for
> game-playing logic to crack it. Can anyone please point out weaknesses I
> am missing?
How about setting up a ROGUE game with your plaintext scattered about the
"dungeon" and using the output of rogomatic to encrypt it? :-)
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
There is no "P" on the end of "Winnie the Pooh."
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Working area of SSL ?
Date: Fri, 01 Dec 2000 15:43:59 GMT
Scott Fluhrer wrote:
> I believe it's called the transport layer. In fact, SSL has been recently
> redubbed TLS -- Transport Layer Security
That's because the internet doesn't have a presentation layer.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
There is no "P" on the end of "Winnie the Pooh."
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Public key encryption in Javascript?
Date: Fri, 01 Dec 2000 15:45:33 GMT
But I'm not shooting for perl -- my goal is Javascript... I'm just more
familiar with perl. Now that I know it works I'll try to rewrite it in
Javascript.
Math::BigInt is such a copout... Watching all my strings of ones and
zeros fly by -- now that's what cryptography is all about, right?
j
In article <[EMAIL PROTECTED]>,
Paul Rubin <[EMAIL PROTECTED]> wrote:
> If you're trying to do it in perl, just use the Math::BigInt module
> that's part of the standard perl distribution (Camel book 2nd ed. p.
460).
> Doing a 512-bit modexp in the obvious way with that library takes a
> few seconds on a current x86 workstation.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 01 Dec 2000 11:09:23 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: JOB: Software Engineer : Security - Ohio
Plea to readers: Please call the toll-free number below and inform Ms. Kay
that her post in sci.crypt is offensively off topic.
[EMAIL PROTECTED] wrote:
> Heidi Kay, President/Certified Personnel Consultant
> Kay Concepts, Inc.
>
> Toll-free fax: 800-879-5828
> E-Mail: [EMAIL PROTECTED]
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Trivial Encryption Algorithm (TEA)
Date: Fri, 01 Dec 2000 08:14:08 -0800
John Myre wrote:
>
[snip]
> No, when we talk about DES being a group, the group elements
> are not the messages but the keys.
>
Oops. Yes. The DES group, if it exists, is the set of permutations P and
the composition operator ( P, o ) and the composition of one permutation
with another results in a third permutation that is itself in the set
P. Each permutation p in P is specified by a key k in the set of keys
K.
Pardon me while I kick meself.
John A. Malley
[EMAIL PROTECTED]
------------------------------
Date: Fri, 01 Dec 2000 10:56:24 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: keysize for equivalent security for symmetric and asymmetric keys
[newbies please note: Mr Silverman is an expert in cryptography, and I'm
not. Salt this article accordingly.]
Bob Silverman wrote:
>
> In article <[EMAIL PROTECTED]>,
> Richard Heathfield <[EMAIL PROTECTED]> wrote:
>
> <snip>
>
> > Moore's Law. By 2032 (or so), we'll have computers a million times
> > faster than today's computers. By 2066, they'll be one million million
> > times faster. By around 2100, one single computer will be able to do
> the
> > work of the batch of computers you describe in the above paragraph.
>
> This is just silly speculation.
I'd prefer the word 'idle' to 'silly', but I won't press the point.
<snip>
> (a) There are quantum limits to how small one can make gates
> (b) The speed of light is finite
And, indeed, I referred to the fact that we can place a theoretical
upper limit on the amount of computing which can be done in the time
remaining to this universe. (No, I'm not going to dive into a discussion
of multi-universe theories of quantum computing...)
As far as I can see, there is some number N such that there is not
enough time and space in the universe to perform 2^N computations, and
that N is a relatively low number. Even if it were a few thousand, it
wouldn't matter particularly, and it's likely to be lower than that.
Given a key of length N, then, and a halfway decent algorithm, one could
be assured that, except for the most terribly unlikely circumstance
(many orders of magnitude less likely than the proverbial million-to-one
chance), the key could not be brute-forced.
Now, the longer the key, the slower the encryption, all else being
equal. Therefore, those who insist on long keys must pay for them in
terms of more cycles, and time is money, right?
No matter what the long-term prospects for Moore's Law, its short-term
future looks relatively assured, and therefore those who insist on long
keys are going to find those key lengths less and less of an
inconvenience, because they'll be able to encrypt more bits for a given
unit of time; the clocks they might have spent lengthening the key can
now instead be spent on actual encryption, because the point of
lengthening the key vanishes, even to the satisfaction of the most
troubled corporate or military soul.
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.
--
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: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: SRP - not good enough?
Date: 1 Dec 2000 17:09:10 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (John
Savard) writes:
>same general class as SRP, providing good security, but not 'ideal'
>security in a sense (a dictionary attack can be cheaper than cracking
>Diffie-Hellman even once).
But a dictionary attack is always possible. Say a user chooses the
password "a" I then launch a dictionary attack starting with one letter
alphabet words. I get it first try. I have just launched a dictionary
attack and no protocol can protect me against that. Any password system
is only as strong as the passwords actually used. And any password
system can be dictionary attacked. You can always put on other external
safeguards, such as time delays etc, but once the password file is
stolen, then I can set up a server with those external safeguards
disabled.
Placing the password split amongst several servers is also possible, but
then that just doubles or triples the effort of breaking in.
>Presumably, one could envisage a protocol in which the user's password
>was augmented with something on the user's computer to give the user,
>in effect, a longer password. This would prevent dictionary attacks if
?? Since both the user and the server must have the same information to
make that longer password useful, you then have the problem of
communicating the random something to the user.
>the server, but not the user's computer, was compromised, and it would
>therefore be of value in some situations.
I do not see how. The server needs that extra information. How is it
communicated to the server?
------------------------------
From: Jerry Leichter <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Fri, 01 Dec 2000 12:31:30 -0500
| > The judge was ultimately overturned on appeal. In the US, you
| > cannot be ordered to reveal your vote.
|
| Yes, nevertheless he successfully ordered three people to reveal their
| votes. Had each of those three people not revealed their votes, they
| would have been thrown in jail. If that's not a case of a 3rd party
| forcing a voter to reveal their vote, I can't imagine what would be.
You misunderstand how the law works. Before this case, it was unknown
whether a judge could order you to reveal your vote. After this case,
we know: He can't. Today, those three people - were they cognizant of
the law - could, if they wished, refuse to answer. Note that whatever
the technology, someone can always *ask* you how you voted. The only
thing this legal case deals with is whether you can be compelled to
answer. And the law says you cannot.
-- Jerry
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Cryptosecurity by another name
Date: Fri, 01 Dec 2000 18:55:01 +0100
John Savard wrote:
>
> Mok-Kong Shen<[EMAIL PROTECTED]> wrote, in part:
>
> >I have a problem with your N. How is this determined/fixed?
>
> N is just 2^n if the key happens to be n bits long. It's just the
> number of bit sequences in a family, not a measure of anything.
So I understand that n is the number of bits of the input
to the generator. If n is large enough, brute-force is
beyond question in practice. Now the output sequence can
be very long. If the generator is good enough, one couldn't
predict (again practically) even with an output sequence
much longer than n.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Cryptosecurity by another name
Date: Fri, 01 Dec 2000 18:36:54 GMT
On Fri, 01 Dec 2000 18:55:01 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>So I understand that n is the number of bits of the input
>to the generator. If n is large enough, brute-force is
>beyond question in practice. Now the output sequence can
>be very long. If the generator is good enough, one couldn't
>predict (again practically) even with an output sequence
>much longer than n.
Yes, that's exactly right.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: JOB: Software Engineer : Security - Ohio
Date: Fri, 01 Dec 2000 12:52:12 -0600
"Trevor L. Jackson, III" wrote:
>
> Plea to readers: Please call the toll-free number below and inform Ms. Kay
> that her post in sci.crypt is offensively off topic.
Why? If you're not looking for work, ignore it. If you are looking, it's
mighty nice to see!
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: SRP - not good enough?
Date: Fri, 01 Dec 2000 18:50:09 GMT
On 1 Dec 2000 17:09:10 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote,
in part:
>I do not see how. The server needs that extra information. How is it
>communicated to the server?
I wasn't claiming there must be a way, just that I didn't see a way to
prove there wasn't.
1) Both sides could always set up, with nonce keys, a
non-authenticated Diffie-Hellman session.
2) The password could protect a private key, and the server can have
on it only the public key corresponding to it, yet the two sides can
authenticate.
These steps by themselves don't solve the problem, they just show that
proving what can and can't be done isn't trivial.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Erwin Graumans" <me@home>
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Date: Fri, 1 Dec 2000 20:00:54 +0100
Paul,
het fiatteringsproces van PIN-transacties loopt als volgt:
de automaat verzamelt eerst alle transactiegegevens en stuurt die in 1
bericht naar jouw bank (via een heel lang, maar vooral snel interbancair
datatraject). Jouw bank keurt de transactiegegevens goed of af (incl. je
PIN-code) en stuurt een response terug naar de automaat.
Groeten,
Erwin
"Paul Wessels" <[EMAIL PROTECTED]> wrote in message
news:8vh89b$auv$[EMAIL PROTECTED]...
> We weten, dacht ik wel dat de PIN code van je bankpas van uit de
> magnetische strip berekend wordt uit je banknummer + kaart nummer +
> eventuele offset, door dit met een "geheime" banksleutel en DES te
> versleutelen tot een resultaat waarvan dan de eerste vier cijfers je PIN
> code vormen. Tot zover snap ik het.
> Zonder die "geheime" banksleutel kom ik niet aan een resultaat ook al zou
> ik de hele kaart kunnen lezen ( maakt niet uit of ik naar track 1 , 2 of 3
> kijk).
> Maar nou heb ik in de vakantie eens goed opgelet op wat automaten in het
> buitenland doen. Zowel franse als italiaanse automaten keuren eerst snel ,
> OFF LINE , mijn PIN code goed, als ik daarna verder wil gaan, dan pas
zoeken
> zij contact met mijn bank voor een saldo goedkeuring !!!. Een italiaanse
> automaat maakte dat helemaal duidelijk door op zijn scherm, NA
goedkeuring
> van mijn PIN, mede te delen dat er een telefoon storing was en dat er
daarom
> geen contact met mijn bank gezocht kon worden.
> Hoe kan dat ? Kan er via DES met verschillende sleutels toch een
> goedkeurend resultaat verkregen worden.? Is er _een_ sleutel die
wereldwijd
> geldig is en slikt DES dat dan bij indentieke input ? Of zijn die
> buitenlandse automaten meer van het gemakkelijke type dat zegt "OK, het is
> toch maar een pas van een vreemdeling, we keuren alles goed wat ie aan PIN
> voorstelt ?
>
> paul_wessels@[nospam]bigfoot.com
>
>
>
------------------------------
** 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
******************************
