Cryptography-Digest Digest #352, Volume #12 Thu, 3 Aug 00 16:13:01 EDT
Contents:
Re: JavaCard vs Multos security ([EMAIL PROTECTED])
Re: Encrypting a String to another String containing only certain characters (wtshaw)
Re: Encrypting a String to another String containing only certain characters (wtshaw)
Re: Let us have Lattice (wtshaw)
Re: Cracking RC4-40 in FPGA hardware ("CMan")
Re: Software package locking (AllanW)
Re: OTP using BBS generator? (Terry Ritter)
Re: OTP using BBS generator? ("Paul Pires")
Re: Cracking RC4-40 in FPGA hardware (Paul Rubin)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: JavaCard vs Multos security
Date: Thu, 03 Aug 2000 19:07:24 GMT
128KB for the JVM. That wont fit into a javacard rom...
In article <[EMAIL PROTECTED]>,
Tom Anderson <[EMAIL PROTECTED]> wrote:
> On 31 Jul 2000, Shawn Willden wrote:
>
> > Daniel James <[EMAIL PROTECTED]> writes:
> >
> > > In article <8ls68p$hr2$[EMAIL PROTECTED]>, wrote:
> > >
> > > > I am somehwat surprised that Multos has so much to offer with
only
> > > > an 8 bit cpu...the new javacard cpu's are 32 bit risc, and that
> > > > has considerable more power to run all the Java bytecode...
> >
> > All the Java bytecode? I'm not sure what you mean by that, but my
> > first take is: not likely. The Java libraries are so huge that any
> > card-based VM is going to have to be stripped down for the
foreseeable
> > future.
>
> this is what's called the 'Java 2 Micro Edition':
>
> http://java.sun.com/j2me/
>
> it's still pretty chunky, though: 128 kB for the JVM and libraries,
and it
> wants a 16-bit chip at the minimum.
>
> tom
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Encrypting a String to another String containing only certain characters
Date: Thu, 03 Aug 2000 12:41:27 -0600
In article <8m9o19$63mcg$[EMAIL PROTECTED]>, "Martin Claviez"
<[EMAIL PROTECTED]> wrote:
> Can I encrypt any string to another string that is containing only certain
> characters ?
> For example I want to encrypt any string and the resulting string should
> only contain
> numbers or letters and NO special characters like ?,!,^,(,), ... and so on.
> Where can I found an algorithm for this task ?
> A strong crypt routine is not required but is welcome.
>
> Bye
> Martin
Be more specific as to numbers of input and output characters, and I will
check the data base of some possibles. This is more common a problem than
many realize. Fear not to give your desired best to worst requirements.
--
Free Circus soon to appear in Philadelphia, complete with a
expectation of elephants, and noisy clowns in undignified
costumes performing slight of logic, and, lots of balloons.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Encrypting a String to another String containing only certain characters
Date: Thu, 03 Aug 2000 12:37:42 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
>
> If your string as input contains, for example, only printable ASCII
> characters, having 95 possible values, and you want to have an output
> string containing only characters from a set of 36, then the way to
> convert between the two is to think of it as if you were converting a
> number between two different bases.
>
One good combination is base 88 to 36, 36=6^2. 88^2<6^5, 88^4<36^5, four
characters of 88 will yield 5 characters of 36.
--
Free Circus soon to appear in Philadelphia, complete with a
expectation of elephants, and noisy clowns in undignified
costumes performing slight of logic, and, lots of balloons.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Let us have Lattice
Date: Thu, 03 Aug 2000 12:20:07 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>
> I have difficulty to understand why you wrote things like
> '(2N+x+y-z) mod 2N'. Isn't that identical to '(x+y-z) mod 2N',
> which is simpler? Further, would '((x+y-z) mod N' be as good
> for encryption purpose as your '((x+y-z) mod 2N)/2' ?
I suppose that my mathematical self is working against myn programming
self. Probably it is best to remind that all results should be forced to
yield 0 to N-1 results by adding or subtracting N as needed.
> Finally, it is a linear transformation. Could you say what
> is its advantage over the Hill cipher? Thanks in advance.
>
> M. K. Shen
There are many possible linear transforms that can be used. Lattice is
not as efficient as Sinnet, which is best visualized in three dimensions,
a resultant set of chained reactions of the form of a torus will return
values to their initial states. There is plenty to study about keys and
the mixture of toruses that may define.
For Sinnet, complete mixing of groups of three characters are done in only
two rounds:
x=b+c, y=a+c, z=b+a. Real Seamen tie knots, knots are analogus to
ciphers, some of which are not meant to be untied, some are for beauty's
sake, but functional art is pleasing.
Breaking a cipher down to simple steps is superior for explanation, and
highlights the possibilites in construction.
--
Free Circus soon to appear in Philadelphia, complete with a
expectation of elephants, and noisy clowns in undignified
costumes performing slight of logic, and, lots of balloons.
------------------------------
From: "CMan" <[EMAIL PROTECTED]>
Subject: Re: Cracking RC4-40 in FPGA hardware
Date: Thu, 3 Aug 2000 12:30:39 -0700
Thanks for the tips on Xilinx. I'll have a look at it
On Beowulf, I don't think the term Beowulf necessarily implies fast
networking. We use cheap (less that $10) ethernet cards. The interprocess
communication is essentially zero. That's the nice thing about the brute
force attack. Each processor is given a portion of the keyspace to search,
it does not have to communicate anything except success.
JK
--
CRAK Software
http://www.crak.com
Password Recovery Software
QuickBooks, Quicken, Access...More
Spam bait (credit E. Needham):
root@localhost
postmaster@localhost
admin@localhost
abuse@localhost
webmaster@localhost
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Paul Rubin <[EMAIL PROTECTED]> wrote in message
news:8mcflf$alp$[EMAIL PROTECTED]...
> CMan <[EMAIL PROTECTED]> wrote:
> >The problem is that RC4 is not really amenable to parallel hardware
> >solutions because of the swapping that is a fundamental part of the
cipher.
> >Perhaps if one could configure enough dual port RAMs on an ASIC the
problem
> >could be solved using massively parallel operations. The problem is bus
> >contention - all of these swaps demand separate buses in a parallel
> >solution. The shear number of interconnections becomes a problem very
> >quickly. Of course a really clever devil may see a way around this
> >difficulty...
>
> I don't see why you need dual port ram. Just use a several separate
> sections of the chip with either separate banks of ordinary single
> port ram, or synthesize the ram out of logic blocks. The single port
> ram means an extra cycle is needed per swap, but that's ok.
>
> The FPGA that I had in mind when I suggested RC4-40 was the Xilinx
> Spartan II (www.xilinx.com). The lowest model has four banks of 4k
> bytes synchronous ram that can all be operated in parallel, plus
> enough CLB's to (it looks to me) provide all the memory needed even
> without any ram arrays. The highest model has about 3x as much stuff.
> They can run at up to 200 mhz, though the logic delays for something
> like this might limit the clock speed to somewhat lower. That's the
> basis for my belief that one of these fpga's can crack rc4 at least as
> fast as a 1 GHz Celeron/PIII, and maybe a lot faster.
>
> The high-end Spartan II costs $10 in large quantity, so the hope is
> that the low-end chip is also around $10 but in small quantity. If
> that's the case, it should be possible to build something comparable
> in cost to your 4-box Beowulf cluster (why Beowulf? The fast
> networking really isn't needed...) but at least 10x faster, using say
> 20 chips.
>
> I'm certainly no hardware guru though. Maybe someone here who is can
> look at the Xilinx page and provide some wisdom on the matter.
------------------------------
From: AllanW <[EMAIL PROTECTED]>
Subject: Re: Software package locking
Date: Thu, 03 Aug 2000 19:25:21 GMT
> "Trevor L. Jackson, III" <[EMAIL PROTECTED]> writes:
> [snip]
> > First, let's dispose of some trivial cases. If the program has a
lesser privilege level
> > than the attacker, the attacker is probably going to win fairly
quickly. Thus a secure
> > program probably needs root/ring 0/etc. capabilities. Of course
the attacker can always
> > use more sophisticated hardware, such as an in-circuit emulator, to
gain an unmatchable
> > advantage, but if the attacker's testing platform matches the run-
time platform then the
> > program has a chance.
> [snip]
Andru Luvisi <[EMAIL PROTECTED]> wrote:
> By requiring that your program runs as root/in ring 0/whatever, you
> are increasing the security dangers associated with a user running
> your product, and decreasing its value to your users. The fact that a
> program is able to run non-root is a security *feature* which is
> valuable to its users.
To more sophistocated users, perhaps. Most users pay attention
to what's needed during installation, and then ignore the whole
concept of privilige.
It's very frustrating. A lot of word processing packages require
you to log in as superuser or Administrator or whatever just
to install the program. Why does a word processor need to have
system priviliges? Just lazy install programs, probably. But
the trouble is, a lazy install program and a trojan horse look
exactly alike.
> [snip]
> > For example, breakpoints and single steps are powerful analytic
tools that can overcome
> > any kind of obfuscation or encryption. But what if the program
interferes with the
> > breakpoint handler? Let's say it stomps on the breakpoint vector
at many places within
> > the code. And it stomps on the vector with a value that is
critical to the operation of
> > the program. Let's say it uses the breakpoint trap as a
replacement for the system
> > services trap (int 21 in PC-DOS lingo).
> [snip]
>
> What happens when some bug in the program which is tickled by
> something in one user's hardware or software configuration goes off?
> Would you rather have the user junk your software, or use a debugger
> to figure out what action it is that is causing the problem and then
> send you a detailed bug report you can use to fix the problem?
Oh, right. "Hello, Microsoft? I've found a bug in Word. Oh,
stand in line you say? Well, this one happens whenever you
underline the phrase "Microsoft Sucks." I used the debugger
to trace it to the routine that starts at 0x00042201, which
sets the ... hello? Hello?"
> By making a debugger unusable, you are making your software less
> valuable to your users.
The only time I ever used a debugger on commercial software
was when I was trying to patch the expiration date.
> [snip]
> > Then we add linkage through the BIOS.
> [snip]
> > Then we add routines that detect the identity of the spawning
process and respond to the
> > debugger by writing to its memory space causing faults within the
> > debugger
> [snip]
> > _Simulate_ debugging yourself. Make patches but remove them before
> > the program runs and restore them when it halts.
> [snip]
> > Then we add routines to detect clock skew.
> [snip]
> > Then we add checksum layers.
> [snip]
>
> And all this costs time and money, which you need to charge your users
> for. Do you think they like the idea of paying your developers to sit
> around writing all these things, rather than creating that new feature
> they need? "Oh gee, this program can't do this basic thing I need it
> to, but I can't copy it! Boy do I feel like I got my money's worth!"
> They will have this reaction *every* time some feature they want is
> missing, and since you can't give them everything they will ever want,
> it *will* happen. If your competition is less concerned than you are
> about this "threat", and spend less time and money implementing this
> "security", they will spend less money to get the same features, and
> stability, and with the same money they will be able to have more
> features and stability.
You're right, of course. But this is EXACTLY what a lot of
commercial programs do.
[snip]
> > The point of all these layers is to eliminate the various classes
of attack. The
> > objective is _not_ to make uncrackable software. The objective is
to make software that
> > take so long to crack that when it breaks no one cares.
> >
> > Just like in crypto.
>
> Unfortunately, in the process you are doing things which are really
> bad for both you and your users.
True. But again, this is the real world.
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: OTP using BBS generator?
Date: Thu, 03 Aug 2000 19:43:50 GMT
On 3 Aug 2000 16:19:48 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (Mark Wooding) wrote:
>[Oh, \deity, not this again.]
>
>Terry Ritter <[EMAIL PROTECTED]> wrote:
>
>> But being "no harder than factoring" is meaningless when an approach
>> *allows* factoring.
>
>You're cleverer than this. Put your brain in gear.
Frankly, I'm not nearly as clever as I would like to be. But I think
this issue is crystal clear.
>Breaking the system is no harder than factoring. Doing foo lets us
>factor. Then breaking the system is no harder than doing foo.
It does seem odd that you are repeating my argument as though it were
yours: When factoring is easy, "breaking" BB&S is easy. And factoring
*is* easy when someone uses a short cycle.
If you are now saying "we should take the effort to not use a short
cycle if we want provable strength," you have joined my position.
>> The alternative is to not use a "special primes" construction, and
>> simply not check for having selected a short cycle. The probability
>> of selecting a short cycle at random is extremely low, but not zero.
>> So where BB&S could argue that their scheme was provably secure, the
>> reduced scheme *might* not be secure, and that is a weakness.
>
>No! You've failed to understand. The security warranty works
>regardless, as long as the modulus is a Blum integer.
Sure. The "security warranty" works in the sense that its assumptions
have not been met, so the warranty does not apply.
The "security warranty" is that BB&S is secure... AS LONG AS FACTORING
IS HARD. But factoring is NOT always hard. For example, Factoring is
not hard if we give away one of the factors. And that is exactly what
we do when we use a short cycle.
>Time to bring out Blum-Goldwasser again. It's a public-key system.
>Important points:
>
> * The private key is a pair of primes p and q, with p = q = 3 (mod 4).
>
> * The public key n is the product of p and q.
>
> * Encryption is done by someone who knows the public key, but not the
> private key. He chooses a random seed value and XORs the plaintext
> with the output of the BBS generator modulo n with the seed he
> chose. He appends the final state value to the ciphertext.
>
> * The sender doesn't know the public key. He can't choose his seed to
> have order, well, anything in particular. If you can compute the
> orders of elements mod n, you can factor n.
>
> * Blum-Goldwasser is semantically secure. This means that no
> polynomially-bounded adversary who can't decide quadratic
> residuosity mod n can compute anything about a plaintext given its
> ciphertext that couldn't be computed without the ciphertext anyway.
>
>The security of Blum-Goldwasser is entirely based on the difficulty of
>predicting the output of a BBS generator *with a random seed*. Semantic
>security is an extremely strong property, so this is an extremely
>important result.
The probability of using a short cycle is very small. But that
possibility is *in* *addition* to the inherent weakness of any cipher
to brute-force keysearch. If we use a short cycle, we have provided
an *additional* way into the cipher. And if the opponents realize our
error, that new way will be rather easy indeed.
The possibility of using a short cycle is preventable, if we will just
take the effort to do it, and that will not affect at all the
probability of choosing the correct key.
>> I claim it is deceptive to call the reduced scheme BB&S.
>
>I don't see it as deceptive.
Right. That's the problem.
>In fact
>
>> It is also deceptive to claim that any system which we can make more
>> secure by our own action is absolutely secure.
>
>Did anyone else hear someone claim that the BBS was absolutely secure?
>I certainly didn't.
Please.
>> Here we have a case where the security guarantee is factoring, but our
>> own inaction can lead to allowing exactly that factoring.
>
>No. Again, see Blum-Goldwasser. Your own web page explains that that
>you must choose the seed value carefully in order to find a long cycle.
So you are now -- finally -- agreeing that it is necessary to choose
the seed to be on a long cycle to guarantee strength?
Congratulations! What a fine idea! You should tell BB&S, they will
be amazed.
>Choosing the primes carefully doesn't guarantee you'll always find long
>cycles, just that one will exist: you then have to find it. In the
>Blum-Goldwasser scenario, the modulus is known to the adversary, and if
>he can, by trying as hard as he can, find a short cycle, then he's
>broken the system.
>
>> Any key-based ciphering whatsoever always has some probability of
>> opponents selecting the correct key at random, and so has inherent
>> weakness. We can't prevent that. But the use of a reduced X^2 mod N
>> structure has *additional* weakness which we *can* prevent. It is a
>> shame to say that is equivalent to the true BB&S design.
>
>But it's *not* additional weakness. It's *exactly the same* weakness,
>with a different hat on.
No, it is an *additional* weakness. An opponent can *also* try any
key, *in* *addition* to checking for a short cycle. Conversely, if
the system is using a short cycle, we do not have to try any keys, so
it is hardly the same weakness, unless you wish to argue that anything
which is broken is "the same" in its weakness.
>> The security warranty from the real Blum, Blum & Shub paper is based
>> upon composites of large primes of a form which they call "special."
>
>No. It's based on the difficulty of the quadratic residuosity problem
>(QRP) modulo a Blum integer. And *nothing else*.
Nonsense. It is the special primes construction which provides cycles
of known long length, so we can check that we are on a long cycle by
stepping around that cycle exponentially. There may be better ways to
assure being on a long cycle, but selecting and using a long cycle is
clearly needed to guarantee that the system we have will not be weak.
>> But now we have people using the part of BB&S they like, and throwing
>> out what they don't like. Do we really think the authors of the paper
>> did not see that possibility and decide against it? Please.
>
>You don't consider that it's possible for mathematicians to prove
>additional properties of a system they've devised, just through
>interest? Oh, well.
Possible, yes. Happened in this case, no.
>> I have seen various recommendations that RSA really should be using
>> special primes. Bob Eachus made one, as far as I remember.
>
>My software generates strong primes for RSA (and BBS, for that matter),
>using Gordon's algorithm. I'm not really sure why I bother: I believe
>the arguments by Bob Silverman and many other experts that it's a waste
>of effort. (But it doesn't take much longer, it doesn't introduce
>weaknesses, and the code's there...) But, basically, I accept that it's
>unnecessary.
>
>Note that we can use cycle-finding to factor RSA moduli too: the result
>that a cycle has a high probability of finding a pair of square roots
>holds even when the modulus isn't a Blum integer. I see a particular
>lack of interest in exploiting this as an attack against RSA.
Short cycles are not really an attack: they are a potential weakness.
A BB&S system which chooses at random will *ALMOST* never choose a
short cycle. But it *might*, and if it *does* choose a short cycle,
an unexpected exposure will occur, which opponents may use.
As I have said many times, this is not a serious practical risk, but
it does point out a fundamental problem in our thinking about
cryptographic proof: Here we have a proof, which I assume is correct,
and we can *still* get a weak system simply by not meeting the proof
assumptions. The assumption that factoring is hard seems obvious, but
factoring is *not* always hard: factoring is only hard if we do things
right. In particular, factoring is only hard if we do not choose x0
on a short cycle.
The ease with which one can accidentally make cryptographic proof not
apply should be a revealing insight.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Thu, 3 Aug 2000 12:44:56 -0700
Terry Ritter <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> On Thu, 03 Aug 2000 07:01:49 -0700, in
> <[EMAIL PROTECTED]>, in sci.crypt lordcow77
> <[EMAIL PROTECTED]> wrote:
>
> >Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >>BBS has been a recurring topic in this group. I have little
> >>knowledge in that but I have the impression that discussions
> >>about it never led to unanimously accepted results. You
> >>may try to look into old postings of this group.
> >>
> >
> >Wrong. Practically everyone accepts that choosing the factors of
> >the modulus to be congruent to 3 mod 4 and picking a random
> >starting point are enough to ensure that the resulting BBS
> >sequence will be secure, based on the computational equivalence
> >of predicting BBS and deciding quadratic residuosity (and
> >therefore factoring).
>
> That is false on its face. You can accept if you want, however.
>
> It is true that using a short cycle would be extremely unlikely. But
> *when* that event occurs, all the math proofs you have will not save
> you, since the resulting system is insecure.
>
> Using a short cycle is unarguably insecure. And, unless we
> specifically prevent it, using a short cycle is an unarguable
> possibility.
>
> The only valid argument here is that using a short cycle would be
> extremely unlikely, and that is no conflict, because I agree.
>
>
> >Terry Ritter is the only proponent of the
> >position that one must take elaborate steps to ensure that one
> >falls into a guaranteed long cycle on the basis of a
> >misunderstanding of the security proof given by Blum, Blum, and
> >Shub and a desire to assert that no cipher can be proven to be
> >secure under reasonable assumptions, such that he can promote
> >his own products that "stack" multiple patented algorithms
> >together.
>
> Alas for the attempt at a personal attack, I have no current
> "products" in that sense. I do hold current patents which represent
> fundamentally new cryptographic technology. You can like that or you
> can hate it, but I own the technology anyway.
>
> Does the fact that I might make money out of improving technology
> somehow make me suspect for pointing out the problems in other
> approaches? Finding the problems is why I have better approaches.
> But I may be one of the few authors and designers who actively seeks
> negative comments and then publishes those on my pages, as readers can
> attest.
>
> My stuff is not intended to replace BB&S or PK, but if they have
> problems that I see, I'm going to say so, independent of whether I can
> profit from that or not.
>
> I have been doing this for the better part of a decade, and I don't
> need to have my motives questioned. By pointing out problems, others
> can make their own informed choices about how to solve those problems
> or perhaps use something else. My patented technology provides
> alternatives which others may weigh against the price of its use.
>
> For free, I offer a 400K Crypto Glossary, plus a free Introduction to
> Cryptography, Literature Surveys also free, plus lots of other stuff.
> You don't have to buy a book to read my stuff, but if you want to read
> it in a library, you can do that too, on any Web terminal.
Well said. I wish that I could be that generous in defending against
nonsensical attacks. The problem with taking the high ground in an argument
is that you must scale it first. I'll keep climbing.
Thanks for the example.
Paul
>
> ---
> Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
> Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
>
>
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Cracking RC4-40 in FPGA hardware
Date: 3 Aug 2000 19:46:46 GMT
In article <8mcbbp$[EMAIL PROTECTED]>,
Paul Morris <[EMAIL PROTECTED]> wrote:
>Anyway, I received a mail from Paul Rubin who suggested building a device
>capable of cracking RC4-40. Since I think cracking a code has more 'wow
>factor' for project markers (and a more tangible goal) I thought I would
>investigate this a little further especially since being in the UK I think
>40 bits is all we can legally import from the US.
Actually, the 40 bit limit has been relaxed to 56 bits recently, and
dropped altogether for exports from the US to EU countries. But most
browsers currently in use still use 40 bits. Plus MS Word uses 40 bits.
>Paul mentioned that RC4-40 is used in exportable web browsers (presumably as
>part of the SSLv3) and for password protected files in Microsoft Word.
>Although RSA's site states that RC4 is considered strong, Paul mentioned
>that it could be broken in 'a few months' with a PIII. Given that RSA
>consider it strong are there any other high profile uses for RC4-40? I'm
>very much looking for some 'wow factor' here!
I'm sure that RSA doesn't consider RC4-40 to be "strong". RC4 when
used with longer keys (such as 128 bits) has no known breaks, and
that's certainly what they mean by "strong". RC4-40, meaning RC4 with
only 40 unknown key bits, is *intentionally* not strong. The 40 bit
limit was chosen several years to be impractical for individuals and
companies to break by brute force, but still crackable by law
enforcement agencies with dedicated hardware. Of course what's
happened since then is fast enough hardware has come within reach of
everyone.
>Fundamentally, Paul suggested that multiple (cheap) FPGAs, running
>multiple threads each, could potentially brute-force break an RC4-40
>in, say, 200 hours or less.
I should add, if someone wants to break RC4-40 in 200 hours, they can
simplify their lives a lot by just using a bunch of PC's and not
messing with special hardware. If you're going to build special
hardware, build it to be fast enough (i.e. use enough parallelism) to
break RC4-40 in (say) 10 hours, not 200 hours.
>Paul coined the name 'Shallow Crack' in reference to the EFF
>Deep Crack machine. Does anybody have any comments on the feasibility of
>this? Given my limited (but burgeoning) understanding of crypto I would
>assume that a brute-force attack like this would require the attacker to
>have both ciphertext and plaintext.
That's correct. In both SSL and Word, enough known plaintext is available
to support a known-plaintext attack.
>If this is the case it makes a transaction using RC4-40, where the
>key used is a session key, impossible to break since even if one
>message is compromised the next transmission will use a different
>key. Or am I on the wrong track?
That's why you need a fast machine--if you want to read several sessions
(Word files, etc.) you have to crack them all separately.
>a, Is the idea outlined above a feasible concept for a 9 month project?
Yes of course it is, if you're determined. Deep Crack took about a
year and was at least 20 times as complicated (it used several
thousand custom ASIC's rather than a few dozen FPGA's, and filled
several equipment racks). Admittedly several people and a fair amount
of money were involved.
>b, Is there a similar yet much easier counterpart algorithm that could prove
>the feasability of the idea (and give me some progress mile stone) along the
>way?
In terms of algorithms, no not really. You have to figure out how to
implement the full algorithm and the search logic in an FPGA. In terms
of milestones, I'd say the following:
1) Examine the data sheets for FPGA's you think might be useable, and
produce a detailed plan on paper of how you're going to design
the cracking engine (build sequencer our out CLB's etc), call up
the vendors and find out how much everything will cost, etc. and
put all that in the paper. As mentioned, I'd start with the
Xilinx Spartan series, but you should also check other
possibilities.
2) Fully design the logic and run it in the software simulator that
the FPGA vendor supplies.
3) Build and test the cracking circuit but using just one FPGA chip
on a test board, controlled by a PC.
4) Build and package the multi-chip unit.
>c, If I don't have both ciphertext and plaintext how can a brute-force crack
>work?
Basically it can't. But known plaintext is usually available.
------------------------------
** 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
******************************
