Hacker Newsnew | comments | show | ask | jobs | submit | aneesh's comments login

What tools do you use today, and what don't they do well enough?


> I think Netflix just shows what's the "maximum" speed needed to deliver their service.

Exactly this. Assuming your connection is faster than 3 Mbps, the number they are showing is neither the bandwidth your ISP is providing you, nor the instantaneous rate that bits are flowing to your home network. If you have a faster connection, they will send you large chunks of bits at a rate higher than 3 Mbps (upto 35 Mbps from what I've seen), and then send nothing for several seconds.

It seems that Netflix tops out at 5.8 Mbps and 1920x1080 no matter how capable your network connection is -- that's the highest number this test will produce.


I've seen around 10Mbps for Super HD streams.


> Specifically, young single women in cities out-earn men, but their earning power erodes as they get older.

Not necessarily -- you're comparing two different generations. These young women may well continue to out-earn men as they get older.


Although you're right that a 256-bit RSA key is weaker than a 256-bit AES key, this is not an intrinsic property of symmetric vs asymmetric encryption. It has to do with how you search the key space. To break 256-bit RSA encryption, it is sufficient (not known whether it is necessary) to factor the 256-bit modulus n, whereas to break 256-bit AES, you have to essentially run AES with the whole keyspace of 2^256 keys.


If you are trying to brute-force guess an RSA key, the fact that the factors which produce the key should be prime (well, co-prime with respect to each other to be more precise) has the potential to greatly reduce the search space. For small keys it is practical to have precomputed what this limited search space is so of the 2^N possible keys you can be fairly sure that you only need to check a much smaller subset of them. You still have to use brute-force, but unlike with symetic methods your search space can be much smaller than the entire keyspace. For larger keys this pre computation (and storage) becomes impractical (with current tech). I have no idea off the top of my head where the point it currently becomes impractical occurs relative to 256 bit keys though.


I doubt this approach makes sense for any size prime. Let's assume a 50-digit number to factor. According to http://primes.utm.edu/howmany.shtml, there are over 10^21 primes less than 10^24. Let's assume you manage to store 10^3 of them in a byte of memory. Then, you would need 10^18 bytes, or a million terabytes of storage to store those primes.

That isn't practical, so let's scale back to primes around 10^20 (around 10^18 different primes) Then, you would need around a thousand terabytes (still assuming that you manage to compress your 64-bit or so primes to fit 1000 of them in 8 bits)

I'll assume you build the machine with those drives, and can do trial divisions in parallel, 1000 CPUs, a billion divisions per CPU per second. you still would need 10^6 seconds to do a complete search over all primes. Rounding down, that is a week.

For comparison, https://sites.google.com/site/bbuhrow/home claims:

"I've seen C90's factored in less than 4 minutes on an 8 core box.

According to what I understand, C90 is tech speak for "90 digits, product of two coprime numbers"


Then, you would need 10^18 bytes, or a million terabytes of storage to store those primes. That isn't practical, so let's scale back to primes around 10^20 (around 10^18 different primes)

Actually, a million terabytes (an exabyte) is really quite feasible. Not on an individual scale, but I would be very surprised if governments (all of them, really) did not have this sort of thing set up.


Do we actually know that it's not an "intrinsic property of symmetric vs asymmetric encryption"? It seems like finding an asymmetric algorithm that's comparably efficient to our symmetric algorithms is a long-outstanding problem in crypto.

Perhaps there's a fundamental limitation here?


Keep in mind that theoretical constructions of symmetric ciphers are nowhere near as fast as practical constructions like AES. The real issue is that no public-key algorithms are known other than those that are based on theoretical constructions.

Also, our knowledge of complexity theory is not sufficient to show that cryptography is even possible. I suspect that improvements in our knowledge of complexity theory will greatly improve our cryptographic primitives, in both security and efficiency.


Keep in mind that theoretical constructions of symmetric ciphers are nowhere near as fast as practical constructions like AES.

What I hear you saying is "AES was designed with a practical implementation in mind, whereas asymmetric constructions were more 'discovered' from theoretical work that's often unweildy when reduced to practice". This about right?

The real issue is that no public-key algorithms are known other than those that are based on theoretical constructions.

I dunno. http://en.wikipedia.org/wiki/Merkle%27s_Puzzles always seemed pretty down-to-Earth to me, but they're inefficient as heck too. :-)


While it is true that AES was designed with practicality in mind, that is not what the difference between a theoretical construction and a practical construction is about. The theory of cryptography is based on complexity-theoretic arguments (or in some cases, information-theoretic arguments) about cryptographic constructions, essentially showing that any algorithm that can be used to violate some security property of the system can be used to solve some hard problem. For example, in the case of the Goldwasser-Micali system, any chosen plaintext attack can be used to solve the quadratic residuosity problem efficiently. On the other hand, there is no such proof for AES; the evidence in favor of the security of AES is heuristic, based on a combination of statistical tests, resistance to known attacks on block ciphers, and other measures that have been developed over the past few decades.

This is not to say that AES should not be trusted. AES is a fine cipher, it is efficient, and unless someone can show us a practical attack the heuristic evidence is pretty strong.

Now, as for Merkle puzzles, that system is not considered secure by cryptographic standards. A cryptographic construction is not secure unless it requires the adversary to do work that is exponential in some parameter in the system (the security parameter), while parties that know some secret (such a key) only do work that is polynomial in all parameters of the system. In the case of RSA, for example, parties that are aware of the secret key must do work that is cubic in the security parameter, while the adversary must do work that is exponential in the cube root of the security parameter. Whether such systems actually exist is still an open question, as it turns out; a positive answer to this question would imply that P does not equal NP. Cryptographers generally assume certain truths about complexity theory, beyond the P vs. NP problem, and cryptography research has actually opened new areas of complexity theory that are based on such assumptions (such as the notion of knowledge complexity, which emerged from the work on zero knowledge proof systems).


Thanks for explaining all this.

The reason I brought up Merkle puzzles is because they depend on a symmetric cipher or one-way hash function, giving them one foot in that first category.


OS X doesn't cost $29.99. It costs $29.99 plus the cost of Apple hardware (the cheapest of which is the $600 Mini). Unless you go the Hackintosh route, you can't install OS X on non-Apple hardware.

Whereas you can install your $100 Windows license on your choice of hardware devices that support it.


You could just say "Windows runs on a wide variety of hardware, OSX does not" to more simply get your point across.


Okay, the point being made is "Apple hardware is not cheap, and you need Apple hardware to properly run OS X".

It's made in a very hand-wavy way, though, which I find a bit annoying.


That's not the same point.

Edit: At least the poster now acknowledges this. Anonymous downvotes? And people claim we're not edging closer to Reddit more and more each day.


> Anonymous downvotes?

All votes on HN are anonymous, whether they're upvotes or downvotes. Showing who voted which way on what just isn't one of the features of the site, and that's a good thing.


I wouldn't worry about random down votes, they happen all the time and are eventually balanced out by a level head with a click to spare.


> For example, iCloud (all it offers) could have been implemented on top of AWS.

Not just "could have". It actually IS implemented on AWS. iCloud uses AWS and Windows Azure as its backend.

Source: http://venturebeat.com/2011/09/03/icloud-azure-amazon/


Comparative advantage is actually even more subtle than that. Even if we're both better at photos than widgets, it's still beneficial for me to produce the one I'm better at relative to you (say photos), and for you to produce widgets. Then we can trade with each other and both gain from trade.


As my econ 101 lecturer used to say 'we have to mangle the english language and use the term more better'

As long as I am more better at photos than you, you produce the widgets, and I produce the photos.

For some reason that hashing of the language sticks in my mind like a beacon and ensures I never lose the concept of comparative advantage.


Not quite right. In a little endian system, the least significant byte is the leftmost one (ie, lowest address). The order of bits within a byte is the same regardless of endianness.

So 10 is always 2.


Ah, well I stand corrected, Mr. Hamming :)


That saved chats folder in Gmail doesn't seem to be available to IMAP clients. Anyone know a way back up chats?


This may be useful: http://martinml.com/en/how-to-download-and-backup-your-gtalk...


In March 2009, I wrote:

PG made an interesting analogy to the college admissions process. How long until we see an "Common App" for seed firms, and a common decision timeline?


The answer was two years, apparently.



Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact