Slashdot Mirror

I believe Paul Kocher first proposed (this is PDF) this attack way, way back in 1995, and as I recall, he even applied it to networked systems. RSA Labs' BSAFE, since version 3.0 has included a "blinding factor" in its RSA implementation that renders this attack ineffective. Reading the original RSA Labs bulletin (also PDF) on this attack shows a very simple fix, and I'm surprised that this hasn't made its way into OpenSSL! Ron Rivest proposed this back in early 1996. What's up?

The SecureID number is in plain text so that someone with a sniffer-type device could sniff a SecureID number and use it for access.

A distributed lock manager tracks user authentication between replicated servers and blocks redundant requests in order to prevent replay attacks against servers or agents.

I work for a financial institution, so security is paramount.

We found that we had serious security concerns with remote access.

We started using RSA SecurID tokens for authentication (and a tie to a database for authorization). That worked well to secure remote access from company owned equiptment (where we could control the security, set standards for antivirus, etc), but left a major exposure:

Specifically, with a VPN we could secure the transmission, but couldn't verify the security of the end point. And a big value of remote access is the ability to let people work from home on their own gear (and the inherrent cost savings to the company).

So we have a multi-tier solution as follows:

All authorized users can use web services. We make available access to the email system, 3270 access to a mainframe, and some internal applications available to authorized and authenicated users over the internet (HTTPS). These web services have the advantage of being very low cost... almost zero incremental cost per user assuming they are not bandwidth intensive.

People with company-owned equiptment (laptops) can use dial-in services, which we provide through Cisco AS-5300's, with strong authentication provided by RSA SecurID. Costs a little to invest in the Cisco gear, and costs a little to support in house.

For those wanting VPN access, we found a company that could address our security concerns... a managed VPN provider called Positive Networks. Positive addresses our security concerns by providing the ability to enforce security policy on the end computer (such as X-brand Antivirus must be installed and running with up-to-date pattern files), as well as providing a managed service at a reasonable cost (its been more effective for us to outsource this big chunk of remote access, rather than staffing for supporting it internally).

I would strongly recommend Positive Networks as a remote access solution.

No affiliation other than a satisfied user (and I'm primarily responsible for our company selecting their product).

I work for a financial institution, so security is paramount.

We found that we had serious security concerns with remote access.

We started using RSA SecurID tokens for authentication (and a tie to a database for authorization). That worked well to secure remote access from company owned equiptment (where we could control the security, set standards for antivirus, etc), but left a major exposure:

Specifically, with a VPN we could secure the transmission, but couldn't verify the security of the end point. And a big value of remote access is the ability to let people work from home on their own gear (and the inherrent cost savings to the company).

So we have a multi-tier solution as follows:

All authorized users can use web services. We make available access to the email system, 3270 access to a mainframe, and some internal applications available to authorized and authenicated users over the internet (HTTPS). These web services have the advantage of being very low cost... almost zero incremental cost per user assuming they are not bandwidth intensive.

People with company-owned equiptment (laptops) can use dial-in services, which we provide through Cisco AS-5300's, with strong authentication provided by RSA SecurID. Costs a little to invest in the Cisco gear, and costs a little to support in house.

For those wanting VPN access, we found a company that could address our security concerns... a managed VPN provider called Positive Networks. Positive addresses our security concerns by providing the ability to enforce security policy on the end computer (such as X-brand Antivirus must be installed and running with up-to-date pattern files), as well as providing a managed service at a reasonable cost (its been more effective for us to outsource this big chunk of remote access, rather than staffing for supporting it internally).

I would strongly recommend Positive Networks as a remote access solution.

No affiliation other than a satisfied user (and I'm primarily responsible for our company selecting their product).

They have linux , windows, and mac clients, and our implementation uses SecurID for authentication, so at least it seems secure. (not being a security expert I have no idea if it actually is.)

Your points are well taken.

I was, simply addressing the comment I quoted, which implied no collisions were known. (They are: an early example can be found in B. den Boer and A. Bosselaers, "Collisions for the compression function of MD5", Advances in Cryptology - Eurocrypt '93, Springer-Verlag, p. 293-304)

However, as an academic matter, I think it can be estimated that a modest corporate budget might construct an MD5 hash matching machine bank for under $1M, if an organization saw a commercial need that justified multiple units (reducing the cost per unit, as well documented in the articles on the custom designed EFF DES cracker)

Rivest was, of course, the R in RSA, and according to a somewhat outdated FAQ on the RSA Security website:

" Van Oorschot and Wiener [VW94] have considered a brute-force search for collisions (see Question 2.1.6) in hash functions, and they estimate a collision search machine designed specifically for MD5 (costing $10 million in 1994) could find a collision for MD5 in 24 days on average. The general techniques can be applied to other hash functions." [ P. van Oorschot and M. Wiener, Parallel collision search with application to hash functions and discrete logarithms, Proceedings of 2nd ACM Conference on Computer and Communication Security (1994)]

Applying Moore's Law as a rough guide, ignoring all the work on algorithms and programmable chip architecture in the past 10 years, a $10M machine would cost 1/64th as much today, or $156K to develop, and much less per unit in quanitity (i.e. parts/construction cost could be under $1K, so 850 units might be constructed for $1M) Again, I cite the EFF DES cracker as a very close example.

That still leaves us with 24 days per collision. If I may be forgiven for positing, purely for purposes of guesstimation, a Moore's Law scale for advances in this hot field of mathematics (which would probably not displayed a steady improvement, but would likely have had crucial breakthroughs in the past 10 years) then the 24 days would be 2.25 hours today. To be conservative: say 1-10 /day

This is, of course, just a crude guesstimate, but I think that you would agree that a bank of 850 machines, a mere $1M in hardware, cranking out 10 exact matches for targeted files, per macthine, per day (8500 spoofed files per day) could present a significant contamination of the media pool.

I *DO NOT* believe that this represents a major enduring danger to P2P, or that the RIAA would actually construct such a bank. I merely note that $1M (plus operating costs) would be a drop in the bucket to the RIAA, and that the error bars go in both directions (i.e. current mathematical methods might be more efficient than a 1994 estimate, when MD5 was a fairly new, less researched algorithm.)

This is just an academic observation on the potential for MD5 collision matching since its introduction in '91. This is not my field. "Dammit Jim, I'm a doctor, not a Cryptographer."

RSA factoring FAQ

The RSA signature used to sign/for comparison purposes used with Xbox execuatables is 2048 bits long.

Common secure internet traffic, carrying thousands of credit card numbers as we speak, uses 128 bit keys (almost always).

To beat the dead cliche, you are comparing apples and oranges. The 2048 bit keys used in the X-Box are asymmetric. The 128 bit keys used by SSL are symmetric. SSL negotiates the symmetric key by using the RSA algorithm: a method of using asymmetric keys to securely determine and exchange a random symmetric key.

The 2048 bit key is not necessarily out of reach. 512 bit keys were breakable for less than $1,000,000 investment in 1997. It's likely that 1024 bit keys can be broken today with a similar investment. See what the experts have said about the feasibility of attacking these keys.

In case some of your forget: it gets exponetionally harder as the length of the key increases. It's not like you just have to search a 128 bit key space 16 times. There are fancy methods where by you can get away with knowing some of the key like differential analysis, but when you increase the size of the key the performance of those tend to fall off also where you have no increase over brute force and man in the middle attacks.

Asymmetric keys DO NOT get exponentially harder as the bit size increases. I'm not very knowledgeable about cryptography but even I can spot complete ignorance.

Many comments here assume that the time to factor a composite integer N is proprotional to N, which is, happily, quite incorrect. Even by trial division, you only have to test prime divisors <=sqrt(N), and there are many far more efficient factoring methods.

RSA Security Inc. has quite informative FAQs on this subject, for example The RSA Factoring Challenge FAQ or What are the best factoring methods in use today?

A good paper, "A Survey of Modern Integer Factorization Algorithms" by P.L.Montgomery, can be found at Crypto World. It is slightly math-inclined but definitvely a worthwhile read for anyone interested in the topic.

Now for the bad news: 2048 bits can't be done today. Even GNFS, the best algo in town, has only managed to factor a 512 bits RSA key (and a 158 decimal digit number, with a 576 bits RSA coming soon, though) but 2048 bits will be million times harder. Right now there's no way to factor that, if Microsoft has chosen the primes for the key even remotely securely. I'm sorry to say that but with present technology, this project is a waste of time.

Alex

Many comments here assume that the time to factor a composite integer N is proprotional to N, which is, happily, quite incorrect. Even by trial division, you only have to test prime divisors <=sqrt(N), and there are many far more efficient factoring methods.

RSA Security Inc. has quite informative FAQs on this subject, for example The RSA Factoring Challenge FAQ or What are the best factoring methods in use today?

A good paper, "A Survey of Modern Integer Factorization Algorithms" by P.L.Montgomery, can be found at Crypto World. It is slightly math-inclined but definitvely a worthwhile read for anyone interested in the topic.

Now for the bad news: 2048 bits can't be done today. Even GNFS, the best algo in town, has only managed to factor a 512 bits RSA key (and a 158 decimal digit number, with a 576 bits RSA coming soon, though) but 2048 bits will be million times harder. Right now there's no way to factor that, if Microsoft has chosen the primes for the key even remotely securely. I'm sorry to say that but with present technology, this project is a waste of time.

Alex

Which, however, does not mean it's easy. RSA has been running the RSA Challenge for a few years now, the lowest prize being $10,000 for a 576-bit key and up to a whopping $200,000 for a 2048-bit key -- like the one in the Xbox. There have been no takers yet, and the largest RSA key cracked to date remains 512 bits. RSA's own estimate is that you would need 320 million 520 MHz Pentium-class machines to crack a 1024-bit key in one year, and we're talking 2^100 times that for a 2048-bit key!

Cheers,
-j.

Which, however, does not mean it's easy. RSA has been running the RSA Challenge for a few years now, the lowest prize being $10,000 for a 576-bit key and up to a whopping $200,000 for a 2048-bit key -- like the one in the Xbox. There have been no takers yet, and the largest RSA key cracked to date remains 512 bits. RSA's own estimate is that you would need 320 million 520 MHz Pentium-class machines to crack a 1024-bit key in one year, and we're talking 2^100 times that for a 2048-bit key!

Cheers,
-j.

RSA is currently providing monitary awards for groups who can crack a larger RSA key than has been cracked before. Here's a quote from the FAQ associated with that contest:

• To date, the largest number of this type to be factored is 512 bits. It was factored in 1999 as part of the previous RSA Factoring Challenge, which this challenge replaces. See the announcement for information about this factorization. The 576-bit value is likely to be factored in the next year or so,
• while RSA-2048 should stand for decades.

RSA is currently providing monitary awards for groups who can crack a larger RSA key than has been cracked before. Here's a quote from the FAQ associated with that contest:

• To date, the largest number of this type to be factored is 512 bits. It was factored in 1999 as part of the previous RSA Factoring Challenge, which this challenge replaces. See the announcement for information about this factorization. The 576-bit value is likely to be factored in the next year or so,
• while RSA-2048 should stand for decades.

or otherwise does anyone think RSA would offer $200,000 to anyone able to crack a 2048-bit RSA key generated by them (exactly the same kind of key)?

That is slightly incorrect. For normal symmetric key ciphers (DES, AES, IDEA, Blowfish, etc.) that is how you do it. This, though, is RSA, which is a asymmetric key cipher. This means that you have access to the public key, and you know that the public key is the product (as in multiplication) of the two parts of the private key, N=p*q. So, when bruteforcing, you only need to try 2^1024 keys, which is a lot better, but still infeasible. There are nice ways of doing better, though. The largest effort I know of is when the RSA-155 (512 bit) challenge was factored in 1999, using more than 35 cpu years. This would take about 2^512 times as long...

First question:
Yes, using Shor's factoring algorithm.
(See, for instance: "Quantum Computation and Shor's Factoring Algorithm."
A Ekert and R Jozsa. Reviews of Modern Physics, pages 733--753, July 1996)

Second question:
If "convential methods" mean the methods currently available..
I'd have to say 3. Definetly 3.

If anyone wants to make a quick $200k, there's always the RSA challenge.
The 2048-bit number has yet to be cracked.
The 576-bit hasn't been cracked either, or anything in between.

What about Public Key Crpto? Without public key crypto, E-business would be a very risky venture not to mention hundreds of other technologies that rely of public key.

Here's a totally different solution: go with something like RSA's SecureID. This eliminates the need for users to change passwords, since the password rotates every second. And the server software runs on various platforms (*nix, windows, Novell). And you have better security since user passwords rotate every minute or so. We use it at work and it's great.

MD5 Checksums have a higher rate of collisions, both in the wild and artifically. A machine can be built for only around $100k or less which can find collisions in less than 24 hours. Hell, in a few years standard computers could probably generate collisions easily. SHA1 (Simple Hash Algorithm) is a much better alternative over MD5.

The previous version of MD5, MD4, was so flawed it is now considered "broken". "Dobbertin [Dob95] has shown how collisions for the full version of MD4 can be found in under a minute on a typical PC... Clearly, MD4 should now be considered broken.".

SHA1, while of the same family of hashes as MD4 and MD5, remains uncompromised by any research discoveries, and is widely used in many applications requiring the highest levels of security.

Gnutella, the File Sharing Protocol, uses SHA1 over MD5 for the same reasons I state here. A developer of Bitzi (the Metadata/Hash catalog) has also recommended to the Gnutella Developer Forum not to use MD5, but SHA1 instead. Thus, people should be using SHA1 instead of MD5. I've noticed some major websites and companies are using MD5 hash's now, such as Adobe and Roxio. I would recommend to them to change them to SHA1 instead, since Gnutella supports it (and the fact that it is a much more secure and stronger hash algorithm)... and they can use MAGNET URI's to link to the files on Gnutella.

And, while I'm no number theorist (or a mathematician,
for that matter), I don't see any way that either end
could verify the shared key was generated by his/her
secret parameter without knowing the other's secret
parameter, which would be as bad as sending a symmetric
key in the clear, it appears. This document
for illustrates the attack you described.

So what the world needs
is a chat program that will still use AOL/ICQ as
a transport, be easy to use, and support the use
of gpg keys out of the box, it seems.

For internal use only, there is no reason you can't be your own CA, as long as you prepare a standard client load for all of your internal users. SSL is no less secure, all the cert is used for is negotiating a session key anyway.

If you're going to enroll for more than 30 or so SSL certificates a year, you have a couple of alternatives to keep costs down. You can run a RA, which means you register the certs and a trusted CA signs them (VeriSign operates under this model), or you can get a subordinate CA that is signed by a trusted CA (RSA bought Xcert so they could offer this service).

The first company to offer a tool to let you manage your own CA was Netscape, which became iPlanet, and was bought by Sun. Their documentation is great, read this explanation of the benefits of a Self-Signed Root Versus Subordinate CA.

RSA writes very good docs too, but they're new to the CA business, and I believe the way their KCA product is positioned and pricing model will change. They are mostly interested in customers who use a lot of certs, for now.

I'm glad I'm using 1024bit encryption. They've worked so hard to do 64 bit. But each additional bit is a redoubling in the amount of computing power it's going to take to decrypt my packets. Good luck!

This is a good joke, but misleading to readers that might not know better.

For their sake: SSH uses both public key and private key (or symmetric) cryptography. Public key crypto uses keys with thousands of bits; private key crypto uses keys with hundreds of bits (older algorithms like DES used only 56). RSA, DSA, and so on are examples of public key crypto. RC5, Blowfish, and such are example of private key crypto.

Their key lengths aren't comparable at all. Whether or not RC5 is "secure" at 64 bits has absolutely nothing to do with using 1024 bits in authentication and session key negotiation.

It took 4 years and 300,000 processors to exhaust the majority of the name space and get lucky enough to find the correct key. That has been demonstrated, that is the accomplishment.

RC5-64 has been proven "insecure"? Hardly. Without even moving to RC5-65 as you have suggested, the very same message can be recoded with a new, randomly generated 64 byte key, encoded with a different number of passes than the previous run, or with a different word size, and the key space will be just as large as for this contest. It only took ~$15,000,000 in hardware, 4 years of electricity, 4 years of maintenance, and four trips around the sun to crack this message of about 50 characters. Gosh, what's to stop anybody from doing it whenever they want to?

It's not just "really hard". It's this hard. Water freezes at 0 celcius, not "when it gets cold enough". It's a stake in the ground, an achievement, and a demonstration (rather than a theoretical limit) that it is not feasible to attack RC5-64 encryption with any regularity, convenience, or economy.

And that comment about distributing the prize money? I encoded that with "rhetorical musing". I am and was well aware of how the money will actually be split, which did not impede my ability to use a little satire to illustrate that a 300,000 processor distributed network is hardly a reasonable way to attack RC5, but thanks for your input anyway.

And just for fun, I was motivated to peruse the contents of this report, mainly for the material that appears on page 39 and the summaries of RC5's results when faced with other attacks.

See our helpful friends (ahem) down at RSA. Dan Bernstein has more here.

So the question is, why don't you use the secure medium in the first place?

Because I only get to see my brother once a year in Cuba. And he has a problem carrying back CD-Rs of random pad material through customs.

verify your PGP (or GPG if you please) fingerprint (assuming you're not being wiretapped as well),

Passive evesdropping (aka wiretapping) does not interefere while verifing a public key fingerprint. So you can verify fingerprints of a public key in a public place.

OTP has other problems, beyond the typical key distribution problem. If a non-random source is used for generating the key material, or if the key pad is accidential reused, then trouble stikes, like it did with Venoma.

OTP also lacks message integerity, so if an attack could cut and paste blocks of encrypted ciphertext, Bob would not be able to detect the altered message if the decrypted text make sense (deposit $1000 to account #1233335632 rather than the modified message of deposit $4950292.95 to #1233335632)

encryptions based on elliptic integrals (which by theorem can't be solved analytically, but I suppose there could be approximations).

Now what methods are you referring to here? Elliptic Curve Cryptography normally is used as a faster version of the Discrete Logarithm Problem (DLP) where it is faster and easier to Exponentiate (x^y) than it is to calculate its discrete logarithm (x such that g^x = h) which is the inverse operation and is much harder to calculate.

So I would be interested in this method of using elliptic integrals.

Quantum computing changes the games of cryptography, but it does not end the struggle of cryptographer vs. cryptanalysis. AES when used with a 256-bit key is expected to withstand a bruce force key search using quantum computing within the near future (less than 10-20 years). Of course quantum computing being a young field there is a chance that a radical discovery may ruin our present best estimates for future capabilitities.

By the way, you fail to mention that many Linux vendors -- i.e., RedHat, TurboLinux -- also have relationships with RSA (type in Linux to see), thus nullifying any potential advantage MS would have over them via RSA.

In other words, this approach only makes sense when the outside services are OSS / FS / public domain, which means that developers of programs can check their integrity and submit improvements.

Granted, peer review by others is always a good idea.

Now what would you say if Microsoft understands this so that they have third parties such as RSA Laboratories help to develop and review their cryptographic routines? It's really not all that hard to believe that third parties work with Microsoft, is it?

I guess my question is, are you claiming that somehow you know more about cryptography than some of the well known members of the crypto community? I guess I'm just curious if giving you the source code is really going to make much of a difference?

This OSS is the only way to achieve peer review trumpet has been tooted too many times without any thought behind it to still be credible.

In other words, this approach only makes sense when the outside services are OSS / FS / public domain, which means that developers of programs can check their integrity and submit improvements.

Granted, peer review by others is always a good idea.

Now what would you say if Microsoft understands this so that they have third parties such as RSA Laboratories help to develop and review their cryptographic routines? It's really not all that hard to believe that third parties work with Microsoft, is it?

I guess my question is, are you claiming that somehow you know more about cryptography than some of the well known members of the crypto community? I guess I'm just curious if giving you the source code is really going to make much of a difference?

This OSS is the only way to achieve peer review trumpet has been tooted too many times without any thought behind it to still be credible.

In other words, this approach only makes sense when the outside services are OSS / FS / public domain, which means that developers of programs can check their integrity and submit improvements.

Granted, peer review by others is always a good idea.

Now what would you say if Microsoft understands this so that they have third parties such as RSA Laboratories help to develop and review their cryptographic routines? It's really not all that hard to believe that third parties work with Microsoft, is it?

I guess my question is, are you claiming that somehow you know more about cryptography than some of the well known members of the crypto community? I guess I'm just curious if giving you the source code is really going to make much of a difference?

This OSS is the only way to achieve peer review trumpet has been tooted too many times without any thought behind it to still be credible.

If you deploy the SecurID hardware tokens, extracting the key from a token is a difficult and destructive process. No uber-hacker is going to be able to take a quick glance at the display on a key fob (or the serial number on the back) and then turn around and break into your systems five minutes later.

If you are feeling really paranoid, you can talk SecurID into selling you the "PINpad" hardware token.

RSA Hardware product line: http://www.rsasecurity.com/products/securid/hardwa re_token.html

I hope you weren't expecting someone to have somehow magically reversed engineered the server for linux.

1. it would be a cryptocracking nightmare.
2. It's illegal - RSA wouldn't allow it and would stop people from hurting their revenue stream.

And assuming someone had done it, where would you get the Tokens from. They don't come free in cereal packets....

If you dont mind spending the mony, you don't have a problem

The ACE/agent is available for Linux. See Agent Support. OK, so BSD isn't supported, but you could play around with the Linux compat stuff or have them all authenticate from the Linux box running ACE/client.

You will have to run an ACE/server on Windows unless they've got Solaris, HP-UX or AIX. See Server Support

People on slashdot seem to be obsessed with getting something for nothing. SecurID is *a really good thing* (we use it at work) - do you think that all that work by Crypto experts could be duplicated by a few spotty geeks with too much time on their hands? Get a grip.

I hope you weren't expecting someone to have somehow magically reversed engineered the server for linux.

1. it would be a cryptocracking nightmare.
2. It's illegal - RSA wouldn't allow it and would stop people from hurting their revenue stream.

And assuming someone had done it, where would you get the Tokens from. They don't come free in cereal packets....

If you dont mind spending the mony, you don't have a problem

The ACE/agent is available for Linux. See Agent Support. OK, so BSD isn't supported, but you could play around with the Linux compat stuff or have them all authenticate from the Linux box running ACE/client.

You will have to run an ACE/server on Windows unless they've got Solaris, HP-UX or AIX. See Server Support

People on slashdot seem to be obsessed with getting something for nothing. SecurID is *a really good thing* (we use it at work) - do you think that all that work by Crypto experts could be duplicated by a few spotty geeks with too much time on their hands? Get a grip.

If I understand the issue... sprintf() has no sanity checking. So anything that uses it becomes a potential buffer overflow vulnerability. In fact, this article on buffer overflows and countermeasures mentions sprintf() and a few others (such as strcpy, strcat, gets) which are common sources of this kind of problem.

Let's hope the hardware encryption is as robust as the XBox (or any other encryption hardware for that matter)

Xix.

Then there is always that long long integer that holds Bill Gate's fortune...

How about the RSA factoring challenge? The biggest prize is $200,000 for the 2048 bit key (256 bytes). That makes it about $781 per byte.

Google for "secret sharing" and you'll find plenty of references. Essentially, the secret (i.e. the password) is converted into a value that intercepts an axis of a n-dimensional graph. m points in n-dimensional space are then generated such that they lie in a straight line on a single plane. You can then distribute the values of the m points safe in the knowledge that you need at least n of them in order to calculate the point of interception of the secret.

AFAIK, this is how things like launch codes for nukes are stored and distributed (to counter the twin threats of elimination of keyholders preventing nukes from being launched, and to prevent a single rogue keyholder launching without appropriate authorisation).

Apologies to the maths/crypto purists out there if my description is fuzzy, over-simplified, or plain wrong, but it's been a while... ;-)

Better explanations can be found on RSA's site and in Ross Anderson's book "Security Engineering"

--

You are right about the public key being used to encrypt (although here symmetrical keys are used), but you can't necessarily easily derive a private key from a public key. In RSA, the two keys are interchangable since they come from e*d=1 mod (p-1)(q-1) and multiplication is commutable, it just tends to be out of courtesy you give out the smaller key (because it requires less cycles to encrypt). Incidentally, it is this interchangeable property that makes digital signing so much easier with RSA than with other algorithms.

I think that contests, when done properly, can't prove security but it certainly can certainly prove a point. I doubt we'll ever see a proof that factoring numbers must be complex, but the RSA challenge proves that, well, anyone who has the technology would rather keep it than the money. Hrm. Well, at least that means a script kiddie or casual hacker can't factor very large numbers, eh?

On board battery? Think of a SecureID card on steroids and you'll get the general idea.

Indeed. borwser implementation of SSL is pretty broken, but since the credit card companies are mostly limiting the card holders liability, it doesn't much matter to the average joe. For secure email, however PKI implementations are (or at least can be) much tighter. The initial outlay to run your own Ceritifcate Authority is expensive however, so this is best suited to large coms/orgs/govs.
Three companies that sell these systems are:
Entrust Inc.
RSA
Baltimore Technologies

<news truth="0">

Mozilla.org has signed a deal with Distributed Computing Technologies Inc. to include encryption research software in the official binary releases of Mozilla 1.0 Release Candidate 5. The RC5 build will include a distributed application to measure the strength of RSA's RC5 cipher, described in RFC 2040.

</news>

You can get them in credit card form. The fob is a bad idea because it gets smashed by keys.

I just attended a network security seminar at a small university in Virginia this past week. I manned the booth for my company, but between rush times I spent most of my time speaking with the people (sometimes competitors) from other booths. One of the engineers at another booth was kind enough to give me an RSA SecurID demo box with two key fobs and all the software I needed to set up a server.

Within an hour of arriving back at my hotel room, I had the software up and running (had to download the Win2K agent from the RSA website), and my login to my laptop was secured via SecurID. Once I arrived home last night, I set up the server on my home network, and now all of my workstations and server (Linux included!) are using RSA SecurID login.

You can run the server on NT/AIX/Solaris (probably more by now because I have an old kit), and there are agents out there for just about any operating system. In addition, you can have routers access the server as if it were a TACACS+ or RADIUS server.

Check the RSA website for more information. The part you'll care most about are the agents (client side of the equation), and I know for sure that there are agents available for Windows, Linux, and Solaris.

Good Luck!

Paul

News flash RSA SecurPC wins award (10/97)

Please note the date. Now, please explain how the SecurPC product differ from the patent claim, other than actually being a product? If you poke around their web site (try searching for disk encryption), you'll see the idea has been done to death

Man, I am so sick of lawyers harassing programmers

*shrugs*... the truth is truth whether or not you provide references. But if you want references, check out RSA's own FAQ. MD4 is definitely broken, and MD5 might have some significant weaknesses. It's likely to be brute forceable with reasonable resources.

...it would boil down to, worst case, factoring n. Which isn't trivial, but the important thing here is that it's constant. One person needs to do it on one machine. Once. Then, you make a wonderful keygen, and it's all over.

I must admit to some curiosity at this point. Exactly which university grants a doctorate in computing to someone who doesn't know how the fundamental hypercube algorithms work, doesn't understand the difference between hypercubes and VLSI, and doesn't even understand the difference between a CPU and an FPU?

Let's see if I can boil the news down to something that Mr. Computing DPhil will understand.

The conventional wisdom is that each processor needs, asymptotically, a huge amount of memory for the number-field sieve. The amount of memory grows steadily with the computation time. The cost of the processor is eventually dwarfed by the cost of memory.

(These effects can already be seen to some extent in today's factorizations. You might think that the cost is about evenly balanced between processors and memory; however, the processors are constantly stalled waiting for random access to memory. A much less expensive processor could easily do the same job.)

My paper shows how to get away with, asymptotically, far less memory per processor (and, furthermore, very simple processors), while keeping the computation and communication costs under control.

These are asymptotic results: theorems saying that there is a huge cost improvement for extremely large factorizations. More work is required to figure out the exact cost of the new algorithms for, say, 1536-bit factorizations. It might turn out that the new algorithms are very helpful in practice. It might turn out that the new algorithms are useless in practice. At this point, nobody knows.