Hacker Newsnew | past | comments | ask | show | jobs | submit | greenrice's commentslogin

You're kidding yourself if you think Google is "just a well known consumer brand"...


I use several Google products, daily. I also eat food Kraft's foods daily. I also use Comcast every hour of every day of the week. I'm not pining over a job at any of these companies.


How is Google anything more than a well-known consumer brand?


Because Google is probably the most well-known advertising agency on the planet?

They're not much of a consumer brand tbh, but they pull in tens of billions a year creating virtual properties to sell advertising space on.


By that logic, you could also say that McDonald's isn't a restaurant chain, but a real estate company: http://seekingalpha.com/article/73533-mcdonalds-is-a-real-es...


Well, who's Google's customers? People who buy ads, or free search users?

(an aside) One of the startups I worked for years ago, rented a huge office near San Jose, but decided to change directions and hire out of cheaper locales for a while. So we sublet the space out. For a good 2 years this space generated more revenue than the rest of the company and we joked that perhaps we should get into the real estate business. We even had two employees with real estate licenses in 3 states.


I wonder if that's how 42floors got their idea.


One could make a similar argument for just about any large financial, real-estate, or holdings company. Bank of America, General Mills, and General Electric to name a few.


"They're not much of a consumer brand tbh"

People google stuff on bing, tho. So, if you're brand is a verb, in widespread common usage, I'd say it's doing ok. Kinda like Kleenex.


Well, for one they just acquired eight of the worlds best robotics/AI teams. You don't see Kraft trying to bring the singularity nearer.


Most of the criticisms by Eric Posner explain reasons why Bitcoin can't replace fiat currency. I don't think the goal is to replace fiat; rather Bitcoin would be a great supplement, as it accomplishes different purposes.


Hit the nail on the head. There is a plethora of important and difficult problems to solve, and the millenial generation has to trudge through the pile of shit that's been left accumulating for the past several decades. Our most pressing matters involve navigating a new world that is built on the internet.


Ok, San Francisco, it's time to bite the bullet and build (much) more housing. This is getting ridiculous.


How experienced are you expected to be if you want to be a Codementor?


"The Pittsburgh Left" is very common practice there, which is to give the right of way to the opposite car in the intersection that is turning left. Definitely a much more relaxed and polite driving environment than anywhere on the east/west coasts.


I think you need to re-read the comment that you responded to.


For now. Just wait until sophisticated AI is developed...


yeh, time to use simple nokia phones again.


Time to use tin cans again.


There seems to be a certain aspect of the night owl that is present in many programmers, I for one am far more productive in the late-afternoon and evening than I am in the morning. Setting a morning-to-evening schedule isn't going to work for a lot of us.


> There seems to be a certain aspect of the night owl that is present in many programmers

This seems likely and could be attributed to the fact that we receive above average artificial light from staring at screens too late into the evening.


Why use symmetric cryptography over public-key? I thought RSA was theoretically secure as long as factoring sufficiently large prime numbers is impossible.


Argh.

First, RSA is about factoring composites.

Second, factoring those composites at popular key sizes isn't impossible.

Third, public-key algorithms are much harder to get right; they involve direct mathematical operations on plaintexts and devolve to well-studied math problems much more readily than symmetric ciphers do.

You should absolutely avoid public-key crypto, including public-key key agreement schemes like Diffie-Hellman, if your needs don't absolutely require them.


You left out speed. The reason we do not use PKE exclusively is that we do not want to wait a week to encrypt a megabyte of plaintext. In fact, it is not so much that PKE is what is slow; rather it is that theoretical constructions, which are the only thing we have for PKE but which also exist for symmetric ciphers, hash functions, etc. are slow.

Also, while PKE is sensitive to implementation issues and parameter choices, you can have much higher assurance that there are no theoretical weaknesses than you can have with something like AES. With PKE you usually have a proof that the security of the system depends on the hardness of one problem, regardless of the specific attack strategy the adversary uses. We do not say that ElGamal is secure against chosen plaintext attacks because we ran a battery of tests designed to detect vulnerabilities to particular CPA strategies; we say it is secure because we can prove that any CPA attack on ElGamal can be used to solve the DLOG problem, and so we only really have to worry about the lower bound on solutions to one problem. With something like AES we only test for certain attack strategies and a few general heuristics that suggest a block cipher is secure.

This is not to say that AES is not secure, nor that PKE is a magic bullet.


Besides, symmetric schemes tend to perform better. Hence the idea of using a public-key scheme like DH for key exchange and then switch to symmetric crypto like AES.

Always avoiding public-key isn't really possible unless you have some sort of secure channel to agree on a key for some communication. But then again, if you have that channel, you might just as well communicate through that.

When encrypting files locally though, there is absolutely no reason I can think of to use public-key cryptography.


> When encrypting files locally though, there is absolutely no reason I can think of to use public-key cryptography.

So that you don't lose your decryption key just because your computer was encrypting when it was seized?

Of course, if the weaknesses are sufficient, then that's irrelevant, but it's certainly "a reason".


> You should absolutely avoid public-key crypto, including public-key key agreement schemes like Diffie-Hellman, if your needs don't absolutely require them.

Is there an alternative to public-key crypto? We all need to do stuff online.


Sure there is: pre-shared keys, exchanged out-of-band.


This works if physical contact is available and parties are trusted (even the weakest literal reading of fourth amendment says "right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures," -- exchanging a key token counts as such).

Yet what of basic online communications where key-exchange is necessary and where we have very little say about the protocols involved?


You probably know what I was getting at. Public-key crypto is very important in today's world. If we can't use the current system, we need something to replace it. Pre-shared keys is for a different scenario.


You are missing both Schneier's point and mine. The point is that if you can contrive of a way to (perhaps inconveniently) pre-share static keys, you should consider doing that instead of relying on number theory to protect your secrets.


> The point is that if you can contrive of a way to (perhaps inconveniently) pre-share static keys, you should consider doing that instead of relying on number theory to protect your secrets.

No I got that just fine. As you know, I'm suggesting that not using public-key crypto or something else for the same purpose is impractical.


Nerdnit, but it's not like AES is based on some wholesome certified organic granola theory to the exclusion of number theory. Number theory didn't wait around 2+ millennia to be useful only to be dissed like that, man!


and you are conveniently missing his point. If we were to throw away public key technology today and say 'Only pre-shared keys' some significant portion of the internet would simply be unencrypted. What do we do about that?


We could all start swapping 1TB drives full of random noise. One-time pads are mathematically proven to be unbreakable if implemented correctly.


> We could all start swapping 1TB drives full of random noise.

This is "sort-of" what I've come to think Miranda was facilitating for Greenwald - it makes little sense that the purpose was for him to mainly carry documents, as while the documents would be more secure if he was not stopped vs. transferring them via the internet, they would have had to consider the possibility that he might be.

But if you pass along a lot of random data, then if it never leaves your possesion, you can be reasonably sure that that data can be safely used as a source for one time pads or keys. If it gets intercepted, then so what? You just ignore that batch of data even if it is handed back to you.


This would be doubly interesting, as it would mean the key he was carrying for the one file would be a smoke screen of sorts.

Of course, with UK law saying they can detain you indefinitely until you hand over your keys if they think a file is encrypted, that might not be a good move... though obviously in retrospect they didn't make use of that here.


Is PGP included as an insecure standard as you mention? It used a combination, so is it safe?


> factoring sufficiently large prime numbers

You probably didn't mean it that way but I feel like fixing that. Prime numbers have no factors except for 1 and themselves. That's the definition of a prime number. What you're thinking about are composites which are a product of two large prime numbers.


I can factor arbitrarily large prime numbers as fast as I can read 'em, so long as you promise me that's all you'll feed me...


You can factor the prime numbers in a list of arbitrary large primes and composites too[1].

[1] http://en.wikipedia.org/wiki/Primality_test#Fast_determinist...


Sure, but not "as fast as I can read them". Also, I'd have to think.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: