Slashdot Mirror

Congratulations! You just re-invented two factor authentication! Of course, what you're proposing is nothing as elegant or simple as market leader RSA's SecurID solution

And a good number of banks offer the use of two-factor authentication to protect your money, including the mid-sized midwestern financial institution where I currently work.

I did not take into Moore's Law, but making that assumption and assuming further advances in factoring techniques, we get the following figures:

http://www.rsasecurity.com/rsalabs/node.asp?id=200 4

Assuming that Moore's Law continues to hold for eight more generations, and starting with estimates based on the Blaze et al. report above, it would take a $10 million machine 10 days with year 2015 technology to search for an 80-bit key -- which even in 2015 should still be a lot of money for most keys. However, many keys will have greater value, and key size recommendations have a history of taking longer to be fully embraced than one might prefer (consider the lengthy process of upgrading DES). Accordingly, an earlier transition would seem prudent, consistent with the higher security level of 90 bits encouraged by the Blaze et al. report [BDR+96] for protecting data through that time period.

The next level in NIST's schedule is the 112-bit security level, matching triple-DES encryption. To put the 112-bit security level in concrete terms, some simple calculations may be done. Starting with the estimates for 80-bit key search today, a 112-bit key search today on a $10 million machine would take about 30 billion years. A machine with the same cost in the year 2030 -- 18 generations from now -- would take over 100,000 years to do a 112-bit key search. (There is clearly dispute over whether Moore's Law will hold that long, so this is only a starting point for analysis.)

Taking the previously established correspondence between 2048-bit RSA keys and the 112-bit security level as a starting point, one may assume that a "future TWIRL" in 2030 would likewise take 100,000 years to factor a 2048-bit RSA key. It could take more time, due to the larger circuit size. More likely, it would take less, as there may be further improvements in integer factorization. Conservatively applying Lenstra and Verheul's "law", i.e., incorporating 18 "generations" of such improvements, a $10 million "future TWIRL" in the year 2030 would take about five months to factor a 2048-bit RSA key. This brings us essentially back to TWIRL's initial claims for 1024-bit RSA keys today.

So, worrying about encryption key sizes because of a couple supercomputers the NSA might have is silly.

As alternative approach you can use SecurID( http://www.rsasecurity.com/node.asp?id=1156) It generates unique password for you that is valid ONLY 20 seconds !. So even if someone sees that pass he can use it for less than 20 seconds

With regards to #3, that sounds like something like RSA's SecurID key fob.

AKA SecureID. Nearest open source equivalent is S/Key.

It's not exactly like there are 2^8192 8192 bits RSA keys, because, well, they have a little structure. Not only product of two primes but in order to achieve the rigt level of security product of two 4096 bit primes. So we are really well under 2^8192 here. I don't have numbers at hand for 8192 but to achieve 128 bits of security you must use 1620 bit long RSA keys (from http://www.rsasecurity.com/rsalabs/node.asp?id=208 8).

Extrapolating from here you 8192bit RSA key is likely at most "only" as expensive to crack as a 1024 symetric key.

But using that kind of key is really having CPU to spare, it is beyond pananoia and well into moronism.

There is nothing really exciting about this other than the overkill usage of quantum cryptography (also called quantum key exchange).

Basically, they are trying to generate enough keys so any succesful breaking of the cipher used gets only one frame of video. The only "exciting" part is they are using quantum cryptography to do this. However, this is like using a sledgehammer to push in a thumb tack - It uses a lot more hardware, and isn't the easiest or best method.

Another way to do this would be to conduct a large number of Diffie-Hellman key exchanges or STS exchanges, (one for each frame), and use the new key for each frame.
Or, even easier, both sides could use identical Linear Feedback Shift Registers to generate the same keys that they need. They cost way less than $20k and since a compromise of the system at either end would destroy the privacy afforded by the quantum encryption, just as secure.
Or, they could exchange one-time pads on a DVD and use the bits on there as the key. If my math is right, then a 4GB CD could hold enough keys for over 1100 hours of video, assuming a 256 bit key and 30 frames/sec. Exchanging 2 or 3 DVDs a year (if that) doesn't seem unreasonable.

None of these methods require a dedicated fiber line connecting the two groups. It can be performed over regular Ethernet if the groups want to. Translation: I can use it to talk to someone more than 120km away.

This isn't to say that some groups wouldn't want quantum security for something - if I was a Swiss bank that made daily transfers of a billion dollars to a German or Italian or French bank, then sure, I should spend the extra couple hundred k for an obscenely secure system.

This also begs the question of why encrypt each frame differently? Since it is VIDEO, then something in the picture is probably important - like a PowerPoint slide or graph or something. Since a presenter usually spends a minute or two on each slide, this means that an attacker would only need to decrypt one out of every 1800 slides (assuming 30 frames/second) to get the information they wanted. I think that it is a good idea to change keys as often as possible, but you have to ask what is the benefit for the added cost/overhead. In this case, I don't think it is very much.

So nice use of the "quantum cryptography" buzzword, but bad application of crypto technology in general.

What about using RSA Securid?

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

Then the first half of your password can be whatever, but the second half always changes. Plus I think I even saw tokens that were also calculators. They also have USB Authenticators as well. Granted, this would not work for some companies, but for many it would be fine.It could even work if you have to have a vendor go into your system to look at something. You could keept that signon's fob and when they need access you call and have them log in while your on the phone.

Password security is never easy to enforce. It's even worse in some industries. The VENDORS IDIOTIC programmers make thier programs have a default password or thier stuff does not work! In some places of business, the IT department does not have the choice in the system that is purchased. We may have a hand in it, but if the majority of the comittee is not IT and they all like it, your stuck.

On February 24, 2005 I tried to pose some questions to USPTO On-Line chat for Independent Inventors today, however the digichat java applet does not appear work with any combination of Linux Galeon/Mozilla/Firefox jdk1.5.0/j2re1.4.2_07 or MacOSX Firefox/Safari. Here is what I tried to ask:

I understand that the discovery of prior art and the evaluation of the obviousness of an invention are difficult tasks for the United States Patent and Trademark Office (USPTO) patent application examiners to perform. The percentage of patents being overturned under the scrutiny of the courts leads me to believe that the process is not quite as accurate as could be desired. In a few recent cases the existence of publicly accessible digital content has played a part in disclosing prior art. The public, technical and scientific communities use of Internet has to a large extent replaced printed media such as journals for the public disclosure of new ideas. To what extent does the current USPTO patent application examination process take into account public accessible website content? Do the patent examiners currently use Internet search engines such as Google ( http://www.google.com ) to locate instances of prior art? Is the changeable and unverifiable nature of some digital content a barrier to its being cited as prior art in the patent application examination process?

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?

It has been nine years since the USPTO updated the Guidelines for Computer-Related Inventions ( http://www.uspto.gov/web/offices/com/hearings/soft ware/analysis/computer.html ). Since that time has the USPTO undertaken, commissioned or evaluated any studies on the effects that granting software related patents has had on the progress of science, useful arts and the software industry in general? If no such study has been performed or evaluated, why not? Can the USPTO point to any instances where the granting of software related patents has been an actual benefit to the progress of science, useful arts and the software industry in general? In a similar vein, can the USPTO point to any instances where the granting of business method related patents has been an actual benefit to the progress of science, useful arts and industry in general?

Really, I can't fathom how people would choose primes over protiens when protiens may help the fight against cancer amongst others. Please follow the link at least and take a look.

Contrariwise, I can't fathom how people would choose proteins over primes when primes may help the fight against identity theft amongst others. Please follow the link at least and take a look:

RSA Factoring Challenge FAQ

You only think this because, (a) you really do not understand authentication, and (b) you hane not looked outside the very propreitary PKI world

Yes. Thank you for talking down to me, and then proceeding to talk about something else entirely. I was talking about hardware tokens like this one or the CryptoCard RB-1 seen here.

I'm quite aware of how certificates work. I'm also quite aware that a private key, whether it's an X509 cert or an SSH key, is quite vulnerable if it's sitting on a user's PC. This is why the hardware tokens are attractive, because it is effectively impossible (i.e., computationally infeasable) for a remote attacker to copy. That's why I was pointing out that hardware tokens seem to be private key based, and asking if anybody knew of a way to perform a public-key based authentication using a typeable number of characters. The private-key nature of the hardware tokens make them unattractive for use in authenticating to multiple domains.

Yes, I'm aware of USB dongles and smart cards that perform public-key based authentication. But they also require drivers/software on the client which hardware tokens do not. They are also vulnerable to misuse as long as the card/dongle is connected to the users PC, even if the private key itself can't be copied.

No, they are not. In fact, I highly doubt that they will require you to do anything new at all. What they are enabling is the option to use two-factor authentication, if your organizational needs mandate it. Regular home users will likely be able to log in insecurely like they always have.

Additional hardware for token-based authentication requires the purchase of, well, the token! And usually that means your administrator will need to purchase a server that is synchronized with your token (to be able to check that the number is "correct").

Smartcards (which are another means of fulfilling the "something you have" option) are also pretty easy to purchase and use these days - there are plenty of USB smartcard devices that are small enough to fit on a keychain. RSA Security sells all this stuff. Among others, of course.

/Kafka

Companies that make these little devices: Safeword and SecurID. Any of these can be spoken to someone over a phone so that the improper person gets the access. A third biometric needs to be added to ensure that the proper person gets the access. Or at least someone who went through the trouble to sever their limb/eye/finger.

With an RSA Key Fob.

In case its still not clear to you, a common form of two-factor authentication is through the use of a small hand-carried device that uses a time-sensitive algorithm to generate a series of numbers. Time senesitive means that this number series changes over time.

In the industry, this is commonly called a "token" and there are multiple vendors that sell them :

RSA Security
ActivCard
Vasco
[etc.]

Typically the "two-factorness" of the authentication is a description of the relative strength of the authentication process. The process itself is one which authenticates users based on several criteria :

• Something you know [passwords]
• Something you have [tokens]
• Something you are [biometrics]

Is this a good thing? Most people say, guardedly, "yes". But only because its better than just merely using passwords.

/Kafka

Same researchers announced some vulnerabilities in MD5 and SHA-1:

See:
http://www.arnnet.com.au/index.php/id;1503863220;f p;512;fpid;710205681
Researchers have discovered a flaw in the MD5 algorithm that is used to provide a unique signature for data.

Xiaoyun Wang, a Chinese expert, and three colleagues have discovered the flaw in the hash function algorithm, which is used in applications, such as EMC's Centera content-addressable file store. The flaw was revealed at the Crypto 2004 conference.

Also:
http://www.rsasecurity.com/rsalabs/node.asp?id=273 8

* The hash function collisions recently discovered have minimal practical impact at this time due to the limitations discussed further. It is not clear that these research results can be turned into practical exploits on most typical uses of these hash functions, so there is no immediate need to replace hash algorithms.
* As a precaution, applications using a legacy hash function described as vulnerable should upgrade to the NIST-approved SHA1 or SHA2 family of algorithms (RSA Laboratories suggested a migration to SHA1 in 1996).
* Applications using SHA1 do not appear to be at risk, but conservatively, developers may also consider planning an upgrade to the SHA2 family in the next few years.

Passphrases are just long passwords with (usually) low entropy. They still have the same problems... You have to have a separate passphrase for each account, and you have to trust the computer you're using not to log your keystrokes. I would much rather carry around a device that can authenticate me and never have to remember a password again.

Why don't we all just switch to USB tokens for authentication? You have one device that can authenticate you by generating an RSA signature without divulging any information that would allow someone else to pretend to be you. It amazes me that more people don't use these things. I've never used one, but have considered ordering one. Does anyone out there have experience with USB tokens? Is there a good model/brand to buy? Is it easy to get them to work with Linux and ssh? Do any brick-and-mortar stores sell them?

I think maye you're thinking about something like this?

The way you're describing how you want it to work would be utilizing X.509 certs. It'll authenticate users to Windows Active Directory, LDAP... anything that can use X.509 for authentication. I'm sure (for a hefty fee) RSA can adapt it to other authentication platforms. The only caveat is it seems a little physically fragile.

Are you sure you werent just having a non-IT person describe a RSA secureid keyfob token to you?
I could see where someone who wasn't in the know could explain a secureid like that.

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

things like SecurID were invented.. 2-factor authentification eliminates most of these special requirements.

You don't try every key at once - you use an algorithm to derive the private key from the public key.

The algorithms to do this for current processors are very expensive (i.e. take a very long time). See http://www.rsasecurity.com/rsalabs/node.asp?id=219 0 for some examples.

An algorithm (as linked to in another post) that could be run on a quantum computer can do this in about the same amount of time as it took to generate the key in the first place (i.e. very, very quickly).

Bottom line: When someone says "only the person with the private key can decrypt it" you can automatically add "or someone with lots of computing power". A quantum computer just makes a much more efficient solution possible.

So, cracks in one layer might reveal enough information to break the next layer. Or, a break in an inner layer may compromise the security of the outer layer. For a physical analogue, see the book "Surely You're Joking, Mr. Feynmann," and specifically the part where he fiddles with people's already open safes to learn their combinations.

Here's a possible example. RSA has an encryption method called OAEP. This page notes "to construct a valid OAEP encoded message, an adversary must know the original plaintext." Let's say that Eve manages to find the plaintext of one message (perhaps through dumpster diving, or whatever.) She might now be able to create OAEP encodings that can spoof the inner layer. By introducing them at the right point in Bob's stream, he may believe that they're valid. Or, Eve might be able to use her computed OAEP encoded message as a plaintext crib to help her break the outer layer's key.

Sure, there's a lot of "what if" there (of the sort cryptographers love to endlessly debate) but the point is that "stacking" algorithms is not an automatic guarantee of "more" security.

You do realise we're talking about a device that generates a number in sync with the server, and not a simple ascii file, right?

This, not this. (or this)

To answer the 5 tokens keychain question: there is a software token device also available: http://www.rsasecurity.com/node.asp?id=1313/

What will they think of next?

What will they think of next?

Putting it in the microwave will kill it, permanently...but there's a chance it'll catch fire.

don't relly on passwords use things like RSA secureid cards.

The basicly generate a new psudo random number every 20 seconds, you login with your id, your 'password' and the random number.

That way users can pick weak passwords, backed up with one that changes every 20 seconds.

You're absolutely correct. S/MIME is easier, works great, and is supported by most mail clients. This should be what the privacy community should be pushing for, not the PGP bloat package. Yet...

The advantages of PGP and its clones are in its local disk encryption, not necessarily email. PGPdisk can encrypt a whole partition. Encrypting local files with your own key. etc.

The problem is incentive. Why should Joe User make a cert? How can he be conviced its in his advantage to do so?

PGP hasn't taken off and neither has S/MIME. That's just wrong.

He can create a file that MD5sum's to the same result as a legitimate file, but does not have full control over the content or size of the result (making this a mostly useless avenue of exploitation except for people who want to spread trash on P2P networks -- I.E. it shouldn't particularly bother anyone except people who already don't care about security).

Suppose you're storing passwords as encrypted hashes, so that intercepting the hashes doesn't tell you what the password is. But if you can generate a password to match that MD5...

You know that GPG keys are identified and signed by their MD5 hashes? Suppose that I can generate a GPG key that would be identified as yours, and distributed it.

Or he can create two files that MD5sum to the same result. But he has to have control over both files, which offers effectively no advantage to someone who is trying to spread malware or tamper with existing archives that have been MD5summed.

There's a coin-flipping protocol that goes as follows. Suppose that Alice and Bob want to flip a coin (over the Internet), but they don't trust each other.

1. Alice generates a file with random data.
2. Alice sends Bob the MD5 hash of the file.
3. Bob picks a bit in the file, and whether he thinks it's a 0 or a 1.
4. Bob wins if and only if he picked right.
5. To verify, Alice sends Bob the file she generated at the beginning.

Now, suppose that Alice generated multiple files in step 1. When Bob makes his guess, she tries to pick a file that will make her win. If she generated only two files, completely randomly, this would let Alice win 75% of the time.

These are just the first ideas I thought of. If I were looking for other problems, I'd think about undeniable signatures, keysigning (which as GPG and X.509 SSL are heavily based on) and other specialized signature systems. In particular, I expect that the first type of crack could cause issues with SSH keys, both user keys (used for authentication) and host keys (to prevent man-in-the-middle attacks).

Digital signatures are used for much more than just testing for file tampering.

Gaim-Encryption uses RSA keys. You can use keys from 512 bits all the way up to 4096 bits. Since its public key encryption it will be VERY secure.

Trillian uses the Diffie-Hellman / Blowfish (128 bit key) protocol. From what I know Diffie-Hellman is vulnerable to man-in-the-middle attacks ("The Diffie-Hellman key exchange is vulnerable to a man-in-the-middle attack." -- http://www.rsasecurity.com/rsalabs/node.asp?id=224 8 ).

From what I can tell, Gaim-Encryption is far superior.

You mentioned that these strings are "short". "Short" means the string space can be brute forced much easier than the hash. Lets say that an attacker concludes these short strings you're encoding map to Visa account numbers (a typical application.) A Visa number, for example, has only 14 unique bytes to brute force, and even then the search space drops to 11 digits when you factor in 4 digit bank numbers (there are even 6 digit bank numbers, but I'll stick to 4 for the example. And since many bank cards are regionally based, if a ZIP code field is present there's a reasonable chance that one of that ZIP code's regional banks may have issued the card.) So 10 possible values for 11 digits yields 10^11 possible values. 10^11 is not a particularly large number of MD5 hashes to generate to determine if a value was encoded -- a high-end dual Xeon desktop could probably search an entire bank's account number space in about six minutes or so. Picking the top 5 national Visa bank numbers plus the top 5 local-to-the-ZIP-code bank numbers means a reasonable chance at a break in about an hour.

I really don't know anything about OAEP (other than that this RSA page says, "This means that to construct a valid OAEP encoded message, an adversary must know the original plaintext." That doesn't bode well for you. If the attacker just figured it out the plaintext by a brute force search of the account number space, then he's got a new wedge into your systems.

That's why mixing crypto systems without a full understanding can seriously weaken security, rather than enhance it.

1. RSA Blocker Tag

2. Tinfoil cover

3. Faraday cage purse.

There is no money in discovering RFID blocking devices. There is a possible market in creating a cheap RFID detector.

Funny that you should suggest that! Check out the picture of the fob at the RSA site

In addition, RSA SecurID hardware authenticators are manufactured and sealed with an integral lifetime battery. No user maintenance or battery replacement is required. As a result, this authentication solution is as easy to deploy and administer as it is to use.

Source: RSA Security - Hardware Authenticators.

Check out RSA's Web Site.

They have a lot more than you assume...

If that is difficult to track the RFID tags "geographically", it is however possible to track them "in the time". I mean you can put a reader in a given place and then determine when your targeted tag is present. That's a kind of "traceability". There are several works on this topic i.e. traceability of the tags, for example for the banknotes, for the lirairies, etc.

There is an interesting webpage about RFID here:
http://www.rsasecurity.com/rsalabs/node.asp?id=211 5

And also here:
http://lasecwww.epfl.ch/~gavoine/rfid/

The probability of being able to create a doppelganger which can cause a collision in BOTH hash functions simultaneously is multiplicatively harder. Right?

And that's exactly what MD2 does! And I quote from an RSA FAQ

MD2 was developed by Rivest in 1989. The message is first padded so its length in bytes is divisible by 16. A 16-byte checksum is then appended to the message, and the hash value is computed on the resulting message. Rogier and Chauvaud have found that collisions for MD2 can be constructed if the calculation of the checksum is omitted [RC95]. This is the only cryptanalytic result known for MD2.

Another interesting thing is that all the secure hashing functions in use today basically all use the same algorithym, by Prof. Ronald Rivest of MIT!

Ummm... RSA has been cracked too:
http://www.rsasecurity.com/rsalabs/node.asp?id=209 6

As with nanotechnology, I'll believe in quantum computing when they produce some real results, like say factoring RSA 2048. Hell, let's see them factor the number 339. If practical quantum computing is decades away, can't they at least show us something impractical, just to prove that quantum computing isn't just hand-waving bullshit?

Its already here.
WPA uses AES (implimented using the Rinjdeal or however its spelt,algorithm). FYI there was nothing seriously wrong with the encryption in WEP. RC4 is a strong algorithm.
However the poor key exchange and flawed generation of Initilisation vectors within WEP are the cause of the flaws. The algorithm itself is solid.
For all intents and purposes WEP would be just as insecure if it used AES insted of RC4.

I for one wouldn't want to have it out there on a public IP (IPv4 or IPv6). That is something you place behind a NAT router and then have your public box act as a relay to and from your protected devices such as the environmental controls, fridge, etc. Of course you would need good security on your public box, preferably with a rolling password token on your PDA, somewhat like the RSA SecurID system but as software on a PDA/phone.

In short, unencrypted steganography isn't particularly useful, but encrypted, you can really hide things.

Would mass use of Ron Rivest's cleartext 'chaffing' technique offer suitable 'deniable encryption' to the masses?

Chaffing and Winnowing: Confidentiality without Encryption


This is the Ron Rivest of RSA fame...

RSA encrypted AES key

You answered your own question. RSA here means the RSA Public Key Cryptography Standard The AES key (which is a symmetrical cipher key) was encrypted using RSA PKCS.

Doesn't anyone here use RSA SecurID or the like? With that you can get a password that changes every minute or so.

It works so that the user carries with him a small device (the shape of a credit card) that shows a changing 6 digit "random" number. Your password is that number appended to your secret pin-code.

The card and the server are synchronized so that the server knows which number the card is displaying.

Interesting. Looks like RSA sells a usb token that can do signatures with keys up to 1024 bits. According to froogle, they sell for about thirty bucks. Does anyone out there have experience using one of these? Is it easy to set up linux to use one for login (remotely or locally)? Can you set your own private key, or do you have to use the one preset at the factory?

-jim

How about a password that you don't know and changes every 60 seconds?

SecurID for phones exists. You just have to have the right one.

The encryption alogorithm for Trillian is quite strong (128 bit blowfish), but the method of exchanging keys is open to attack. Tril uses Diffie-Helman key exchanges for the clients to get private keys, but this is entirely open to a man-in-the-middle attack. A server (or carnavore type machine) could sit between the two clients during the key exchange, and manipulate the exchange so that the whole conversation is readable to the client.

More info here

I always thought about creating an IM service that uses certs in order to encrypt / decrypt messages. Like, when the person logs in and authenticates with the server, the client registers a new public key with the server.

Of course, something like this will take a bit of thought, and is in the future. Thoughts?

Do you know how long it takes to break encryption (even just 64-bit)? By the time you crack it (if ever), any data you've been snooping will be long out of date. And one can hope the encryption keys will be changed on a regular basis.

Sure, you might be able to do it...but would it be worth your time?