Open-access journals seem to be redundant in CS. Since both IEEE and ACM allow you to put PDFs of your articles on your own personal page or preprint sites, and in my experience 100% of articles that I wanted to read which were written in the last ten years are on such sites, everything in CS is already de facto open-access. Google Scholar manages to find PDFs of articles put on the web in various places almost every time. In the most extreme case, you can always email one of the authors and have them send you a copy.
Two big exceptions to your rule, which apply to a lot of Groupons:
(1) You are getting a deal at the expense of some less informed person getting screwed.
(2) The company is stupid and actually isn't making a profit, in the hopes that you will come back for return business. You don't. You win.
unless they are using the fingerprint itself as the encryption key (highly inadvisable as you would have to get the same image every time)
There are some relatively new cryptographic constructs called fuzzy extractors which allow you to use imprecise data like biometrics to generate deterministic keys. As long as the image is within some threshold of original image, the same key will be extracted. The original image is stored as a secure sketch which essentially means it can be used as a "hint" to extract keys but alone it reveals nothing about the target biometric. The idea is that the difference between two images of the same finger will be significantly smaller than the difference between images of two different fingers, and the entropy you get from this is enough that you can do some cryptographic error correction magic to extract good, deterministic keys.
You are missing the point of the checksum. In a situation where random error or corruption might happen, then sure CRC is fine because it will most likely catch the change. In an adversarial setting, if someone changes any of your file maliciously they can EASILY craft it so it matches the old checksum. That is the point of cryptographic hashes, it is very difficult to find two things that hash to the same value. If you realize that, then you have to use at least SHA-1 because it is relatively easy right now to craft collisions with MD5.
This is what Apple is doing now but people flip out about it. Apps in the app store can only interact with files through the OS file chooser, so they are effectively sandboxed and can only see files explicitly allowed by the user.
Most exciting thing I've seen all day! Right now I use a subversion repository to collaborate with my coauthors, but my advisor isn't very technical and can't seem to figure it out half the time. This is going to be much easier.
Um... what? Determining whether P is or is not equal to NP is probably the largest open problem in complexity theory. I thought everybody knew that. I feel like I'm taking crazy pills here.
Well its a theoretical attack against TLS because you can restart the connection and currently browsers will use the same parameters if you have a certain cookie set, giving you a chance to try again. It takes millions of tries though and each TLS handshake is rather slow so it isn't currently possible to use this attack on TLS even under the best conditions.
For lazy people a quick overview of this attack is that it uses very small differences between the amount of time it takes to decrypt a correctly padded TLS record and the time it takes to reject an incorrectly padded record (think of the padding as kind of a checksum). An attacker can modify encrypted records, send them to the server and discover whether the decryption is correctly padded or not based on the amount of time it takes to respond. With this knowledge, an attacker can interactively decrypt a record bit by bit, testing the padding over and over.
It only works in datagram TLS (DTLS) because regular TLS terminates a session after one incorrectly padded message. It also only works over LAN where you can get really precise timing.
Where did he say that? I find it hard to believe that he would because it is a well known fact that breaking RSA does not imply factoring. Think of it like this: if you can factor, then you can certainly calculate the decryption exponent (private key) from the encryption exponent and the factors of the modulus (using the totient of the modulus). This is exactly what you do when you are generating the private key in the first place. However, knowing only the modulus, the encryption exponent and a ciphertext, if I could find the eth root of something in a finite field, then I would be able to decrypt that ciphertext and get the message. I can do that without knowing the factorization of the modulus.
Currently nobody knows a way to find eth roots, so the surest way of breaking RSA is factoring, but there is no guarantee that such a method will not be found. If you don't believe me or the Wikipedia page you could always read the cited article by Dan Boneh, one of the top modern cryptographers in the world.
just look at the graph of rate of prime numbers vs number of digits or however you wanna phrase it, obviously it must intersect zero at some huge number (what would hitting negative even mean?)
According to the prime number theorem the probability of getting a prime number by randomly picking an n bit number is about 1/n. If you look at the graph it does not decrease linearly so it would never reach zero.
As other people have said, generating primes is actually quite easy. It is a direct consequence of two facts: checking if a number is prime can be done in polynomial time (see AKS primality test), and the distribution of primes is dense (that is, if you pick a random number, in a large enough range it has a non-negligible probability of being prime; see prime number theorem). That means you can quickly generate primes by picking a random number in your designated range and checking if it is prime, repeating until you get one.
Not saying that it would be useful for cryptography, but I think you are being a little generous when you say it can be checked in "seconds". Lets assume that the way they are testing Mersenne numbers is by starting at n=1 and checking whether 2^n-1 is a prime. If it could be done in, say, 10 seconds, then this distributed computing setup would have gotten to the current number, n=57,885,161, in 57,885,161 * 10 seconds / 360,000 = ~25 minutes. Since it has taken 17 years, I would assume it is harder to check than you think. That is not even taking into consideration that 2^n - 1 can only be prime when n is prime, which already pre-filters quite a few candidates.
Actually, it's "worse" than that: the "proof" that most modern PKCS crypto works is: "It's hard to find the (prime) factors of the product of two primes".
Small correction, there is actually no proof that RSA reduces to factoring. It is true that if you can factor you can break RSA, but you may also be able to break RSA without factoring. http://en.wikipedia.org/wiki/RSA_problem
OFB and CTR are weaker than CBC and similar modes in that you don't need to have correctly deciphered the previous block to decipher the next one, you only need to know the key, initialization vector and the position in the stream
If you have the key then you can decrypt the first block and all the other blocks in a CBC encrypted stream so it doesn't really matter. If you have the key you win no matter what. With CBC, losing a packet of ciphertext would mess up only adjacent blocks, errors do not propagate. Also, CBC decryption requires only the previous ciphertext, not the plaintext. OFB and CTR are both proven to be IND-CPA (assuming a secure block cipher and your counter is not reused), so they are no weaker than any other modes of operation.
Known plaintext is the weakest form of attack. Every cipher in modern cryptography is resistant to it. This would not be a big deal. Using AES in CBC mode is believed to be IND-CPA secure even, which means that it is secure against chosen plaintext attacks.
Any encryption that would be used (say AES-CBC) would be IND-CPA, which is resistant to known plaintext attacks. That is one of the most basic forms of security for symmetric encryption. Without it you have essentially nothing.
Completely wrong. Most STEM departments have 10 foreign applicants for every 1 domestic (at the graduate level at least). My old department (and I expect many others) had a quota for domestic students. They would not admit more than half foreign students even though many of them were far more qualified than domestic students who did get in.
The point is you have no proof. It adds nothing to make baseless accusations and, in fact, detracts from the conversation because it relieves you of the burden of actually responding intelligently.
Slashdot Mirror
Open-access journals seem to be redundant in CS. Since both IEEE and ACM allow you to put PDFs of your articles on your own personal page or preprint sites, and in my experience 100% of articles that I wanted to read which were written in the last ten years are on such sites, everything in CS is already de facto open-access. Google Scholar manages to find PDFs of articles put on the web in various places almost every time. In the most extreme case, you can always email one of the authors and have them send you a copy.
Two big exceptions to your rule, which apply to a lot of Groupons:
(1) You are getting a deal at the expense of some less informed person getting screwed.
(2) The company is stupid and actually isn't making a profit, in the hopes that you will come back for return business. You don't. You win.
unless they are using the fingerprint itself as the encryption key (highly inadvisable as you would have to get the same image every time)
There are some relatively new cryptographic constructs called fuzzy extractors which allow you to use imprecise data like biometrics to generate deterministic keys. As long as the image is within some threshold of original image, the same key will be extracted. The original image is stored as a secure sketch which essentially means it can be used as a "hint" to extract keys but alone it reveals nothing about the target biometric. The idea is that the difference between two images of the same finger will be significantly smaller than the difference between images of two different fingers, and the entropy you get from this is enough that you can do some cryptographic error correction magic to extract good, deterministic keys.
You are missing the point of the checksum. In a situation where random error or corruption might happen, then sure CRC is fine because it will most likely catch the change. In an adversarial setting, if someone changes any of your file maliciously they can EASILY craft it so it matches the old checksum. That is the point of cryptographic hashes, it is very difficult to find two things that hash to the same value. If you realize that, then you have to use at least SHA-1 because it is relatively easy right now to craft collisions with MD5.
This is what Apple is doing now but people flip out about it. Apps in the app store can only interact with files through the OS file chooser, so they are effectively sandboxed and can only see files explicitly allowed by the user.
Most of these things apply to regular ATMs too you know.
Worst logic ever. The reason they aren't using mobile communication is because we are monitoring it. We are denying them a valuable logistical tool.
Most exciting thing I've seen all day! Right now I use a subversion repository to collaborate with my coauthors, but my advisor isn't very technical and can't seem to figure it out half the time. This is going to be much easier.
Um... what? Determining whether P is or is not equal to NP is probably the largest open problem in complexity theory. I thought everybody knew that. I feel like I'm taking crazy pills here.
http://en.wikipedia.org/wiki/P_versus_NP_problem
You seem quite certain of that. Do you know something the rest of us don't?
Well its a theoretical attack against TLS because you can restart the connection and currently browsers will use the same parameters if you have a certain cookie set, giving you a chance to try again. It takes millions of tries though and each TLS handshake is rather slow so it isn't currently possible to use this attack on TLS even under the best conditions.
For lazy people a quick overview of this attack is that it uses very small differences between the amount of time it takes to decrypt a correctly padded TLS record and the time it takes to reject an incorrectly padded record (think of the padding as kind of a checksum). An attacker can modify encrypted records, send them to the server and discover whether the decryption is correctly padded or not based on the amount of time it takes to respond. With this knowledge, an attacker can interactively decrypt a record bit by bit, testing the padding over and over.
It only works in datagram TLS (DTLS) because regular TLS terminates a session after one incorrectly padded message. It also only works over LAN where you can get really precise timing.
Where did he say that? I find it hard to believe that he would because it is a well known fact that breaking RSA does not imply factoring. Think of it like this: if you can factor, then you can certainly calculate the decryption exponent (private key) from the encryption exponent and the factors of the modulus (using the totient of the modulus). This is exactly what you do when you are generating the private key in the first place. However, knowing only the modulus, the encryption exponent and a ciphertext, if I could find the eth root of something in a finite field, then I would be able to decrypt that ciphertext and get the message. I can do that without knowing the factorization of the modulus.
Currently nobody knows a way to find eth roots, so the surest way of breaking RSA is factoring, but there is no guarantee that such a method will not be found. If you don't believe me or the Wikipedia page you could always read the cited article by Dan Boneh, one of the top modern cryptographers in the world.
just look at the graph of rate of prime numbers vs number of digits or however you wanna phrase it, obviously it must intersect zero at some huge number (what would hitting negative even mean?)
According to the prime number theorem the probability of getting a prime number by randomly picking an n bit number is about 1/n. If you look at the graph it does not decrease linearly so it would never reach zero.
As other people have said, generating primes is actually quite easy. It is a direct consequence of two facts: checking if a number is prime can be done in polynomial time (see AKS primality test), and the distribution of primes is dense (that is, if you pick a random number, in a large enough range it has a non-negligible probability of being prime; see prime number theorem). That means you can quickly generate primes by picking a random number in your designated range and checking if it is prime, repeating until you get one.
Not saying that it would be useful for cryptography, but I think you are being a little generous when you say it can be checked in "seconds". Lets assume that the way they are testing Mersenne numbers is by starting at n=1 and checking whether 2^n-1 is a prime. If it could be done in, say, 10 seconds, then this distributed computing setup would have gotten to the current number, n=57,885,161, in 57,885,161 * 10 seconds / 360,000 = ~25 minutes. Since it has taken 17 years, I would assume it is harder to check than you think. That is not even taking into consideration that 2^n - 1 can only be prime when n is prime, which already pre-filters quite a few candidates.
Actually, it's "worse" than that: the "proof" that most modern PKCS crypto works is: "It's hard to find the (prime) factors of the product of two primes".
Small correction, there is actually no proof that RSA reduces to factoring. It is true that if you can factor you can break RSA, but you may also be able to break RSA without factoring. http://en.wikipedia.org/wiki/RSA_problem
OFB and CTR are weaker than CBC and similar modes in that you don't need to have correctly deciphered the previous block to decipher the next one, you only need to know the key, initialization vector and the position in the stream
If you have the key then you can decrypt the first block and all the other blocks in a CBC encrypted stream so it doesn't really matter. If you have the key you win no matter what. With CBC, losing a packet of ciphertext would mess up only adjacent blocks, errors do not propagate. Also, CBC decryption requires only the previous ciphertext, not the plaintext. OFB and CTR are both proven to be IND-CPA (assuming a secure block cipher and your counter is not reused), so they are no weaker than any other modes of operation.
You are the third person to post this comment. Short answer, no http://en.wikipedia.org/wiki/Ciphertext_indistinguishability
Known plaintext is the weakest form of attack. Every cipher in modern cryptography is resistant to it. This would not be a big deal. Using AES in CBC mode is believed to be IND-CPA secure even, which means that it is secure against chosen plaintext attacks.
Any encryption that would be used (say AES-CBC) would be IND-CPA, which is resistant to known plaintext attacks. That is one of the most basic forms of security for symmetric encryption. Without it you have essentially nothing.
Just use client-side encryption and you're good to go. Probably shouldn't trust them with your unencrypted data even if you are a US citizen.
Completely wrong. Most STEM departments have 10 foreign applicants for every 1 domestic (at the graduate level at least). My old department (and I expect many others) had a quota for domestic students. They would not admit more than half foreign students even though many of them were far more qualified than domestic students who did get in.
None of that made any sense.
The point is you have no proof. It adds nothing to make baseless accusations and, in fact, detracts from the conversation because it relieves you of the burden of actually responding intelligently.