skysight-inc/HackerNews huggingface dataset:
"If you roll your own crypto you're an idiot" is technically correct, but discouraging in all the wrong ways and worse for everyone in the long term. I've been a teaching assistant for MIT's introductory graduate crypto class, and I still don't consider myself qualified to implement core crypto algorithms. But I've seen -- and used -- entirely too many crypto implementations that are obviously poorly written in my eyes.

I would love to see a solution to the fearmongering that still keeps people aware of their mistakes. Perhaps public development is the answer -- many eyes make all bugs shallow, so all we need is more people who feel like their eyes are qualified. How many people have actually read the OpenSSL or gnutls or GPG source with an eye to its security?
No, what I am saying is that the borrowed money are not backed by value in the economy, and that returning them has to be painful.

Now I know Krugman says the value should appear in a puff of smoke once money is thrown in thin air, but that's more a matter of personal belief. Did it help curing the Great Depression? Perhaps; however there are numerous examples of where societies bankrupted themselves with borrowing and spending.
How to Get Siri to Provide Google Maps Directions, No Hack Required
I don't live in the USA and I'm interested in that question ... Americans shouldn't leave their socialists restrict their freedom. They do not understand that restricting the right to firearm is a way for the state to take more control. The problem is, maybe you never had any problem, but when you have, most of the time, the state isn't there to protect your ass.
And ... Why not to forbid cars as well? Knives, glasses, alcohol, tobacco, chimneys and so on ...? You totally dumb guys. People are not self-responsible? Learn them to be, rather than resricting privacy to « protect them from themselves » ...
But ... It won't happen. I'm living in a socialist country and I know how you, leftists, are thinking ... You only admit you mistakes when it's way to late. It's a shame.
Bigger screens, and possibly augmented/virtual reality will allow looking at larger parts of code. Code will be more modular. Unit testing will be built directly into languages as an intrinsic part, like compiler optimization or GC. Code will generate to a larger extent (think intelisense or code completion, but with better understandings of what you are trying to do.) Also code will self optimize to a larger extent.

touch screens, voice to text, and input methods similar to the Kinect will be used, but not the extent that people expect. Keyboards will still have a big place. Voice is too ambiguous and slow for much of programming, and touch screens and kinect style interactions require you to move too much. However, expect that touch pads will be more popular, and that they will have screens in them.

simple user facing programming languages for different interfaces will be omnipresent, and their lack of unification problematic. Many things will be programmable, and user programmable, and while unification efforts for commonality in how you program your fridge/toaster/tv will exist, they will not be enough to keep things from fragmenting. Voice interaction to program things will not progress as much as they could given the capabilities of voice recognition, simply because of a lack of well formatted connections between devices.

More documentation will be automatically generated by expert systems.

Saving power will be a bigger focus for programs, especially in enterprise. In moble Batteries will still not last as long as you want, though e-ink and better chips will help. concurrency and networking will be very important, with the rise of always on connectivity, and the limits of moore's law.

That's my best guess.
In my experience, "don't roll your own crypto" primarily means "do not reimplement a well-known algorithm, because you are likely to get it wrong and likely to leak side channels out the wazoo". I think most people have realized by now that inventing their own algorithm is a terrible idea. (Although certainly there are people who haven't realized that!)
There are a couple of crypto courses coming up on coursera.org that might be worth a look
Direct link to the donation page: https://archive.org/donate/
The Secrets of Sleep (May 2010)
I really liked this article, but I think the very best devs are the ones who admit they don't understand and then ask specific, intelligent questions.

Anyway, admitting you don't fully understand something is the first step to fully understanding it. Great article!
Interestingly with regard to (2), there is actually a (totally impractical) attack on AES that only affects the larger key 192 and 256-bit versions and not 128-bit AES - http://eprint.iacr.org/2009/317
You need to distinguish between:

1. "Rolling your own crypto" meaning "inventing your own algorithms".

If you invent your own algo for creating one-way hashes, performing symmetric encryption etc and are not an active, up-to-date cryptographer ... you will make a mistake.

This is a world for academics and researchers; for open publication of algorithms followed by the open publication of attacks on those algorithms.

2. "Rolling your own" meaning "Assembling known cryptographic primitives into a larger system".

If you assemble well-studied primitives (SHA-2, AES, HMAC) into larger systems ("I've invented a simple messaging system, guys!"), you are probably still mistaken.

But at least you won't be as much of a professional embarrassment (unless you're keeping passwords in plaintext or some such thing).

At this level, you're between academia and industry. Design at this level is mostly about using certain rules of thumb, exercising defence-in-depth and taking inspiration from existing designs that are battle-hardened. For example, when using multiple kinds of cryptographic operation, have different keys for each operation to mitigate potential bit-leaking attacks.

The good news is that you can get professional reviews done. Seek out respected security experts and ask if they are prepared to exchange labour for currency.
For this to make sense you have to look at statistics, not individuals. Statistically speaking your argument holds no water, but I'm happy for your friend. In her case it worked out well. But that's the exception, unfortunately.

http://answers.yahoo.com/question/index?qid=20121216092406AA...

"People like me" like to judge things on a wider basis than the exceptions confirming the rule.
Rails 4 changes (loads)
There is an important fact that is always missed in the gun control debate. People like to get caught up about minutiae - who and what type of guns should we be able to own, if at all.

Not sure how people miss this - the largest groups of murders in human history are governments by a long shot - events that typically take place some time after guns are confiscated. Ultimately, the right to bare arms is about a last resort against tyrannical government.
Hiya, this is my site. I noticed the spike in traffic (I tend to watch analytics when I'm bored. I don't have a problem)

I updated the code so it will respond to both htm and html.
"For wage earners this isn’t so much of a problem as long as wages inflate as well (which, well, they haven’t)"

This, I think is a bit of an overstatement. Although wages may not have inflated too much, compared to, say gold, they have certainly inflated in terms of quality of life. Prices of personal possessions are extremely low, compared to 50 or 100 years ago, mostly due to "technical progress". 100 years ago a watch was a great luxury - passed down from generation to generation. But today "everybody" owns a smartphone, a computer, a wardrobe full of clothes. Everyone can afford high-caloric food (at least in the "developed world"). Not very much like 100 years ago.
There are a lot of applications where we want encryption to be faster. The slowness of SSL delayed its widespread adoption until _very_ recently, and is still delaying it, for instance. And ciphers are often much faster on dedicated hardware (which a good attacker will have) than in software on a general-purpose chip.

It's better to make brute-force attacks infeasible by increasing the search space than by making each individual encryption take longer.
Speeding up HTTP with minimal protocol changes
Google is phasing out Google Sync. Now what, Outlook users?
Doesn't that Schneier quote only apply to symmetric algorithms (e.g. AES)? I thought asymmetric algorithms (e.g. public/key systems like RSA, as in the original question) have completely different characteristics and rules.

"NIST key management guidelines further suggest that 15360-bit RSA keys are equivalent in strength to 256-bit symmetric keys."

http://en.wikipedia.org/wiki/Key_size#Asymmetric_algorithm_k...
"Don’t laugh at anything, there are business opportunities in places you’ve never even knew existed."

Absolutely. The best entrepreneurs are the ones who can find opportunity in the most unexpected places.
I'm glad you like F#. I agree it is a great language and I think it fills a big gap on mono and the CLR. The foundation (www.fsharp.org) is still _very_ young! We are looking into how to improve cross platform tooling and support. For example, soon (if not already) MonoDevelop 3 will come with F# pre-built on Mac. There is still a lot of work to do but we do recognise this as a key issue. I encourage you to join the foundation and help out by suggesting how we might go about improving.

Zach (a programmer - never employed by Microsoft)
Why doesn't Mark Suster generally attend Y Combinator demo days?
People often mention quantum computing will break all encryption. Would that be a non-matter computer?
Love his tutorials. Motivates PCA by walking trough a creepy eigenface decomposition, and solves a political prediction problem with a ID3 implementation of a decision tree. I actually used the latter initial code scrap for writing an entire damn random forest implementation!

Really looking forward to his future discussion of computational topology and persistent homologies.
I only say this because you mentioned that some PMs had some problems with your work. People who gravitate to one of the PM roles are problem creators. They are not users and they are not developers. In order to make a living they need to extract value from the dev process. One of the methods in which this is done is politics, gatekeeper-ism, and gridlock. This manifests as FUD to upper management. If the project or technology is not seen as one the PM has instigated and is in control of, they will fight it and you with FUD. Never mind the fact that the PM probably knows nothing about the technologies in question. Unfortunately you will probably need to find some new clients.
Whenever they tried giving me this test, my score just went off the scale. In the end, they had to assign me a new type: SEXY. ;)
Dear Sophie - Motivational letters for Sophie from female role models
OpenSSL straddles a difficult line: on the one hand, security. On the other, performance. It carries a fair amount of state around in big context structures and there is a ton of clever, platform-specific code.

One alternative that I've played with is PolarSSL[1], which has the nice property that every module is designed to be compiled as a standalone.

It's slower and it's less efficient, but I suspect that it would be a lot more auditable.

[1] https://polarssl.org/
Are we going to play this game? How dare you call guns toys. Do you have any idea of how many crimes guns stop every year? How many rapes, how many robberies, how many homicides? This is not a small thing, some estimates put the number of rapes per day stopped due to the potential victim being armed or thought to be armed at more than a thousand. Per day.

The naive math of no guns = no gun crime is so easy, and so mentally satisfying to people who have no experience with guns. People who live in safe neighborhoods where crime is uncommon. People who have never been faced with life or death situations where having a gun could save someone's life, or save them from being raped, or robbed. But when the math becomes a more complex question of potentially trading off rape, or even homicide vs. potentially reducing one kind of mass homicide then the answers aren't quite so pat and easy are they?
so if that key size is increased, would these side channel attacks be either mitigated, or made impractical?
Hello, I'm the technical lead of the project.

Thank you for the feedback! We will try to make the fonts better readable.
Was it the size, the contrast, or the font that made it bad to read for you?
It might be worth mentioning that this is part of an offer to match donations 3-for-1 until December 31st.
I don't usual hit my thumb with a hammer, but I have no empirical evidence that I shouldn't. Maybe I should smash my thumb with a hammer occasionally?

Seriously, does this need research? Just try it, and you'll see some pain go away, not the least the mess of multiple copies of project directories and zip files.

Not that there isn't anything research worthy about version control, but it is entirely possible to recognize it as a good thing without it.
Schneier's Applied Cryptography is a very readable introduction.

If you want to get into the actual mathematics of it, then it is considerably more difficult. Luckily for me I took courses in pure math, RSA and some hashing functions at university, so I had to learn it :-)

As others have said, crypto is properly hard and it's very easy to make cock-ups. So unless you're prepared to do the years of work becoming a proper researcher, don't try and design any algorithms yourself (for fun is ok, but not for real world use).
call me when 3d printers would be able to print itself from materials found in nature.
According to the docs, Quintus does support mouse and touch input.

On my PC, the demo is controlled by keyboard only. Presumably, they wanted to make the code as small as possible so they didn't put touch controls in.

http://html5quintus.com/quintus/docs/quintus_input.html
That's because quantum computers are still a pipe dream, so people assume it can do anything.

Anyway, no - http://security.stackexchange.com/questions/25375/why-not-us... tells us that you'd need the energy of all the output of our own sun for 32 years to even just count to 2^192
Didn't quite find anything noteworthy in that article. I am in fact surprised that such an article can feature in HBR.
> I have never felt the need to own firearms in order to feel secure

robomartin: I enjoy many of your posts and understand where you're coming from. Regarding this point, however, if you saw videos of Koreatown during the LA Riots, or in New Orleans after Katrina, or of Vancouver or London recently, you saw video of real times - in industrialized society - where the police were absent and law & order broke down.

The Koreans with guns defended their stores against rioting looters. That happened in America. It happened to the parents of people I know.

http://www.youtube.com/watch?v=PmsKGhLdZuQ

http://www.youtube.com/watch?v=NmQW6xLECUU

I hope you'd agree then that you don't have to be a "nut case" to imagine you need to defend your family, property, and loved ones from fellow Americans in the event of riots. It's happened, multiple times, as the clips above show.
This system is (almost) just a variant of the one-time pad.

One-time pad: before Alice and Bob need to send secret messages to one another, they generate a large blob of random bits and each take one copy of it. They keep these bits very secret. When one needs to send an N-bit message to the other, s/he takes the next N bits of the blob and XORs them with the message. This is trivial to do and provably impossible to break -- except that making and sharing and keeping all that key data (the big blob of bits) is really inconvenient and easy to get wrong.

So, anyway, your system has the same weaknesses as any other one-time pad: you need new key data for every message you send, which means you have to make a lot of key data, share it with your partner in crime, and remember it for a long time, all without leaking any of it.

It's not quite the same as a one-time pad. You can get by with fewer bits of key than bits of message, provided there's still "enough" key. On the other hand, "enough" is quite a lot, much more than the key length of a typical symmetric cryptosystem like AES.

Anyway, I don't think this counts as "by far the simplest encryption to understand". A standard one-time pad is simpler and stronger, and the extra complexity of multiplying large prime numbers doesn't really buy you anything much to compensate.
Similar point has been raised in the following paper:

http://www.bmj.com/content/327/7429/1459 "Parachute use to prevent death and major trauma related to gravitational challenge: systematic review of randomised controlled trials"

Results: "We were unable to identify any randomised controlled trials of parachute intervention."
Facial expressions simulator
Totally dissatisfied. The main complaint is how blatant and mindlessly people are concerned with power. Every single aspect to them is a huge political game. Their chosen profession is 'power'. They have no other goals and just see tech as a means to that end. It is as mindless as it is bizarre. Entire departments are created by high level people with the sole goal of trying to take over existing departments. The result is there are lots of people and departments who have the same job. Obviously it is difficult to develop software in this environment.

I just want to make an honest living making useful stuff without having to deal with the crazies that fill large companies.
A dramatically smaller LEGO could still probably make a living off selling model design/instructions and Mindstorms software.
Here are some more links to FPGA implementations of other home computers.

Commodore 64:
(http://www.syntiac.com/fpga64.html)

Commodore PET:
(http://www.stepinfusion.com/projects/pet2001fpga/)

Mac Plus (incomplete??):
(http://www.bigmessowires.com/category/plustoo/)

Sinclair ZX81:
(http://zxgate.sourceforge.net/zx81.html)

Sinclair Spectrum:
(http://www.mikestirling.co.uk/zx-spectrum-on-an-fpga/)

MSX: (commercial product, I'm not sure if there's any code downloads)
(https://en.wikipedia.org/wiki/1chipMSX)

The popular music ICs from a variety of machines in one box:
(http://www.gadgetfactory.net/2012/06/introducing-the-retroca...)

EDIT:

Atari ST: (http://www.experiment-s.de/en/)

Atari bits n bobs (http://hardware.atari.org/vhdl/vhdl.htm)

A variety of different systems - Videopac; Adventure Vision; Colecovision; Bally Astrocade: (http://www.fpgaarcade.com/platforms.htm)
"Password is too short (minimum is 8 characters)" - this can lose you users. I don't want to invent yet another password just to try this out. So offer feedback on password strength, but let users decide on the secutity/convenience tradeoff. Better yet, use openid.
A good reason to use the right tools of static analysis, rather than look manually. ;)
Reimagining Matrices
In the web programming world, we will still be trying to shoe horn fully-dessed circa-mid-90s client-server applications into documents-with-scripts-and-sockets. It will be necessary to know at least 17 languages to develop a modern HTML6 application.

Developers who are today children in primary school will be writing 70-character denunciations of node.js, which will be to be as old-fashioned as Ruby on Rails. This link-baiting intellectual dandruff, masquerading as deep thought, will constitute 100% of the HN front page.

Companies that sprung up to simplify Amazon Web Services will themselves become sufficiently complex that a new ecosystem of simplifier-simplifiers will spring up. You will be able to write code that runs at any one of the two dozen layers over cloud providers who layer over two hundred IaaS providers without modification. That's what the sticker will say, anyhow.

Github will have even more completely supplanted sourceforge. Good riddance.

99% of programming will be done in languages which are direct, legal descendants of the languages in which 99% of programming is done today.
Information Managing in Web3.0 way
From research to business, how to manage information using Semantic Web powered engine.
I don't intend for anyone to actually implement this. It's just to understand how encryption can work. i.e. how it's possible for an operation in one direction to be quick and easy, but the reverse operation is hard and slow. (And why it's hard to implement properly.)

But you are right that as described it is a lot like a one time pad. (Especially since if you encrypt a known message you can instantly find the password.)
And so how is strangling the economy, creating unemployment and destroying our future helping to pay for our debt?
now there is :

here is how you can pull a specific username's submissions and you can add filters:
http://api.thriftdb.com/api.hnsearch.com/items/_search?filte...

And then here is how you can pull the comments for a specific thread/discussion/id:
http://api.thriftdb.com/api.hnsearch.com/items/_search?filte...

you can now grab a lot of data.. including they enlarged the site's rss feed in hopes of slowing a few of the scrapers..

there are a few items missing, but they added a lot:
http://www.hnsearch.com/api

btw that includes a user bio now, as well as things you've upvoted... etc.. its all just done via filters..

the also boosted the rss feed to help slow down the strapers
Public key crypto schemes (RSA, elliptic curve etc.) are vulnerable to some variation of Shor's algorithm. We'll have to move to quantum crypto when this happens. Hell for all I know D-Wave's machines can already break RSA for the DHS.

http://www.infosecisland.com/blogview/19707-The-Emerging-Thr...

The 256 bit key size is still the recommended maximum since no increase will help against quantum computers.
Our First Experiment
People should really be saying "If you roll your own crypto, and then use it, expecting to stay secure against GCHQ and NSA, then you're an idiot".

But rolling your own crypto, then attacking it, is probably a good learning exercise. Having a group of people rolling their own crypto, and then attacking each other's attempts is probably better.

Somewhere there's a list of common mistakes people make, and it's surprising how often those mistakes are found in commercial "MILITARY GRADE ENCRYPTION!"