Slashdot Mirror

Other notable minor changes (yes, I noticed the oxymoron too):

-because it breaks the main font app when the app is running on XP (likely an MS bug).
+because it breaks the main font app when the app is running on XP.

They don't want MS to be associated with bugs?

- // The Windows API sometimes fails to indentify the file system correctly so we're using "raw" analysis too.
+ // The Windows API sometimes fails to indentify the file system correctly (observed under Windows XP) so we're using "raw" analysis below too.

Alright, maybe they're okay with XP taking some heat, as long as Win 7&8 are implied to be better.

-- Microsoft Visual C++ 1.52 (available from MSDN Subscriber Downloads)
+- Microsoft Visual C++ 1.52
...
- header files (available at ftp://ftp.rsasecurity.com/pub/...)
+ header files
...
- wxWidgets 2.8 library source code (available at http://www.wxwidgets.org/
-- FUSE library and header files (available at http://fuse.sourceforge.net/
- and http://code.google.com/p/macfu...)
+ wxWidgets 2.8 library source code
+- FUSE library and header files
- RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki) 2.20
- header files (available at ftp://ftp.rsasecurity.com/pub/...)
- located in a standard include path or in a directory defined by the
- environment variable 'PKCS11_INC'.
+ header files located in a standard include path or in a directory
+ defined by the environment variable 'PKCS11_INC'

They're trying to make it harder to find what you need to build your own binaries?

Also, when did /. start auto-creating links? Yes, I used preview and actually edited my post before submitting. Although now since I said that, someone will point out a typo somewhere in my post.

Other notable minor changes (yes, I noticed the oxymoron too):

-because it breaks the main font app when the app is running on XP (likely an MS bug).
+because it breaks the main font app when the app is running on XP.

They don't want MS to be associated with bugs?

- // The Windows API sometimes fails to indentify the file system correctly so we're using "raw" analysis too.
+ // The Windows API sometimes fails to indentify the file system correctly (observed under Windows XP) so we're using "raw" analysis below too.

Alright, maybe they're okay with XP taking some heat, as long as Win 7&8 are implied to be better.

-- Microsoft Visual C++ 1.52 (available from MSDN Subscriber Downloads)
+- Microsoft Visual C++ 1.52
...
- header files (available at ftp://ftp.rsasecurity.com/pub/...)
+ header files
...
- wxWidgets 2.8 library source code (available at http://www.wxwidgets.org/
-- FUSE library and header files (available at http://fuse.sourceforge.net/
- and http://code.google.com/p/macfu...)
+ wxWidgets 2.8 library source code
+- FUSE library and header files
- RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki) 2.20
- header files (available at ftp://ftp.rsasecurity.com/pub/...)
- located in a standard include path or in a directory defined by the
- environment variable 'PKCS11_INC'.
+ header files located in a standard include path or in a directory
+ defined by the environment variable 'PKCS11_INC'

They're trying to make it harder to find what you need to build your own binaries?

Also, when did /. start auto-creating links? Yes, I used preview and actually edited my post before submitting. Although now since I said that, someone will point out a typo somewhere in my post.

Or maybe all those fucking banks can make Web sites that don't recommend (or require) Internet Explorer.

I would settle for RSA not requiring IE. Yes, RSA, a company founded by the inventors of public-key cryptography, requires that you use IE to sign up for their security portal:

https://knowledge.rsasecurity.com/registration.asp

They use a lot of weird client-side javascript in their webpage that only works with IE.

Doesn't look good for a company in the security business to require their customers to use the world's most insecure browser.

RSA and other similar algorithms can only 'encrypt' things which are quite a lot shorter than the key length (and they use some kind of padding scheme). So you would have to define some kind of encoding scheme which splits the source into blocks to 'encrypt' them (and with some kind of chaining scheme so that the bad guys could not take blocks from different messages and rearrange them). As far as I know, there is no standard for this with widespread support.

Well, not quite. The block size for RSA is equal to the size of the key modulus (basically the key size). If you encrypt plaintexts shorter than the block size, you'll need to pad them, of course (and there are well defined standards for the padding too, see here ). For plaintexts of arbitrary size, you use one of the (well known and standardized) modes of operation - for example ECB (Electronic Code Book), CBC (Cipher Block Chaining) or various feedback modes. The modes of operation are defined in the ANSI X3.106 standard for DES or in ISO92b (for cyphers with arbitrary block sizes). FWIW, it's not recommended to simply split the plaintext in MODULUS_SIZE blocks, but instead pad every block - see OAEP (Optimal Asymmetric Encryption Padding).

How you got modded insightful is beyond me. This shit is real, very real, not just some propaganda from the Chinese. The attack on MD5 has been demonstrated by generating a couple of forged X.509 certificates based on the MD5 hash. It has long been suspected that MD5 harbored significant weaknesses, but it was confirmed in 2005 when Wang and her team demonstrated in a 2005 paper (warning PDF link) that it is possible to generate MD5 collisions with only about 2^39 hash computations (approx. 500 billion), a level of computational work which is doable in a matter of a few days even on the computer which I am using to type this post, and a very long way from the 2^64 computations required by a brute force attack. MD5 is well and truly broken, and not just in the academic sense, and anyone who says that the break doesn't affect the vast majority of its uses is either hopelessly uninformed or willfully ignorant. Checksums and digital signatures based on MD5 are now all suspect, and the only major application of the algorithm that remains unaffected is its use as a message authentication code, and the fact that the algorithm shown significant weakness in so many other areas should make anyone think twice before using it even for that. The biggest names in cryptography have been watching her work and that of her team with the keenest of interest, and there was an announcement (also here) that SHA-1 collisions could be found in 2^63 operations, which, while not feasible on my humble little PC, is within the realm of feasibility of today's fastest supercomputers and distributed computation clusters. Meaning that the NSA could probably generate SHA-1 collisions if they wanted to. Her most recent peer-reviewed paper on the subject gave a work factor of 2^69 for generating collisions, which while quite high, is quite a ways from the 2^80 required by true brute force, and that would make any serious cryptographer worried about using the algorithm.

RSA is making their physical asset. They carry smart cards. RTFA.

http://www.rsasecurity.com/node.asp?id=1173

RSA has had this type of product available for quite sometime now.

It will integrate into Cisco VPN solutions, things that support RADIUS, and I am pretty sure they have some SDK's to integrate it with pretty much anything you are trying to do..

http://en.wikipedia.org/wiki/Securid

http://www.rsasecurity.com/node.asp?id=1156

Cheers!

The banks don't do this because those Secure Cards cost $$$$$$ and that will hurt the banks bottom line.

If you're referring to those based on the product of two large prime numbers I think you'll find that even 193 digit numbers can be factored and that estimates about brute force encryption don't take into account advances in processor technology or parallel processing or human ingenuity.

You can also use distributed computing over the internet to tackle computer problems on the scale of your "supercomputer will take 5-10 years" sort. There are many examples of those if you care to look.

"what will be the advantages of paid use of their quantum computer?"

I'm sure the NSA and other government agencies have a passing interest in code breaking, which among other things means being able to factor huge numbers quickly. A quantum computer would (if it contained sufficient logic cells) be able to try all possible factors of a number at the same time, and would thus be able to factor any number almost instantaneously. It would mean the death of most common types of encryption that depend upon the difficulty of factoring as a means of insuring the privacy of data. After all, the government probably has petabytes of encrypted data from their nationwide wiretapping of telephone and Internet communications they would love to be able to decrypt quickly.

I'm guessing some of the product's will get cut off. Going out on a limb here, but I'm guessing Most of the Keon family will get cut off, at least the toolkits with openssl and boncycastle as options for customers.
The big question is if the CA too will be cut-off... there is lots of viable options here too Ejbca for example <shameless plug>There is commercial support available</shameless plug>.

Has anyone but myself thought of the implications this will have on encryption and security... or a lack there of?

As I'm sure most of you know, SHA-1 has been proven to show signs of collisions on todays computers. http://rsasecurity.com/rsalabs/node.asp?id=2738
Now imagine what would be possible with 500GHz. Amazing!

> Now if RFID tags had RSA or something built in, it would be a different story. But they don't.

Not exactly true. Even the passive tags can have on-board logic, and there are a number of crypto solutions proposed given the processing constraints. Yes, including one by RSA .

The problem with biometrics is that most people can't easily change them if/when their metric is compromised. And yes that WILL happen. Just look at fingerprints for example. I believe the best way to have security is to use something like RSA's SecurID technology. If you lose your keychain, you just get a new one. It uses a rolling code that's only valid for a short time. Nothing to remember, and it's more random then most users's passwords could ever be. http://rsasecurity.com/node.asp?id=1157

The USPTO patent application examiners task could be made more reliable if the examiners could consult one or more public online registries that document cases of prior art and public discoveries. The online registries could provide a means for the public to retroactively point to cases of preexisting prior art for pending patent applications and a means to proactively document publicly known ideas and concepts. Although websites and digitally stored content in general is changeable, individual entries and changes in an online registry could be legally authenticated by means of digital timestamping ( http://www.rsasecurity.com/rsalabs/node.asp?id=234 7 ). An online registry could be hosted by the USPTO as an adjunct to the existing online public patent and patent pending databases. The USPTO could also publicly recognize other individual registries hosted by third parties such as a commercial entity or a non-profit community similar to Wikipedia ( http://www.wikipedia.org/ ). An individual adding an entry to such a publicly online registry does not involve granting that individual any form of monopoly, therefore the action need not have any artificial barrier involving fees or payments. Would the existence of digitally timestamped public content overcome any objections by the USPTO to its citing as prior art? Has the USPTO any plans to add some form of publicly accessible feedback mechanism to the patent application process?

Sigh.

Giving everything an IP address is not an intrinsically bad idea. It _would_ be a bad idea if the hypothetical nuclear reactor was controlled remotely, but do you think anyone would be that stupid? If we were to remove everything that _could_ be misconfigured, broken, or hacked we would quickly run out of possessions (the first thing gone would be your beloved computer.)

To convince you that it is not intrinsically stupid, look at this
thumbnail strategy for protecting the IP connected water mains.

Case 1. Use the IP connection only for checking status. The checking apparatus will have no control over the operation of the water main.
Allow it only to receive connections from inside the Harvard network to protect from external attack. To protect from attack within the Harvard network, log traffic into the main. The worst thing that can happen is a DOS attack, and in that case, make the water main capable of being monitored manually.

Case 2. If you want to use IP connections for monitoring and controlling the water main, restrict access like in Case 1, but add the restrictions that the password not be set by users but be provided by one of those RSA keychain things. This is a hedge against the typical weakest point in many security systems -- crappy passwords. Eliminate all unnecessary services and accounts on the computer responsible for the water main control. And then, most importantly, incorporate a network-independent failsafe control that will override the IP-controlled computer if the watermain tries to do something catastrophically stupid at the command of a hacker or a user mistake.

I'm no expert, but this strategy seems like it minimizes risk enough. If you stick with Case number 1, then things should probably go nicely.

And of course, it can still be hacked (although that is unlikely.)

Troll on, but you miss the mark, my uninformed friend.

This is nothing to do with data aggregation, targeted advertising or behavior tracking. It is not invasive software, surreptitiously installed while a user beleives they are performing another action.

This is more akin to "soft token" technologies:
http://www.rsasecurity.com/rsalabs/node.asp?id=214 1
http://www.actividentity.com/en/products/4_2_6_sof tware_token.php
http://www.securehq.com/group.wml&deptid=80&groupi d=566

The catcher is that this is not tied to X.509 PKI infrastructures, per se. Identity is established by locally configurable means - usually a Kerberos ID - and presented by signed XML markups, rather than the static, signed ASN.1 encodings in certificates. The exchange is still fundamentally an RSA public key validation type problem, but with an extensible policy mechanism in XML. This is an application of the work done by multiple vendors in the WS-Security space. Dynamic policy, negotiated in a federated manner between endpoints, is not possible with x.509, which has permanent policy encoded in the cert.

There is integration with Windows AD Federation, which means there is possibility to interoperate with SAML clients. Trust can also be established by reputation - with attesters signing a keychain for particular identities.

The short story is that this could end phishing attacks.

The long story is that most banks and investment firms won't make this mandatory for transactions, since their Businesses still insist on Win95/IE4 compatibility from their IT and InfoSec personnel.

> To entend the analogy, and answer your question, the situation for the last 30 years has
> essentially been that RSA have patented front doors and indeed, non transparent walls.

Wrong.

1) They patented a certain type of front door, not all of them - you could buy doors from other companies, or make your own. There's a type of door - a `one time door`, which can't be opened by anyone except for you and people you live with, as long as you follow the instructions cafefully.

2) You've been able to use RSA's front door for free for years now:

http://www.rsasecurity.com/press_release.asp?doc_i d=261&id=1034

RSA does offer the RSA SecurID Token for BlackBerry Handhelds - multiple tokens from one device may be possible..

I'd say RTFA, but I don't think it'd help (it's light on theory).

Probably start here, then head here for some background on what is being done here.

"Credit Card" sized cards w/ a display on them for one time passwords have been in use for 10 years.

They are used primarily for authorizing logins to secure systems.

See "securID card" from RSA Security

http://www.rsasecurity.com/node.asp?id=1338&node_i d=

Fashioning it in Windows is quite simple, as Windows domain participants will automatically enroll for the types of certificates that you want, for example, allowing the machines to authenticate into the domain silently. I've written several detailed implementation how-tos on these subjects (kafkaATtelusDOTnet, if you're interested).

As soon as you leave the Windows world, then all these things become a bit trickier. No longer can you simply let the the Windows Certificate Services generate your certificates silently, since you'll need to intercede to generate the type of certificates that want. Controlling how these certificates are constructed becomes somewhat difficult (not impossible, just tricky). How and what you want will totally depend on the applications that you're using. You're probably far better off getting a PKI solution based on OpenSSL in that case, especially if you need to interoperate with non-Windows applications and devices (such as CISCO routers). If you don't have time to write any code, look into RSA Security. They're wayyyy cheaper than Verisign, and you don't have to deal with the hassle of outsourcing.

Another poster recommended using OCSP - thats fine, but I don't believe there is a native OCSP client built in to Windows. You either have to roll your own, or obtain one (RSA, for example, has one. As well as Computer Associates OCSPro). In fact, there is no reason why you can't implement both redundantly. Use both the CRL distributionpoints (CRLdP) extension *and* the AIA extension to get this done.

Another citation, I believe, referred to Peter Guttmans (very old) document on various PKI implementations, X.509 Style Guide. This document is horrendously outdated, as the tools and apps are far more widespread than they were wayyyy back in 2000.

Anyways, for what its worth, if you know what you're doing PKI has distinct advantages to add to your electronic security (although a blind reliance on it won't help you at all).

If you don't know what you're doing, then you'd better go with a vendor that will support you.

/K

Sounds like you're talking about RSA's SecurID products.

These things are expensive to purchase and deploy. Who's gonna foot that bill? Just the users who can't get the hang of responsible computing....or all of us?

Besides, SecureID does have its flaws...no panacea here.

RSA cost study says "It makes no sense for an adversary to spend (say) $10 million breaking a key if recovering the key will only net (say) $10 thousand." Third party payer negates this asumption. Exceptions to the rule are seen in the everyday spending of U.S. taxpayer's millions by low level government employees and politicians alike for their personal gain or amusement, no matter how minor.

Anyway, see ya later, I'm going straight for the RSA-2048. $200,000 can make you forget that you've spent a good deal of your life trying to unmultiply two numbers.

from http://www.rsasecurity.com/rsalabs/node.asp?id=208 8

To put this in perspective, it would require about 1.4 billion 500 MHz machines, each with about 170 Gbytes of memory to do the sieving for a 1024-bit number in the same time as RSA-512. While a hacker might try to steal cycles on the Internet by creating a ?Number Field Sieve Worm? it is hard to see how such an attack could find enough machines with enough memory to make such an attack feasible. Further, such an attack would be detected and shut down rather quickly as with the Robert Morris worm. Of course increasing speed will reduce the required number accordingly. It would take a single Cray with 6 Terabytes of memory approximately 70 million days (192,000 years) to solve the matrix. One could reduce this to a mere 19 years with 10000 Crays each with only 600 Mbytes of memory running perfectly in parallel. It is likely that within 10 years common desktop machines will be as fast or faster than a Cray C90 is now. However, it is unlikely in the extreme that 10000 machines running in parallel will be anywhere close to 10000 times as fast as one machine. It would require 10 million such machines running perfectly in parallel to solve the matrix in about the same time as that for RSA-512.

So basically, according to the article from RSA it's not feasable... but still an interesting IDEA. Maybe a worm that installs something like folding@home that would have immediate benefits. ;)

It's actually less of a chunk.. it's more something like 20k
http://www.rsasecurity.com/rsalabs/node.asp?id=209 3
RSA-1024 with a reward of 100 000$ USD seems to be the best cpu time/reward challenge

The Wikipedia article on RSA-640 has more info. Check this for easy money ;)

Actually, the next one has only 212 digits...

While I think your remark was a joke about them breaking into RSA's computers, this is still worth mentioning. Noone in the entire world knows or has ever known the factors of the remaining numbers. Read this for more info.
Regards,
Steve

Yeah, EMF proof. That is why i called it the Farraday Passport Sleeve. As in Michael Farraday and a Farraday cage. ;-)

Although it isn't exactly a unique idea on my part to put a passport inside such a container when not being displayed to a customs agent.

http://www.rsasecurity.com/rsalabs/node.asp?id=212 0

-matthew

Two Factor Authenticationis not the only part of the problem. It does helps a lot for strong authentication of the client. Some other important parts of the problem are:

1. Mutual Authentication. Short term, need to have the FI display something unique which helps the user tell for sure they are connected to who they think they are connected to. Longer term, need changes to Firefox and IE6 (which for me means 95% of my customers) so that the PKI credentials for the FI are displayed.
2. Need to be able to ask the client if I can query their computers status, and make sure that they have a current patch level and decent AV and Spyware protection. So, need to ask Linux and Windows (or other products installed on Windows and Linux) to provide capabilities, because I do not want to download code. After all, not my business. Could request this function with a special HTTP header.
3. Mid term to long term, I love the idea of a second factor (USB attachment) which supports PKCS#11 / PKCS#15. This, along with #1, prevents MITM attack.
4. Everywhere in the world, except maybe theU.S., we are rapidly rolling out EMV and VIS. So, we are going to have Smartcards in everyone's wallet, that will be a key part of the 2FA problem. Just need a small portable USB device to support a USB interface to the card. So far, I am having trouble with this, need something small enough to hang on your keychain. Wait a year or so, someone will build it.

On the server side, need to make some changes as well.

1. Proper support for tiered authentication. So, you can access less dangerous functionality with less authentication
2. Base the entire thing on a decent RBAC approach, so I can administer and keep track of what is going on. Note, DSD gives me a decent way to model tiered authentication.
3. Need to build a proper authorization framework so that the requirements for both a proper authentication tier and even a signature (OTP, Digitial Signature) on specific transactions can be enforced.

The bottom line:

1. The stronger the authentication of the client, the better. As we move towards 2FA, lets be careful to not make any stupid biometric decisions. Biometrics should only be used to gain access to the hardware second factor, for instance via a thumbprint. Then, it the second factor gets stolen, we just revoke the token; we do not need to cut off your thumb!
2. Mutual authentication. Not only does the client need to prove who they are, the FI needs to prove who it is. Some cool stop-gate things with GIFs and stuff are possible, but in the middle and longer term, changes to the browsers (the two that dominate my customer base are Firefox and IE)
3. Assurance the PC is protected. If you will excuse me the vanity, I will riff on "Clarke&'s Third Law", name it "Cameron's Law&", and state that "Any sufficiently infested PC cannot be protected from allowing the customer to be scammed". Frankly, I was really hoping that the Fed would step up to that in its

Two Factor Authenticationis not the only part of the problem. It does helps a lot for strong authentication of the client. Some other important parts of the problem are:

1. Mutual Authentication. Short term, need to have the FI display something unique which helps the user tell for sure they are connected to who they think they are connected to. Longer term, need changes to Firefox and IE6 (which for me means 95% of my customers) so that the PKI credentials for the FI are displayed.
2. Need to be able to ask the client if I can query their computers status, and make sure that they have a current patch level and decent AV and Spyware protection. So, need to ask Linux and Windows (or other products installed on Windows and Linux) to provide capabilities, because I do not want to download code. After all, not my business. Could request this function with a special HTTP header.
3. Mid term to long term, I love the idea of a second factor (USB attachment) which supports PKCS#11 / PKCS#15. This, along with #1, prevents MITM attack.
4. Everywhere in the world, except maybe theU.S., we are rapidly rolling out EMV and VIS. So, we are going to have Smartcards in everyone's wallet, that will be a key part of the 2FA problem. Just need a small portable USB device to support a USB interface to the card. So far, I am having trouble with this, need something small enough to hang on your keychain. Wait a year or so, someone will build it.

On the server side, need to make some changes as well.

1. Proper support for tiered authentication. So, you can access less dangerous functionality with less authentication
2. Base the entire thing on a decent RBAC approach, so I can administer and keep track of what is going on. Note, DSD gives me a decent way to model tiered authentication.
3. Need to build a proper authorization framework so that the requirements for both a proper authentication tier and even a signature (OTP, Digitial Signature) on specific transactions can be enforced.

The bottom line:

1. The stronger the authentication of the client, the better. As we move towards 2FA, lets be careful to not make any stupid biometric decisions. Biometrics should only be used to gain access to the hardware second factor, for instance via a thumbprint. Then, it the second factor gets stolen, we just revoke the token; we do not need to cut off your thumb!
2. Mutual authentication. Not only does the client need to prove who they are, the FI needs to prove who it is. Some cool stop-gate things with GIFs and stuff are possible, but in the middle and longer term, changes to the browsers (the two that dominate my customer base are Firefox and IE)
3. Assurance the PC is protected. If you will excuse me the vanity, I will riff on "Clarke&'s Third Law", name it "Cameron's Law&", and state that "Any sufficiently infested PC cannot be protected from allowing the customer to be scammed". Frankly, I was really hoping that the Fed would step up to that in its

The most popular second-factor token is the SecurID by RSA. It is a device which generates pseudo-random numbers every 60 seconds. This would be the easy solution for any bank interested in a cross-platform solution with no driver support to worry about.

That said, I hate the SecurID. I'm a much bigger fan of PKI-based solutions, because of all the other things you can get along with it (secure email, secure transactions, strong authentication, persistent digital signature and encryption) for almost no additional cost. However, I'd understand if organizations went the SecurID route to save money not having to support something that didn't work well in multiple platforms.

The most popular second-factor token is the SecurID by RSA. It is a device which generates pseudo-random numbers every 60 seconds. This would be the easy solution for any bank interested in a cross-platform solution with no driver support to worry about.

That said, I hate the SecurID. I'm a much bigger fan of PKI-based solutions, because of all the other things you can get along with it (secure email, secure transactions, strong authentication, persistent digital signature and encryption) for almost no additional cost. However, I'd understand if organizations went the SecurID route to save money not having to support something that didn't work well in multiple platforms.

You mean something like this?

http://rsasecurity.com/node.asp?id=1309&node_id=

http://rsasecurity.com/node.asp?id=1159 (warning: flash)

http://rsasecurity.com/node.asp?id=1309&node_id=

http://rsasecurity.com/node.asp?id=1159 (warning: flash)

• First you need to find the tag. Few people have scanners at home, and more and more tags are non-obvious (to avoid shoplifting by removing the tag in the store.) This is the current big problem.
• What happens if the tag is part of the product? Interesting you mention boots -- one of the first products to ship with embedded tags is likely to be sneakers. The tags will be in the soles of the shoes, no way to get 'em out without ruining the sneaker. Tags can be part of molded plastic (like the car keys that ship with them right now) so they'll also be in the handle of your toothbrush, not stuck on top of it and easy to remove. This is the coming big problem.
• Tag removal may eventually become illegal. A Proposed European Union IP Enforcement Directive failed, but had a small clause that citizens were not legally allowed to remove tags because -- I love this part -- it would violate the intellectual property rights of the manufacturers. See http://www.ipjustice.org/CODE/codewhitepaper.shtml #Ib3

This is going to be a big fight - no idea where it will end. Thus far, no one has a good solution for consumer privacy. A few things have been tried.

• The Metro group in Germany pledged to disable all tags at the point of sale. Turns out they didn't. But who knew, right? You take your purchase to a counter, the clerk waves something at it and tells you the tag is off, and you go on your way. Only, their system was broken. This points out that to have an effective assurance of privacy, consumers need a way to be able to check for themselves.
• Blocker tags (http://www.rsasecurity.com/rsalabs/node.asp?id=20 60) not only don't work in practice yet, they won't work for many sorts of tags. Blocker tags are only effective against specific types of tag communication protocols. That may be good enough, but I'm not yet convinced. I'm taking a wait-and-see approach here. I think the right people are working on it, though, and I expect they'll eventually come up with something that at least helps.
• Ari Juels came up with the most serious proposal I've seen, "A bit of privacy," http://www.rfidjournal.com/article/articleview/153 6/1/133/ IMHO, the solution won't work. It depends on everyone behaving and following the spec, but doesn't enforce good behavior. However, if he's able to lobby for changes to the EPC spec, perhaps a solution like this will eventually come to market. I figure that's five to ten years at best.

Two examples from my own experience. We attempted integration with RSA and OpenSSH had significant problems that we had to resolve and in the end we could not resolve the final problem which was a session would hang after exiting the shell if the session was authenticated using the RSA PAM module.

One example from my own experience: I ran ssh-keygen from OpenSSH, copied the RSA public keys around, and it just worked. I do believe you've had different luck, but I suspect my case is more typical.

I don't think the GP was talking about RSA public/private keys, but instead about RSA SecurID. Having said that, I haven't implemented this for ssh authentication, so I don't know how it goes. If the GP was indeed talking about public/private key authentication, then yeah, they deserve to pay for everything.

RSA is having a competition for people who beleive what you say here.

Break that!

..... Single Sign-On Manager by RSA. The IT manager then has the choice of using an RSA SecurID Authenticator, RSA Smart Card, RSA USB Authenticator, a biometric or (god forbid) a password.

Why do you think 1024 bit asymmetric is roughly equivalent to 128 bit symmetric when numerous sources say it is closer to 80 bit symmetric?

Here's a quote from RSA Security:

"The design confirms that the traditional assumption that a 1024-bit RSA key provides comparable strength to an 80-bit symmetric key has been a reasonable one." -- http://www.rsasecurity.com/rsalabs/node.asp?id=200 4

And I don't believe any literature says 1024-bit DH key provides 128-bit symmetric key strength either. Where did you get your info?

• http://cervisia.org/biometrics_encryption.php
• http://www.rsasecurity.com/rsalabs/staff/bios/ajue ls/publications/fuzzy-vault/fuzzy_vault.pdf
• http://www.bioscrypt.com/

I probably would have used SHA-1 too.

So, its just a card with a password, and a chunk of crypto that said the password was right or wrong

No. It's a card with a *private key* that can encrypt data given to it using that private key. The bank/eBay/other would have your public key. They would create some random token to be encrypted and give it to you. Your card encrypts and signs it using your private key. If they can then decrypt it and verify it with your public key then they know it's you.

http://www.rsasecurity.com/rsalabs/node.asp?id=216 5

And no-one's ever proven that you have to factor large numbers to solve the RSA problem.

??? The "RSA Factoring Challenge" is a challenge set by the RSA company to... factor large numbers.

This is a different proposition to breaking RSA encryption.

And yes, you do look like an ass now.

I have found the solution, but we need to come to an arrangement about my other $19,000, don't you think?

These things are cool. The have random numbers on them that change once a minute. These are sync'd with software that runs on the banks servers. I've worked with them before for access to VPNs and such. Great tools.

I noticed some routing issues earlier today. Specifically, at least one alter.net (MCI)router is unresponsive and RSA's website is un-reachable/-traceable/-pingable. However, the unresponsive router is not listed on dslreport's Router Watch page. I was curious if anyone knew if this Pakistan issue was causing problems for some US sites.