Technology is Heroin (2009) - <AUTHOR> http://www.whattofix.com/blog/archives/2009/02/technology-is-h.php <comment><USER2> Learning how to deal with the effects of technology, the instant gratification and the multi-sensory stimulation it provides is, indeed, one of the great challenges of the modern age.

The writer's specific examples grate on me. I do not think that most of them are supportable - they seem to originate from a mono-cultural understanding of the world which muddles influences from non-Western cultures with the effects of technology. His description of life in rural America is important, not because of the similarities to life in other historical cultures, but because of the differences.

Take the music. There are more cultures in human history than merely rural America. Many of them have historically relied on drum-heavy music.

Not just African music, either. Rhythm based music (often with spoken words) has been important to many cultures and is not some sort of new demon fostered by technology. I would "blame" multi-culturalism on its popularity, not iTunes.

[http://www.youtube.com/watch?v=Pxk7c38Q-lQ](http://www.youtube.com/watch?v=Pxk7c38Q-lQ)

I do not believe in the slightest that intelligence is going down - not unless you compare the elite of the past to the failing students of the present. After all, the vast majority of people either didn't have access to much reading material or have the time to peruse it.

We now have access to an always-on research library through the Internet. Does everyone use it to its full potential? No, but there are a surprisingly high number of people who go out and read research studies and long-form articles of their own volition. I do not think books are innately superior.

Does his suggestion that Indians and Chinese are writing the software, which Westerners merely consume, really jive with your experiences?

The drug war saved our country?

I do not want to fall prey to middlebrow dismissal, but these arguments unnerve me and I think the point could have been made in a better way.

</comment><comment><USER3> The author goes into delightful depth about the history of addiction, but then implies at the end ("things that take mor brain time win") that after all that we haven't evolved any defenses against it.

But there _are_ checks and balances against addiction in our culture. Your friends start to get concerned. You lose your job and can't pay your WoW bill anymore.

And these events afford us a time for reflection. I specifically _don 't_ do World of Warcraft (or amphetamines) _because_ I know they're good at capturing my "brain time". My fear is bad for WoW's growth.

I do agree Internet addiction is a public health crisis. But I don't think we're as powerless to take it on, both individually an collectively, as the author implies.

<comment><USER4> The moment you can't pay your WoW bill its too late, imagine how fucked up you must be not to be able to pay $15 a month? Hell, Comcast is more expensive.

<comment><USER5> Perhaps "you lose your job and decide that your WoW bill is a non-essential expense, and make the one-time, non-trivial-to-reverse decision to cut it, which is much easier than every fifteen minutes crushing the urge to start playing."

<comment><USER4> Yeah, but you lost your job!!!

</comment></comment></comment></comment><comment><USER6> If you like this kind of Science Fiction check out Neuromancer by William Gibson

But seriously saying Technology is Heroin is like saying Obama is Hitler.

Heroin is a serious fucking drug that will destroy your life. If your a heroin addict you can't just stop doing heroin and go back packing in the forest for a week.

Yet people take breaks from technology and the internet all the time and are perfectly fine. Theres plenty of technology to be afraid of; dying in a car accident, sitting in a chair too much, but Instagraming every meal you eat is not one of them, thats just a little weird.

<comment><USER7> correct title should have been "Technology is Dopamine". It is really surprising to not see a mentioning of dopamine in an article on addiction of technology.

Btw, dopamine is also key player in heroin addiction.

>Yet people take breaks from technology and the internet all the time and are perfectly fine.

people take breaks from smoking, for example, all the time (i'm saying this as a 10 years long smoker - i was taking breaks from smoking and i was perfectly fine, just wanted to smoke the way i want to check email periodically. Quit smoking 10+ years ago, still check email/stocks/news looking for the "rush" though :)

</comment></comment><comment><USER8> Although I strongly agree with the basic premise -- namely, that many of us could benefit from some reflection on our screen-gazing habits -- after the Brief History of Drugs portion of this piece, it drifts off into speculation that could be attributed to a William Gibson story. The comparison here might be valid, but this piece could use some more info on how technology measurably affects quality of life, quality of social health, and other factors.

</comment><comment><USER9> This guy doesn't know shit about music. \- A music teacher.

</comment><comment><USER10> TV, video games, internet - information technology is evolving towards Matrix- like virtual environment. It's not going to be forced on us by aliens, or intelligent machines. We are going to build it, and we are going to like it.

Cochlear implants and artificial retinas can already inject information directly into our brains, bypassing our senses. Artificial skin is being developed to provide a sense of touch to prosthetic limbs. Direct brain to brain communication was demonstrated, where one person was able to move another person's finger as if it was his own finger.

A virtual reality technology has been pretty lame so far. However, if traditional input/output devices are bypassed, people can experience it in a natural way. A brain does not care where the data came from - a computer, or your eyes - it's all just electrical signals. As long as that data is realistic enough, your brain will believe it. Every sensory experience from a real world can be recorded, analyzed, modified, and recreated in a virtual world. Sound, touch, smell, taste - they are just patterns of electrical activity to our brains.

After the technology is available, people are going to gradually migrate to this new social environment. Your physical body remains in the real world, where it can be connected to a sophisticated life-support machine, but most of the time you spent in the "Matrix". Virtual reality will be interfaced with a real world. There's no reason why it should be a closed, isolated environment. Anyone will be able to perform their jobs in the real world from the virtual one. A doctor can monitor your health as you lie down strapped to your life support machine. Even a surgery can be done remotely. If people don't want to leave the virtual world to do something in the real one, the technology will appear to make it possible.

Now, back to the entertainment - can you imagine being a god? Anything you can imagine will be possible. More than that - anything that anyone can imagine will be shared and experienced. Just like in the real world, people will create, buy, and sell good designs. A design can be anything - from a new pair of shoes, to an entire planet, to a weird feeling, to an experience of being a spider.

Your brain will believe it's real. Any you're going to like it.

<comment><USER11> Would most people want to be gods? Video games are more fun without using cheat codes.

<comment><USER10> I don't see your point. If you don't want to do something, then don't do it.

My point was you'd be free to create your own reality, limited only by your imagination.

<comment><USER11> Well your reality might conflict with other people's, so you're not 100% free.

<comment><USER10> Nope. If it's your reality, then you can do absolutely anything you want. Other people will have to play by your rules (if they want to be in your reality). This is the same as if you created your own private video game.

If you actually want to interact with other people in a 'shared' reality, then of course you would have to follow rules set by whoever created that reality.

</comment></comment></comment></comment></comment><comment><USER12> Seriously? What arbitrary metric of cultural value is this guy using other than nostalgia? He makes a truly fascinating comparison, but like many of you have said, his statistics are dubious. Technology's influence on evolution / selection in modern society pushes us towards efficiency, connectivity, knowledge, and truth. Its influence on art/music is profound, too, but we can't qualify art anyway

<comment><USER7> >Technology's influence on evolution / selection in modern society pushes us towards efficiency, connectivity, knowledge, and truth.

it is really fascinating statement. Is gen X more efficient than boomers? and Millenials more efficient than gen X? I'd agree with more connected. The next 2 are also doubtful - more knowledgeable (vs. baseline of available knowledge) and more truthful.

</comment></comment><comment><USER4> Heroin brought euphoria reading Wikipedia has made me knowledgeable on many diverse subjects and those video games might have increased my focus and problem solving skills. Video games and to a lesser extent television are stimulating, while most drugs are not.

<comment><USER13> _Video games and to a lesser extent television are stimulating, while most drugs are not._

What about 'stimulants' then, mmm? Oh wait, you were only talking about mental stimulation? Many actually do sharpen the mind. Nootropics? What about psychadelics or lesser psychoactives then? Oh wait, you don't consider those experiences 'stimulating'?

You put television above drugs? Psychoactives and similar experiences (eg. sensory deprivation) really are critical to the history of human cultures... in particular the emergence and development of visual art[1] and other forms of communication (glyphs, writing, dance...). Television and radio, for all their wonders, historically speaking do represent a johnny-come-lately, distributed programming channel for an (a)pathetic population of pliant, endebted, time-poor, couch-dwelling wageslaves subsisting on artifice and an everpresent supply of tangential mental wankery.

I agree fully with 'all things in moderation, including moderation' as suggested by your first sentence, but I disagree strongly with your conclusion.

[1] [https://www.youtube.com/watch?v=DtymYxADpnE](https://www.youtube.com/watch?v=DtymYxADpnE)

</comment></comment><comment><USER14> Some good points, but Technology is a stimulant not a depressant (unless you spend all your time on facebook looking at your friends' pictures), so it's more like Cocaine.

</comment><comment><USER15> I think the problem is that there is too much content available, and it paradoxically reduces interest.</comment>


News Publishers Call On Europe To Support Them Against Aggregators - <AUTHOR> http://paidcontent.org/article/419-news-publishers-call-on-europe-to-support-them-against-aggregators/

<comment><USER2> I think there are two things about the internet, that are pissing off newspapers.

1\. Power-Loss

Newspapers do not dominate public discussions any more. This is nothing new and the melting adrevenues are just proving the pint to all those few that didn't already knew it.

2\. Being forced to be engaged

Newspapers still have a chance, because quality still matters. The question is how to organize a profitable quality-producing workflow. There's no ultimate answer yet, but for the publishers it is already humiliating enough to be forced to do anything (see point 1).

</comment><comment><USER3> It seems the organizations that are participating in this are still stuck in a 20th century media monopoly mindset. They really don't get the Web, and in the case of the American companies (Dow Jones, etc.) seem to be angling to regulate the clock back to 1987, when they didn't have to deal with more than a handful of competitors, and pesky things like fair use, hyperlinks, and Google weren't a concern.

</comment><comment><USER4> It seems they haven't heard of robots.txt.

</comment><comment><USER5> It must feel really horrible to have your content spidered, indexed and found by users who will come to your site and see your ads.

As far as I have understood the issue, the newspapers want to control how users interact with the site, coming in from the front-page where they can tempt/lure the users to more on-site content and more ads, or just have two page-views and double ads for that one same story.

What I don't get, is how in this time and age where everyone should know more or less how the World wide web works, anyone can think they can control how users interact with your content.

<comment><USER6> I work at a newspaper, and it goes a little something like this: _The people in charge don't really think of their website as a part of the world wide web, but as a part of the newspaper._

There are a lot of reasons for this, journalism school, "the way things have always been done", etc. The rammifications are that even the young, 20 something reporters don't see the value of the internet, the opportunity to have users interact with their content. (aside: in newspaper speak, that would be "readers read their content")</comment></comment>


Me and My Numb Thumb: A Tale of Tech, Texts and Tendons - <AUTHOR> https://www.nytimes.com/2018/05/19/technology/smartphone-overuse-numb-thumb.html <comment><USER2> A few things I started early in my career that may or may not have helped me avoid finger problems but I figure certainly didn't hurt:

1\. Rearrange a few select keys - Backspace goes on Capslock, Ctrl goes on Alt, Alt goes on Windows key, Windows key goes on Ctrl.

Doing this allows me to hit Ctrl with my thumb instead of my pinky with way less wrist rotation. Alt can then still be hit with my thumb with a short reach. Backspace doesn't require completely extending my whole right hand.

2\. Switching to the Dvorak keyboard layout. While claims that Dvorak is faster than Qwerty are dubious, I think it's fairly clear that there is less finger movement with Dvorak. My fingers stay much more on the home row.

3\. Using Vim. The above combined with remapping Escape to something not in the far upper left corner means I do very little weird hand contortions at all when coding. But, with Ctrl on Alt, any IDE requires much less wrist movement.

Yes my keyboard is completely weird and my editor incomprehensible to anyone else, but my hands are super comfy. For an 80/20 optimization, just rearranging Backspace, Ctrl, and Alt might save you the worst of wrist damage. On Windows a simple AutoHotKey script can do it.

<comment><USER3> Interesting. I have a Japanese keyboard that has a very short space bar. On either side of the space bar are keys dealing with Japanese input. I've mapped those to tab and I've mapped the tab key to escape. I've really grown used to it and I pretty much can't use a normal keyboard any more.

<comment><USER2> In general the thumb is very under-utilized on the keyboard but also the strongest finger. Any use of the keys beside the spacebar is a win in my mind. Alt is used so infrequently compared to most of the other modifiers.

</comment></comment></comment><comment><USER4> My thumb and pointer finger went numb a year ago. For me, I'm pretty sure that most of the cause was due to problems in my shoulder, and not the hand itself. It's worth noting that strain on your neck and shoulder can cause "pinched nerves" which will result in numbness in your extremities.

Acupuncture, regular breaks away from the computer and exercise fixed my issues.

</comment><comment><AUTHOR> This past weekend on Saturday morning I woke up with a numb right thumb from the finger tip to the first joint. It's a sensation very similar to when your foot falls asleep. The skin feels sort of "dumb" or almost swollen but not entirely without feeling. Like it has been filled with sand.

During the course of the day, it will sometimes shift to a more pin-prick feeling. Touching things - forks, pens, my phone, the keyboard right now - feels really "icky" and sometimes even hurts. And now at times it'll have a hot flash as if it were setting on fire.

I got a wrist brace shipped to me on Tuesday. I've not noticed any perceptible change.

I'm going to see the doctor on Monday. One thing I have learned is to not Google "numb thumb". You wind up on sites offering the worst possible theories, and none of them help your stress level or mood.

I hope this doesn't mean surgery, but I do wonder.

This article hit me hard when I stumbled across it. "At least I'm not alone," was the first thought that hit me.

</comment><comment><USER5> I've always held my phone with one hand, and typed with the index of the other. Granny style.

I doubt the thumb finger evolved to perform high-precision tasks. The index finger did.

Anyway today's huge smartphone screens would force to contort and stretch the thumb in obviously unnatural ways.

</comment><comment><USER6> It's interesting, in a purely personal way, that this article was posted today. I've used computers and other tech daily since childhood and never had issues with wrist/hand/arm/finger pain or numbness. However, over the past few weeks I have been experiencing wrist and forearm pain at night, and today is the first day I've experienced it early in the day. I just purchased some wrist braces on amazon because I've read that they can help. Any other solutions that people recommend for similar issues?

<comment><USER7> Split keyboard, vertical mouse. See [https://news.ycombinator.com/item?id=17888557](https://news.ycombinator.com/item?id=17888557)

<comment><USER8> I've been very happy with MS Sculpt keyboard. It's even relatively inexpensive. I just hope it'd be a normal USB model as I don't really get why a keyboard should ve cordless.

I've also used the later model, MS Surface Ergonomic, and it's one of the worst keyboards I've had the displeasure to use. YMMV.

</comment></comment></comment><comment><USER9> Value and care for your hands. You can have troubles you never see coming.

I developed Emacs-Pinky (though actually from writing a butt-ton of PHP, not using emacs), though I didn't know it had a name at the time. My Hand surgeon couldn't believe I didn't injure myself through a trauma. It's really been a challenge for my career since then. Tried moving to python and it's helped some, but now that I've started down the bad path, Enter keys and everything else are issues.

</comment><comment><USER10> I started to develop similar issues when I moved from the iPhone 5 to the 7 Plus. I sold that and got the 8 the next year, and I started using Popsockets and swapping hands and fingers more frequently, but I still have some numbness and pain in my right thumb joint. I really wish phones had stuck around the iPhone 4/5 screen size - even with fairly large hands, that felt just about perfect.

<comment><USER11> When I got a larger phone for the first time, I noticed it was finally comfortable enough to type with both thumbs in portrait mode. Previously I'd always type one handed. My WPM shot up and strain went down.

</comment></comment><comment><USER12> i have de quervain's tenosynovitis from lifting my 95th+ percentile weight toddler. the difference between the article's author and my experiences are night and day. nobody ever gave me a lecture about tech addiction, despite also having my phone at hand 24/7\. they just told me to suffer through it and try to lift my toddler less when possible. ha. it's common enough that it's often referenced as "mommy thumb".

outside of the lectures and minor lifestyle changes to reduce strain, there are absolutely medical options for treatment, even if your doctor doesn't want to discuss them.

</comment><comment><USER13> I've had large parts of my feet numb for over 7 years and parts of my right hand numb for about 2.5 years. Doctors were never any help.

</comment><comment><USER14> If you must use your phone to do that amount of typing, I wonder if a swipe keyboard would be better.

</comment><comment><USER15> Might as well share my story here in the hopes that it might be of use to someone else. Apologies for the length.

At the start of summer 2016 my phone screen broke, causing the bottom line on the keyboard to go black. This obviously led to a lot of mistakes which led to a lot of backspacing, and all this backspacing was done with my right thumb. It soon became quite sore, so I tried to even things out a bit, but then the same thing happened to my left thumb. I was solo-travelling up the west coast of the US at this point (I think it started/got very bad in Seattle) and when I made it to my friend in Vancouver I think it may have gotten a bit better from not using my phone as much. When I arrived home I sensibly topped it all off by, on my laptop, typing up every single one of my notes from the previous six years.

It then got so bad I would not want to put away the groceries and even holding a book was sore. The doctor was not particularly helpful, she even just literally Googled stuff in front of me and then printed out one of the pages... But she did prescribe some gel to apply on my hands that also didn't seem to have any effect. Your mileage my absolutely vary here though, but I would reckon that a Physiotherapist would be a better bet than a doctor (although you might as well go to both).

I was incredibly worried that I would not be able to complete the final year left in my degree. From sculpting to programming my hands were crucial to my being. So it was obviously quite distressing when they weren't functioning as intended.

Two years on though and I can say things have dramatically improved. While my hands are still not back to their former glory, they are not holding me back in any way. I finished my degree, got a paper into NIPS, and am now working very hard as the first engineer at Inscribe (YC S18) so there's nothing to fear.

Things I've tried that helped:

Minimizing phone usage as much as possible: If it can be done on a computer instead, do it on a computer.

Taking breaks

Minimizing mouse usage as much as possible: mainly done by using Vimium [0] and other keyboard shortcuts, but doing so is only good if you have an...

Ergonomic keyboard: I use the Microsoft Sculpt Ergonomic Keyboard [1] and find that the keyboard is great, but the mouse doesn't really help that much. A Kinesis keyboard might be even better but I have yet to try one.

A spiky yoga ball thing: Mine looks like [2] and is good for massaging my hands or forearms if they get sore.

Running my hands through the hot & cold taps can be nice the odd time for some relief.

There are also some other great suggestions in the comments

Things that I've tried that were probably not necessary/overkill:

Hot & ice water: I used to spend about and hour or two a day alternately soaking my hands in buckets of ice water and hot water. After I stopped I did not really notice any change, except in the rate I got through podcasts.

Avoiding anything using my hands: for a while I avoided the gym and anything using my hands, and this may have been warranted at the worst period, but after that I found that working out seemed to help a little bit, and even it didn't it's unhealthy not to. Deadlifts are very different from texting so I wouldn't worry too much about that.

Things I haven't tried that may help:

A wrist brace

Wristbands

Other points:

Cold definitely makes it worse: I remember one time in particular during my final year project where I had to program a drone outside in the middle of winter on my unergonomic laptop keyboard. Not fun.

This situation has massively heightened my sense for bad ergonomics. And in doing so, completely changed how I look at the design of technology, and a lot of common assumptions of technology in general. While I used to think the Apple keyboard was beautiful I now only consider its form aesthetic, while its function, and the object as a tool, is far from it. I care much less about a lot of the advancements in phones because I want to use mine as little as possible. And the startup trope of an office of people coding on couches, hunched over their laptops is now almost terrifying.

It's also amazing to note the sheer level of addiction a phone can create. Even though it is painful and I know it is, I still find it hard not to flick through stuff in the morning.

If anyone wants to talk more about this, my email is in my bio.

[0] [https://chrome.google.com/webstore/detail/vimium/dbepggeogba...](https://chrome.google.com/webstore/detail/vimium/dbepggeogbaibhgnhhndojpepiihcmeb?hl=en)

[1] [https://www.microsoft.com/accessories/en- us/products/keyboar...](https://www.microsoft.com/accessories/en- us/products/keyboards/sculpt-ergonomic-desktop/l5v-00001)

[2] [https://image.dhgate.com/0x0/f2/albu/g5/M00/DB/D9/rBVaI1lklx...](https://image.dhgate.com/0x0/f2/albu/g5/M00/DB/D9/rBVaI1lklxSAAxycAAIrAaOeVAg243.jpg)

EDIT: Another great way to avoid texting is to send voice messages or even better just call. But obviously these are not always possible.</comment>


Facebook's 'Second' IPO Not Panning Out For Shareholders - <AUTHOR> http://tinycomb.com/2012/05/23/facebooks-second-ipo-not-panning-out-for-shareholders/

<comment><USER2> Yeah I forgot about GS and their $500m... I suppose its not really surprising then</comment>


Writing Network Drivers in Rust [pdf] - <AUTHOR> https://www.net.in.tum.de/fileadmin/bibtex/publications/theses/2018-ixy-rust.pdf <comment><USER2> Per a talk from Joshua Liebow-Feeser at the Rust Belt Rust 2018 conference, Google is heavily using Rust for networking in their new Fuchsia operating system.

This is a rough approximation of a quote he gave during the talk:

"What makes Rust different is not that you can write high-performance, bare- metal code. People use C and C++ to do that all the time. What makes Rust different is that when you write that code, it is safe, clean, and easy to use, and you are confident in its correctness."

If even Google is using Rust for performance-critical development, that seems pretty promising to me.

<comment><USER3> Isn't the networking stack of Fuchsia written in Go?

[https://fuchsia.googlesource.com/garnet/+/master/go/src/nets...](https://fuchsia.googlesource.com/garnet/+/master/go/src/netstack/)

[https://github.com/fuchsia-mirror?language=go](https://github.com/fuchsia- mirror?language=go)

I'm pretty sure Go is the dominant language for networking in Fuchsia and not Rust.

<comment><USER4> Links in the presentation point here: [https://fuchsia.googlesource.com/garnet/+/master/bin/recover...](https://fuchsia.googlesource.com/garnet/+/master/bin/recovery_netstack/core/src/)

</comment></comment></comment><comment><USER5> Having written device drivers before, the first thing I wondered was how he allocated a fixed region of physical memory in user space...

"In kernel space there is an API to allocate DMA memory, in user space we have to use other mechanisms since this API is not available here. To disable swapping, we can use mlock(2). [...] However, mlock(2) only ensures that the page is kept in memory. The kernel is still able to move pages to different physical addresses. To circumvent this problem, we use huge pages with a size of 2 MiB. These pages cannot be migrated yet by the Linux kernel, thus stay resident in physical memory."

He didn't, he's depending on an implementation quirk which might change in the future (and also depending on the physical memory backing huge pages being in a region which can be reached by the network device through DMA, though that's probably always true on x86 when memory encryption is not in use).

<comment><USER6> DPDK also relies on this quirk if there is no IOMMU available. He does mention the IOMMU as future work, but in the context of security.

</comment></comment><comment><USER7> This is very cool. I've been working on using Rust to manage an XDP based network driver that is much, much, much faster than the socket API in C, and slightly faster than DPDK. There's no driver in the traditional sense, Rust works as a control plane and eBPF injector, while the XDP programs communicate back to Rust through eBPF maps.

I'm extremely bullish on Rust, it's such a breath of fresh air to be able to write maintainable, modern code to do low level tasks. I was a C/C++ dev for a little under a decade before switching to Rust and it really delivers on its promises.

Also Rust using llvm is a huge boon to writing eBPF programs.

<comment><USER8> This sounds very interesting, do you have some code (parts) to share?

<comment><USER9> I'm also very interested in any more information regarding this since I'll be doing my thesis work on XDP soon and would like to use Rust!

</comment></comment></comment><comment><USER10> FTA

"Based on our findings we can conclude that Rust is a very well-suited programming language for writing network drivers. It is not only a fast and safe systems programming language but was also voted most beloved programming language in 2016, 2017 and 2018 [15, 16, 17]. Writing more drivers in Rust would certainly lead to safer and more reliable computer systems."

Working link to their code: [https://github.com/ixy- languages/ixy.rs](https://github.com/ixy-languages/ixy.rs)

<comment><USER11> How is "most beloved" a prerequisite to writing network drivers? Don't get me wrong, if Rust is a good technical fit, then that's great, but so convince me on those objective measures.

<comment><USER12> "Most beloved" is a weird way to put it but if it's a way to gauge the state of the language's ecosystem I'd say it's a very practical concern.

For instance these past few days I've been writing a small bootloader for some embedded ARM chip. I pondered going with Rust but ended up using C for two main reasons:

\- I know that if it's doable in Rust it's doable in C but the opposite is not always true (or straightforward). In particular bare-metal/very low level Rust is still somewhat experimental, you can't use stable Rust if you want to be able to use inline ASM or other advanced features. I have very tight constraints regarding code size and memory use and I was concerned that I might not control that as effectively with Rust code than with C.

\- There's already a bunch of C code written for this chip that I can reuse without any friction (no binding generation, no ffi etc...). The vendor even provides a huge header file with the full memory map and some code to init the PLLs.

If you're coding in a vacuum then how "beloved" a language is is mostly irrelevant but if you want to benefit from the ecosystem then having a language that people want to use and support is extremely important. The tooling will mature and stabilize as more and more people use Rust to write bare-metal code and device drivers, which will eventually make my first point above irrelevant. Then if the language becomes popular enough it will be easier to find Rust code or pre-made crates to do what you want which will hopefully eventually solve my 2nd issue.

<comment><USER13> What ARM chip are you considering this for? Is it a Cortex M?

<comment><USER12> No, Cortex A in an Arria10 SoC. The boot process is tedious because you have to load the FPGA before you can access the external RAM so the stage 1 bootloader has to fit 256KB code+data. Currently I'm using a multi-stage U-Boot but for simplicity and robustness I'd like to cram everything in a single stage loader.

Since I can't get u-boot to create a small enough image with all the features that I want (and also because I want to add vendor-specific customizations on top) I decided to try and rewrite a small, single purpose loader from scratch. I considered Rust but then that meant that I'd have to port or rewrite all of u-boot's code I want to reuse (especially the vendor code contributed by Altera mentioned in the previous post). So C it is.

</comment></comment></comment></comment></comment><comment><USER14> I recently wrote my bachelors thesis and I wish it could have been as practical as this. Props for German universities for allowing a software engineering project to be accepted. There is no way I could have gotten away with so little amount of academic references.

<comment><USER15> When I took my bachelors, each semester we split the 27-ish people in our year into groups of about 6 people that had to write a piece of software related to a theme, e.g. compilers or robots, where the courses that semester supported the theme. At the end of the semester we handed in a report of approximately 100 pages detailing the decisions and design and theory behind the practical work we did, which we had to defend orally.

The bachelor project was more of the same, but each group should do a part of a bigger piece of software. I don't recall having any academic references in our final report.

It was a very nice way to learn, as you had your group members to study with and learn from each other.

This was in Denmark, Aalborg University. Which have just been named the best engineering university in Europe, and the fourth best in the world [0].

[0] [https://www.usnews.com/education/best-global- universities/en...](https://www.usnews.com/education/best-global- universities/engineering)

<comment><USER16> Hah, I was reading this thinking "That sounds so much like Aalborg". I'm so incredibly happy I went there :)

Here's another report from MIT from earlier this year, reporting largely the same, placing Aalborg at 3rd or 4th depending on the method used [0].

[0] [http://neet.mit.edu/wp- content/uploads/2018/03/MIT_NEET_Glob...](http://neet.mit.edu/wp- content/uploads/2018/03/MIT_NEET_GlobalStateEngineeringEducation2018.pdf)

</comment></comment></comment><comment><USER17> Related (Writing network drivers in Go):

[https://news.ycombinator.com/item?id=18399389](https://news.ycombinator.com/item?id=18399389)

I'm excited to read both of these.

<comment><USER18> Same university and department :D

<comment><USER17> Yeah I noticed!

Seeing that this is an undergrad thesis makes me feel like I did nothing in undergrad. I'm impressed

<comment><USER19> Maybe I missed something, but all of these network drivers in Go, Rust, C# etc are just re-implementations of the original C driver, where it would seem to me that the real work happened.

That would make the ports still be an interesting experiment, but not as impressive IMO.

<comment><USER20> I think it depends. Writing a non-trivial language port is an interesting way to show off a language. Though it also tends to be an ugly way to show off a language. It depends on the ugliness of implementation for a given language. Early in C# I saw some really ugly implementations of crypto from other languages, for example. Often pretty obvious the person porting didn't understand the new language well.

Some things hard in one language are easy in another, and it usually helps to have a good understanding of both. Just my own POV. However, low level code often requires one to do things "the hard way" for performance reasons. I particularly appreciate what Go, Rust, C# and others bring to the table.

Most of the code I write isn't particularly performance intensive, so I tend to reach for JS in early implementations. Though happy to rewrite if/when performance becomes a concern. I really enjoy articles like this.

</comment></comment></comment></comment></comment><comment><USER21> Since we are looking at PCI Ethernet drivers written in languages other than C (fun!) here is one written in Forth too: [https://github.com/openbios/openfirmware/blob/master/dev/ne2...](https://github.com/openbios/openfirmware/blob/master/dev/ne2000/ne2kpci.fth)

Good to remember that C and Unix kernels haven't always had a monopoly on device drivers.

</comment><comment><USER22> The Rust version of ixy seems to have as many or a bit more lines of code than the C version? That is a bit suprising to me. 1306 for Rust, and '1000' for C. The Rust additionally uses 4 dependencies from crates.io

Unsafe usage is quite small, at 10%, which seems good for a hardware device driver.

<comment><USER23> I'm not sure if this is a critique or a question. If former, then I don't understand why would that matter. Even at 4 times the length of the code, Rust is safer, more robust and better optimized. So why would the length matter?

<comment><USER24> One of Rust's selling points is zero cost abstractions which would normally imply doing more work with less code (as you would expect in a high level language like Python). So it is surprising that it takes that many more lines of code to achieve what C does without those abstractions.

<comment><USER25> "zero cost abstractions" usually means you don't pay a performance penalty for abstractions you do not use.

<comment><USER26> Also means that the abstractions themselves don't introduce unnecessary overhead. It's taken from C++.

 _C++ implementations obey the zero-overhead principle: What you don't use, you don't pay for [Stroustrup, 1994]. And further: What you do use, you couldn't hand code any better. – Stroustrup_

[https://blog.rust-lang.org/2015/05/11/traits.html](https://blog.rust- lang.org/2015/05/11/traits.html)

</comment></comment></comment></comment></comment><comment><USER27> Contrast this with [https://news.ycombinator.com/item?id=18399389](https://news.ycombinator.com/item?id=18399389), both of which are trending.

</comment><comment><USER28> Does anyone happen to have a copy of the LaTeX template that they are using? I really like the typography of the two that are currently on the frontpage.

<comment><USER29> It may be this: [https://github.com/fwalch/tum-thesis- latex](https://github.com/fwalch/tum-thesis-latex)

At least it's linked here: [https://www.in.tum.de/fuer-studierende/bachelor- studiengaeng...](https://www.in.tum.de/fuer-studierende/bachelor- studiengaenge/informatik-games-engineering/abschlussarbeit/)

</comment></comment><comment><USER30> What really would be nice is an extension of what Zinc does, namely encode the IO registers as strongly types entities. Maybe not even encode their usage, but also their usage (r/w/rw).

</comment><comment><USER31> Reading the conclusion in the PDF, the Rust version is not faster than the C version and not necessarily safer either, since there is plenty of "unsafe" Rust code involved.

While Rust is nice in some areas, I'm not convinced this is anything more than yet another "let's rewrite it in Rust, because I happen to like Rust" article.

Angry comments defending Rust incoming in 3..2..

<comment><USER32> > not necessarily safer either

Rust version will not be safer if the authors did 10 times more errors per line than average C programmer.

<comment><USER32> Rust version has 10% of lines marked as `unsafe`. Programmers need to make 10 times more errors per line to introduce the same number of errors that are considered unsafe in Rust (memory corruption, data races, double frees, deallocated memory usage). I'm not sure what's wrong with this statement.

</comment></comment></comment><comment><USER33> I was hopping to see something like that. Thank you!

</comment><comment> OpenBSD-reich Why rust? Didn't Ada and SPARK already pretty much solve the problems rust is tackling? rust feels like the systemd of languages: came out of nowhere and very heavily evangelized.

<comment><USER34> Do those languages have anything even remotely similar to linear types [0]? If not then they aren't even in the same league as Rust.

[0] [https://en.wikipedia.org/wiki/Substructural_type_system](https://en.wikipedia.org/wiki/Substructural_type_system)

These types of comments really irritate me. New thing X comes out that solves an unsolved problem. Then someone comments "why not obsolete thing Y that doesn't solve the problem sufficiently"?

I constantly see comparisons like JVM vs WASM [1], or in this case Ada vs Rust. And very often the newer thing is superior and is not popular just because of cargo culting.

[1] i.e. To obtain similar performance while still using java bytecode you will have to stop using the Java object model completely and exclusively use sun.misc.Unsafe and calculate field offsets of structs manually and still have the risk of vulnerabilities like buffer overflows similar to writing programs in C.

</comment></comment><comment><USER35> Nim produces smaller binaries, has zero-pause, realtime gc (and you can even define gc behavior) and compiles to optimized C. It's a win over Rust in every way including ease of use. Big issue with Nim is tribalism, pure and simple. It's author failed to get any major corporations behind it so it doesn't get hyped up in constant Medium articles and conference talks and therefore does not get a lot of attention, which keeps it a niche language, sadly.

<comment><USER36> [https://nim-lang.org/docs/gc.html](https://nim-lang.org/docs/gc.html)

> Tests show that a 2ms max pause time will be met in almost all cases on > modern CPUs (with the cycle collector disabled).

So in a reduced mode, pause times are only bounded by 2ms. Not sure how you could say that is zero pause

<comment><USER22> Certainly not zero, but probably enough for hitting the frame deadline for 60fps graphics (16ms). Could even enough for real-time audio processing (at 4ms or 8ms). That will cover the vast majority of latency requirements that application developers using an OS deals with.

Some embedded realtime cases might have more strict deadline requirements, or be complicated by the potential jitter that a GC _might_ intoduce. Eg most discrete math used in motor control systems assumes a fixed sample period.

<comment><USER37> I haven't done game dev beyond hobbyist level, but 12.5% of your total budget for a frame seems pretty significant. Is that kind of percentage hit generally considered negligible?

<comment><USER38> 60 FPS is not enough, many people have monitors with much higher refresh rates (120 hz, more). You have virtual reality which basically requires a higher refresh rate than 60 FPS to begin with. Using a runtime component for garbage collection is highly sub-optimal.

Rust is possibly an ideal language for game development. Standard Rust has no runtime component, which is perfect. It's also a high-performance language.

The ecosystem for Rust game development is immature, but there's progress being made.

<comment><USER39> Standard Rust absolutely has runtime components. Otherwise a "Hello World" would not compile into several 100 KiB of binary. (Not saying that that's bad, just that this is how it is.)

<comment><USER32> It has runtime as in "C runtime", that is the code which runs before and after `main` and the code of standard library. It doesn't have runtime as in "Java runtime" (or "C# runtime") that includes the code that runs alongside your code (garbage collection thread).

<comment><USER38> Yes, I was loose in my use of the term "runtime" and sacrificing correctness. Writing "runtime component" rather than "runtime" makes it more misleading. I probably should've worded my original comment more wisely.</comment></comment></comment></comment></comment></comment></comment></comment>


FCC Takes On Apple And AT&T Over Google Voice Rejection - <AUTHOR> http://www.techcrunch.com/2009/07/31/fcc-takes-on-apple-and-att-over-google-voice-rejection/ <comment><USER2> I'm impressed with how quickly the FCC is responding (and that it's responding at all). The questions are thorough and well thought-out too. There's still hope...

<comment><USER3> The head of the FCC is now Julius Genowaski(sp?). He's a Internet tech guy. He's an investor and one of the principals who started the DC incubator LaunchBox Digital. I would assume he's a great proponent for net neutrality issues!

<comment><USER4> In case anyone's still interested, actual spelling is Julius Genachowski.

</comment></comment></comment><comment><USER5> Particularly interesting are the last two questions:

5\. What other applications have been rejected for use on the iPhone and for what reasons? Is there a list of prohibited applications or of categories of applications that is provided to potential vendors/developers? If so, is this posted on the iTunes website or otherwise disclosed to consumers?

6\. What are the standards for considering and approving iPhone applications? What is the approval process for such applications (timing, reasons for rejection, appeal process, etc.)? What is the percentage of applications that are rejected? What are the major reasons for rejecting an application?

<comment><USER6> Yes, this is very good. A clear definition will help most developers not waste resources on executing a great idea only to see it rejected later. The light of day clears up many issues.

[http://www.tuaw.com/2009/07/30/yeah-theres-an-app-for- that-b...](http://www.tuaw.com/2009/07/30/yeah-theres-an-app-for-that-but-for- how-long-and-at-what-cos/)

Not only did Riverturn see its app pulled, it is also responsible for the resulting refund requests... That's just wrong.

</comment></comment><comment><USER7> Quick summary of 47 C.F.R. § 0.459, for those interested in how much will be confidential.

Confidentiality requires a "preponderance of the evidence", as judged by the acting chief (James D. Schlichting). He will base his decision off the following information:

        (1) Identification of the specific information for which
         confidential treatment is sought;

        (2) Identification of the Commission proceeding in which
         the information was submitted or a description of the
         circumstances giving rise to the submission;

        (3) Explanation of the degree to which the information
         is commercial or financial, or contains a trade secret
         or is privileged;

        (4) Explanation of the degree to which the information
         concerns a service that is subject to competition;

        (5) Explanation of how disclosure of the information
         could result in substantial competitive harm;

        (6) Identification of any measures taken by the
         submitting party to prevent unauthorized disclosure;

        (7) Identification of whether the information is
         available to the public and the extent of any previous
         disclosure of the information to third parties;

        (8) Justification of the period during which the
         submitting party asserts that material should not be
         available for public disclosure; and

        (9) Any other information that the party seeking
         confidential treatment believes may be useful in
         assessing whether its request for confidentiality
         should be granted.

Because this information was requested by the FCC, Apple/AT&T/Google can't withdraw the information if the confidentiality request is denied. They can apply, however, for a judicial stay.

</comment><comment><USER8> I know that this is probably not very comme il fait to say on HN, but really, I don't see what all the righteous indignation at AT&T / Apple is about.

You signed up for a highly proprietary and controlled walled garden when you got an iPhone. I did too. When you ran into some limitations you didn't like, you jailbroke it and loaded some things Apple and/or AT&T didn't want you to load.

If you don't like this whole paradigm, why get an iPhone? Why not get an Android or something else? For that matter, why does Google bother releasing an iPhone app; why not build the Android into a handset that is tightly coupled/integrated with Google Voice? Seems like that would be a fine marketing coup for the former.

I'm just not sure what there is to whine about here. Of _course_ enhanced voice application services aren't going to be allowed on the phone because they are perceived as encroaching on possible or actual carrier revenue streams. Of _course_ you can't put applications on it that make a "dumb pipe" of the carrier's data network in order to deliver voice. If you don't like this set of circumstances, pursue a solution by competitive means, not legislating it; vote with your feet and quit buying iPhones until the exclusive distribution contract with AT&T expires, and thusly encourage Apple to diversify its retail blend to include other network operators with more liberal approaches.

Really - what, do you expect that a de facto contractually sanctioned monopoly (AT&T) is going to act in the spirit of the public welfare or consumer choice when it perceives a conflict of interest? Seriously?

Neither the courts nor the FCC should be looking at this. Consumers just need to take their wallet elsewhere.

EDIT: I very much concur with the poster above who speculated that AT&T's 3G network doesn't have the bandwidth to handle a large amount of relatively constant (at a certain baseline) voice traffic generated by something as popular as GV. Anybody who deals with mobile issues routinely can tell you that AT&T's 3G network is positively the worst in the land, and oversubscription in many MSAs is unbearably high. You want 3G bandwidth, go with Sprint, or maybe T-Mobile.

<comment><USER9> About your edit footnote, what do you mean by GV voice traffic? GV is not a VOIP solution, it calls your phone which uses your subscription minutes. Usage might increase a bit because international rates are lower, but I fail to see how that could overload AT&T's bandwidth.

<comment><USER8> I was under the impression that the GV client also provides some degree of VoIP client functionality.

It would be hard to see what is controversial about this proposal if that weren't present. What, is AT&T complaining about more subscription minutes being used?

<comment><USER10> AT&T is freaked the fuck out because your Google Voice number is _actually portable_ to any carrier, completely dynamically, in perpetuity.

Number portability in the US as it is now only works if your new billing address is in the same zip code as your old number, and usually doesn't work at all when you're trying to port _out_ of a VoIP provider or _in_ to a PoTS line.

<comment><USER11> Really? I ported an Atlanta number from T-Mobile to Sprint without a single problem here in Seattle. They did ask me for an Atlanta zip code during the process, but it never came up as an issue.

<comment><USER12> Phone number portability (one carrier to another) is mandated by law. They gave you no problems because they mustn't. GV style portability (a virtual number that works with any carrier) enjoys no such privilege, so they can, and in Apple/AT&T's case, have, blocked it.

<comment><USER8> It's not "a virtual number that works with any carrier." I can assure you that the number is (1) natively homed or (2) ported - to a particular physical, facilities-based carrier (generally a CLEC) at any time. In a lot of places, Google Voice is using bandwidth.com's new CLEC license holdings (after they stopped being a pure Level3 reseller), and probably the usual national-level multibillion dollar folks that are interconnected to everyone, everywhere and have a lot of direct end-office trunking: Global Crossing, XO, Level3, etc.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> Wow, how great is this? And by reading the questions, it actually seems like there is someone in a government organization that a) knows what they are talking about and b) isn't scared to write in an unequivocal way From a person that usually follows wall street matters, this type of letter is a shot out of the blue. Wall street "enforcement" letters have so many loopholes any reasonably intelligent person could drive a mack truck through them, the wording of this sounds like someone in the government screwed up and accidentally hired someone that has competence, and gives a sh*t. What a breath of fresh air in America.

</comment><comment><USER14> This can't end well. At the end of the day, Apple and AT&T have the right (or _should_ have the right) to make any agreements they find necessary, and customers obviously have the power to reject the iPhone and AT&T if this matters enough to them. The government gets involved when consumers want to have their cake and eat it too -- you want the iPhone Apple & AT&T are offering BUT you aren't willing to accept their price and terms.

I know this isn't going to be a terribly popular point here, because, well, we all do want to get _our_ way. But just consider how much you'd like to find yourself on the receiving end of one of these letters.

<comment><USER5> Not true. AT&T does not own the spectrum they use, it is a publicly owned natural resource, licensed to them under specific rules, and can be revoked by the FCC for failing to comply with the regulations.

The government is not getting involved because people want to have their cake and eat it to, (although that is a pretty good default assumption), but because there appears to be collusion involving regulated resources.

<comment><USER14> You are being over-broad with the scary word _collusion._ Collusion would be AT&T, Sprint, T-Mobile, Verizon, etc. agreeing to keep voice revenues for the industry high by crippling mobile data. Nothing in a carrier's agreement with a handset vendor could possibly qualify for _collusion._

As for violating regulations, please find for me the regulation that they have violated. It seems to me that their present sin consists of doing something _unpopular._

<comment><USER15> This is a valid point, but I'm not convinced that it's OK for companies to act/co-operate in a way that is this detrimental to their customers just because they aren't supposed to be competitors. Based on the questions asked, the FCC seems to be trying to find out if this exclusivity agreement is harming consumers or not, which seems like a decent goal. If this inquiry leads to some transparency from Apple/AT&T, so much the better, right?

<comment><USER16> No! You can't think like that.

Apple and AT&T should have every right to be as opaque as they want. If you don't support their policies and pricing, switch to another carrier and buy another phone.

In a completely non-monopolistic scenario, which this is, the government should have no concern whether a company's action's harm customers or not, since the customer has complete choice in whether to buy the service or not.

This is precisely a situation in which the customer wants to have his cake and eat it too. Regulated resources are by definition a case when the customer wants to have his cake and eat it too.

<comment><USER17> Oh, for fuck's sake.

The FCC said _why_ they wanted this information. They wanted this information as part of its examination of net neutrality and exclusive phones. The FCC doesn't even look at collusion and antitrust - the FTC does.

The idea that there's some monolithic "government" is juvenile at best.

<comment><USER18> _The idea that there's some monolithic "government" is juvenile at best._

Thank you. It should, however, be noted that as Goldman Sachs rehires, the government will get bigger. Oh wait, I forgot that I'm not Matt Taibbi, so scratch that last sentence.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> And in the wsj: <http://online.wsj.com/article/SB124908121794098073.html>

</comment><comment><USER20> This is gonna be good.

</comment><comment><USER21> I'm curious what jurisdiction the FCC has over Apple (other than clearing the devices for interference). AT & T I can understand. Anybody know?

<comment><USER22> Apple is manufacturing and selling telecommunications devices. That being the case, the FCC's purview extends well beyond simply clearing the devices for interference. That's the standard a device is held to if it _may_ emit EM radiation, but that emission is not meant for communications purposes, AIUI. The bar is set rather higher, and the FCC's powers rather deeper, if the EM spectrum the devices emit on is actually meant to be used for communicative purposes -- particularly if it uses a licensed band.

Disclaimer: IANAFCCW (I am not an FCC wonk.)

<comment><USER23> Is this a fair shortening of your comment:

Because Apple sells devices that use the public airwaves, they are subject to regulation, and the agency in charge of that is the FCC?

</comment></comment></comment><comment><USER24> Is this likely to cause any change of course? Does the FCC's inquiry have enough weight to spur a different stance on the issue?

<comment><USER25> Just an inquiry no... I think most of us are hoping that it's the beginning of something larger and that Apple/AT&T will be forced to compromise.

EDIT: typo

</comment></comment><comment><USER3> Anyone think a lot of apps are rejected due to AT&T network not being able to handle bandwidth intensive or highly popular apps?

The network is not able to handle the load now and if they allowed Skype, Sling and others it probably be even worse. Though if iPhone was not exclusive to them, a lot of their problems would be solved!

<comment><USER26> This is an argument that can fly with Skype and Sling, but not with Google Voice. When you make a call on Google Voice, you're still using your regular AT&T minutes (in other words, it's not going over the data connection).

<comment><USER3> Sure that's why I said apps that are bandwidth intensive or highly popular.

Although just recently released GV if released on the iPhone would become a staple app; free SMS. Thus, with everyone using it would put a further strain on AT&T's already drained network, as well cut into PROFITS. So, it could possibly be both.

</comment></comment></comment><comment><USER27> It was inevitable that the feds will step in. If MS would have controlled any software running on Windows then how good would have Windows be? But that would have never fly!

Same here once you release a software product that carries an API you policing it can result in an unwanted results!</comment>


Ask HN: Facebook no longer seems to allow birth date change - <AUTHOR>

I used to shuffle around my birth date on Facebook, but it seems it is now locked down.<p>Is there a way to edit it? <comment><USER2> It appears you can still edit it using the mobile interface: [http://m.facebook.com/editprofile.php?edit=birthday&type...](http://m.facebook.com/editprofile.php?edit=birthday&type=basic)

(I don't want to test if the change actually goes through, sorry.)

<comment><USER3> Just tested, change goes through.

</comment></comment><comment><USER4> Generally sites lock down info that can be used to help users reset passwords when they forget them. Also, birth dates are used to help ensure compliance with child-protection laws. You can't change your birthdate on Yahoo either.

(I work for FB, but not on this part)

</comment><comment><USER5> It has been that way for quite a while. Lucky for me I didn't enter the correct date when I signed up, and I keep it hidden so my friends don't start wishing me HB on the wrong day.

<comment><USER6> I had a problem where a few real friends wished me HB on or around the correct date. Another example of friends revealing your information. ;-)

Seriously, though, there is a problem with friends not understanding the medium and privacy concerns. If someone does not display their birth date, it may be a clue they don't want it communicated in that medium.</comment></comment>


Developers shouldn't distribute their own software - <AUTHOR> https://drewdevault.com/2019/12/09/Developers-shouldnt-distribute.html <comment><USER2> I am mostly in agreement with this article; releasing a tarball is a necessary and sufficient mechanism for distributing your software. If it is valuable enough, maintainers can use that tarball to package it. I strongly believe that my software isn't somehow "more special" than anybody elses'; users shouln't have to install my software any differently than others', or expect a different release cadence.

For those unfamiliar with the packaging process, check out Fedora's `.spec` file to generate the RPM for rsync [0]. It contains instructions for downloading the tarball, installing dependencies from Fedora's repositories, build commands, and metadata. Tarballs can also be used to generate Flatpaks in much the same way; see the manifest file for qBittorrent [1] for an example.

It is okay to distribute your own software, but only for development. End- users should not be expected to get your software from npm, PyPI, etc. when distro packages exist.

That being said, it is possible for developers to optionally go above and beyond by:

\- setting up repositories for the latest stable release or prerelease, for those interested

\- Providing their own binaries/artifacts (if applicable) for anybody who wants to test software out before installing.

These are not replacements for distributing a tarball that can be used for packaging; they are optional additional steps.

[0]: [https://src.fedoraproject.org/rpms/rsync/blob/master/f/rsync...](https://src.fedoraproject.org/rpms/rsync/blob/master/f/rsync.spec)

[1]: [https://github.com/flathub/org.qbittorrent.qBittorrent/blob/...](https://github.com/flathub/org.qbittorrent.qBittorrent/blob/master/org.qbittorrent.qBittorrent.yaml)</comment>


Ask HN: What are the best practises for using SSH keys? - <AUTHOR> Following the recent post about upgrading SSH keys to ED25519, I am wondering what the best practises (regarding security) for using SSH keys are.
For example:
- Is it better to use a different passphrase on each key, or does using the same one not matter much?
- How much less secure is it to not use a passphrase on a key?
- Should you use a different key per user account, per server, or per use-case (i.e. personal or work)?
- Does increasing the amount of bits in a key really have an effect on the security of the key, or does it not make much difference in a real-world use?
- How/Where should private keys be stored on a device using them?
- What are some of the pros and cons from a security standpoint, and how may doing different things affect the usability of a key? <comment><USER3> From my experince as an attacker --

       - Is it better to use a different passphrase on each key, or does using the same one not matter much?
       - How much less secure is it to not use a passphrase on a key?
       - Should you use a different key per user account, per server, or per use-case (i.e. personal or work)?

None of these things really matter that much. Make sure you use full disk encryption and never stand up from your machine without locking it, and make sure you keep your local machine patched. If I get code execution on your machine, I am going to use whatever keys are loaded in your ssh-agent to pivot, hijack your existing open sessions, or modify your ssh client to dump the keys I need.

       - Does increasing the amount of bits in a key really have an effect on the security of the key, or does it not make much difference in a real-world use?

Key length is a protection against the future, and against state level actors. Right now, key length doesn't matter much to me because I'm more focused on just stealing your keys from you regardless of length.

<comment><USER4> Nobody seemed to answer this question, and neither did the original blog post (besides "trust me and do it"), so maybe you can shed more light on the main point:

Why are ED25519 keys better than RSA, how compatible are they with different systems, and are they worth the hassle and risk of generating and using a new one?

<comment><USER5> > Why are ED25519 keys better than RSA

Two reasons: 1) they are a lot shorter for the same level of security and 2) any random number can be an Ed25519 key. To generate an RSA you have to generate two large random primes, and the code that does this is complicated an so can more easily be (and in the past has been) compromised to generate weak keys.

<comment><USER4> If I understood it correctly, you're saying that RSA requires the two numbers to be big AND random, otherwise the algorithm isn't strong? Therefore Ed25519 is better because it's strong regardless of the key?

What I don't get then is how can a short key be secure, that goes against what I was taught in college. Aren't shorter keys more prone to collisions and bruteforce attacks?

<comment><USER6> _Aren 't shorter keys more prone to collisions and bruteforce attacks?_

Given the same cipher, more or less, yes. Between ciphers, though, key-lengths are less relevant, and the differences in those ciphers become more so.

EDIT: Think of it in terms of Shannon Entropy: because RSA requires a pair of primes, the keyspace is so much sparser — that is to say, more "predictable" (if, granted, at a mostly theoretical level) — so keys need to be that much larger to be secure.

Contrarily, with ED25519, keys can be smaller, because the keyspace is denser.

(Or am I just talking out my ass here?)

EDIT 2: s/smaller/sparser/, s/bigger/denser/, regarding keyspaces. Thanks, 'lisper!

<comment><USER5> Not bigger -- denser.

<comment><USER4> Great replies, I got it now, it makes sense. Thanks to both of you!

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I consider best practice to be using a hardware token.

My favoured solution is to use a yubikey via gpg: with this method you use your gpg subkey _as_ an ssh key. The yubikey 4 supports RSA 4096 bit keys, if you need NFC then the Yubikey Neo supports max RSA 2048 bit keys.

<comment><USER8> This. It's so cheap and easy to use a hardware token for your GPG and SSH keys nowadays (YubiKey 4! TPM! Smartcards!). If you're not using one, you should.

<comment><USER9> Do you have a list of guides you recommend for getting started with YubiKey?

<comment><USER10> I found this guide to be pretty comprehensive: [https://www.esev.com/blog/post/2015-01-pgp-ssh-key-on- yubike...](https://www.esev.com/blog/post/2015-01-pgp-ssh-key-on-yubikey-neo/)

</comment></comment></comment></comment><comment><USER11> The first rule: never share a private keys between physical devices. Apart from reducing the opportunities for it to go walkies in transit, or accidentally get left on a USB stick, it allows you to revoke a single credential if you lose (control over) that device.

From that, we get:

      - you're not sharing passphrases between keys, you're
      sharing them between devices, and whether that's safe
       depends how likely it is that a compromised passphrase
      on one device can be transferred by an attacker to another.
      - Similarly, whether a blank passphrase is a good idea or
       not depends on what other measures are protecting access
      to that private key.
      - If a private key ever turns up on the wrong machine,
      you *know* the key and both source and destination
      machines have been compromised.

<comment><USER12> If I understand this properly, how do you use the same identity from two different machines on a service like github?

If they only allow you to upload one public key per account, then you aren't able to use that account on both your desktop and laptop, if you have separate private keys on them, no?

Edit: Actually I just looked at github and they allow multiple keys. Is it generally the case that any service that offers ssh keys will allow multiple keys?

<comment><USER11> There's no reason not to. The `authorized_keys` file on a host does exactly that. Whether a specific service does the same is down to that service.

<comment><USER12> How do you revoke the keys when a machine a compromised? Log in to each service and remove it when you become aware?

</comment></comment></comment></comment><comment><USER13> If you have a lot of machines, SSH certificates are supported in OpenSSH 5.6+ and are awesome: [https://www.digitalocean.com/community/tutorials/how-to- crea...](https://www.digitalocean.com/community/tutorials/how-to-create-an- ssh-ca-to-validate-hosts-and-clients-with-ubuntu). They allow for centralized management of authentication/authorization without having to touch each machine (beyond an initial trust relationship setup).

<comment><USER14> Additionally there is a fork of OpenSSH called PKIXSSH that supports X.509 certificates in addition to keys and OpenSSH certificates. This is useful for using the same credential (certificate) to authenticate using other protocols such as TLS (via TLS client certificate) and Kerberos (via PKINIT).

It supports OCSP responders as well as CRLs.

It can allow or deny access based on X.509v3 extensions.

Using this and a hardware token with an X.509 certificate you can completely eliminate passwords for most cases and have no ability to leak your keying material (barring HSM vulnerability).

Android and iOS devices have historically had little support for smartcards so that's a downside of you use those devices. There's a smartcard framework in Android but I've not used it since 4.x and it was not useful.

Support on ChromeOS, Linux, Windows, Mac OS X, Solaris, and *BSD has been a lot more reliable.

Also, this is a fairly common usage scenario thanks to HSPD-12 and the tens of millions of affected PKI users.

</comment></comment><comment><USER15> This is probably the wrong forum, but I have a question or two that I see as related.

I have setup a VPS, disabled passwords, and setup a key with a passphrase to gain access. At this point my greatest worry is losing this private key, as that means I can't access the server.

What is a reasonable way to backup my private key?

Encode it as something similar to a QR-code, print it, and store it in a hole in the wall? Copy it to an USB-stick and hide that somewhere safe?

Alternatively, I have access to more than one computer, so I could also authorize a couple of other keys to access the server. So I would transfer the public key to the authorized machine, and add them to the authorizedkeys from there?

How to deal with the possibility of death? Do I trust someone with my keys and passphrases?

<comment><USER16> For backing up your keys, they can be encrypted to a device with full disk encryption, or to a mountable disk image that's encrypted, and then push that file off site.

As for access if you lose a key, unless you somehow run a VPS that also uses full-disk encryption (and requires a passphrase on boot), then your hosting provider has access to your VPS.

For instance, with DO or Linode, you can log in to the admin console and reset the root password of a server. Once done, you can use the terminal built into the admin panel to access to the server even if SSH is disabled.

Presumably, someone could work with the provider, prove you are dead, and that they should gain access to your servers. At that point it would come down to the policy of the hosting provider.

<comment><USER17> An account that can only login on the local ptys is a good enough backup plan.

The disk encryption doesn't buy you much in such an environment, though... Even with whole disk encryption if you're running virtualized; then your provider can just read your VM's memory anyway...

Unless your VPS is going to be forever shutdown, disk encryption under a hypervisor you don't control seems reasonably pointless -- I only use it for physical security to stop people being able to use disks they yank from physical boxes -- even then if they were motivated enough they could probably grab the memory from the server(s) and get the keys anyhow...

AFAIK, there is no possible protection from this besides running your own gear. There were recently published attacks where someone managed to pull keys from other machines by abusing some either intel or vmware's memory dedupe tech bugs iirc (don't have the link handy) -- so; it's not even limited to what your provider may be doing...

</comment></comment></comment><comment><USER18> If you use fail2ban make sure to pin the right key to the right host. Otherwise ssh will try all the keys and get you banned from your own host. The easiest way is to use the ~/.ssh/config:

        Host myhost
          IdentityFile ~/.ssh/myhost

<comment><USER19> Good advise. This happenned to me. By luck I had another account I could use to recover. I wish I could disable that feature. I use config now but the default should not be to try every key in ssh directory.

<comment><USER20> Agreed. That seems like a weakness in OpenSSH. One should have to turn on a "try all keys" option to get that behaviour ..

<comment><USER21> Yeah, it's on by default. See _IdentitiesOnly_ to turn it off.

</comment></comment></comment></comment><comment><USER22> The classical document about this:

[http://lackof.org/taggart/hacking/ssh/](http://lackof.org/taggart/hacking/ssh/)

</comment><comment><USER23> > \- How much less secure is it to not use a passphrase on a key?

This is a question of layers. If you don't have a passphrase on your key, what stops someone from gaining access to it? Just your account password? If they steal your device, is there some form of storage encryption involved?

> \- Should you use a different key per user account, per server, or per use- > case (i.e. personal or work)?

I have different keys for different purposes per client device. This is mostly because sometimes I need to login to places that are ancient enough I need to use a weaker key than I would like to use in other places or vice-versa, there's places I can only login with ed25519 keys.

Though having different keys per purpose isn't necessary it allows me to keep certain identities separate. I have a different one for GitHub for example, mainly because GitHub exposes my public key and therefor allows for clever tricks like tying the key to an established identity should I use that key to authenticate in other places.

I would also recommend configuring SSH so that it doesn't send over any/all keys by default. Take a look at the IdentitiesOnly option in ssh_config.

</comment><comment><USER24> \- Is it better to use a different passphrase on each key, or does using the same one not matter much?

Yep in an ideal world, though I suspect in practice it doesn't matter much.

\- How much less secure is it to not use a passphrase on a key?

You are relying completely on the security of your disk, against either physical or cyber. Use a passphrase, use an agent to manage it.

\- Should you use a different key per user account, per server, or per use- case (i.e. personal or work)?

Per client device. This is the device that can be compromised and cause invalidation to be required, so this is the one which should be seperate. For convenience you can maintain all your devices public keys concatenated together and hand them out like that - comment each with hostname and date created for ease of identification.

\- Does increasing the amount of bits in a key really have an effect on the security of the key, or does it not make much difference in a real-world use?

Up to a point. RSA in 8 bits is trivial. Go for a highish key length, different key types have different recommended lengths. Note some machines dont support higher lengths.

\- How/Where should private keys be stored on a device using them?

In $home/.ssh

Permissions should be set for only you to read with no writing. Even better if your home drive is encrypted as it is only vulnerable whilst you are logged in.

\- What are some of the pros and cons from a security standpoint, and how may doing different things affect the usability of a key?

If you hop machines a lot key per client can be problematic. In this case a portable secure drive is useful. Of course one leak can be fatal here.

Try not to fall back on passwords, they have nothing like the same security.

Most usability issues are caused by the people running the servers not reacting in a timely fashion to key updates.

<comment><USER25> If necessary, it's possible to fall back to password plus OTP.

That's a reasonable compromise, since you carry the OTP generator around with you.

</comment></comment><comment><USER26> Some general advice based on most requirements.

\- Is it better to use a different passphrase on each key, or does using the same one not matter much?

If they are being used on different device then different passphrases makes sense otherwise no.

\- How much less secure is it to not use a passphrase on a key?

10? Not sure you can really quantify an answer. I'd recommend a passphrase if you aren't already using disk encryption with that it's probably less of a concern however with agents there's not much issue with not having one.

\- Should you use a different key per user account, per server, or per use- case (i.e. personal or work)?

Use a different key per client device but you don't need a different key for logging into different servers unless you care about people correlating those users.

\- Does increasing the amount of bits in a key really have an effect on the security of the key, or does it not make much difference in a real-world use?

Use more than 2048bit for RSA/DSA beyond that it doesn't matter.

\- How/Where should private keys be stored on a device using them?

~/.ssh on some local filesystem.

<comment><USER27> Don't use DSA

</comment></comment><comment><USER28> > \- Is it better to use a different passphrase on each key, or does using the > same one not matter much?

It is better to use a different passphrase for each key but it is also less convenient unless you're using a password manager (personally, I'm using KeePass)

> \- How much less secure is it to not use a passphrase on a key?

That depends on the security of the computer where the keys are. I remember a Firefox vulnerability where one site exploiting it was looking for ssh keys on the local file system. So I'd say that a passphrase is very important.

> \- Should you use a different key per user account, per server, or per use- > case (i.e. personal or work)?

Personally I'm using a key per account per host.

> \- Does increasing the amount of bits in a key really have an effect on the > security of the key, or does it not make much difference in a real-world > use?

Yes up until 2048 where the returns of increasing the amount of bits will start diminishing.[1]

      [1]: https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096

<comment><USER26> > It is better to use a different passphrase for each key but it is also less > convenient unless you're using a password manager (personally, I'm using > KeePass)

If you are going to use a password manager to store them there's no point in using different passphrases.

<comment><USER23> Why not? Granted the passphrase are in one place but as long as your password store doesn't get compromised managing to brute force a key's password then only gives you access to the machine(s) that one key is accepted on.

Also, the keys don't have to reside on the same device the password store is on. If you have one key per client device for example.

<comment><USER29> Because if your password manager is compromised, so are all of the passphrases stored in it. So what would the point, then, be of using different ones?

<comment><USER30> So because a password manager is one-stop shopping (something that I'm subconsciously uneasy about, to be sure), it's pointless to use different passphrases, one of the major selling points of password managers.

So to protect against that, don't use a password manager. Which means that you're more likely to re-use passphrases, because lots of them are hard to remember and keep straight. So breaking one gets access to many others.

My head spins.

<comment><USER31> I was originally going to post something along these lines, but then I realized that this argument doesn't work the same in this particular context, and the parent isn't necessarily arguing against password stores in general. Sure, it might be better (in the sense of not concentrating your risk to a single file) to have a strong (importantly, private) scheme for creating passwords (say, based on the site and account name). But if you're restricted to some inane restrictions ("6-10 alphanumeric characters"), then there's not really a strong argument against a password manager in this case.

Sure, in general, you want to avoid password reuse to isolate password compromises / security breaches (some companies are still storing passwords in plaintext in 2016, ugh). But in this case, we're talking about private keys that should never leave your local machine. If those are compromised (even passphrase-protected), then it's not inconceivable to think that your password store might also be compromised.

<comment><USER30> > he parent isn't necessarily arguing against password stores in general.

Yeah, reliazed that, my post was just my "logical" progression.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> > How much less secure is it to not use a passphrase on a key?

It's better to think about specific attack scenarios. If your keys get exfiltrated because of some local exploit (like a browser vulnerability, a malware download or physical access) then the attacker has access to your servers.

<comment><USER32> the same holds for keys with passphrases; the attacking process just has to wait until you enter it.

<comment><USER33> As I mentioned in my other comment: stealing local files does not necessarily have to happen via unrestricted-RCE (which would allow you access to the ssh agent)

<comment><USER34> This, for instance.

[http://m.theregister.co.uk/2013/01/25/github_ssh_key_snafu/](http://m.theregister.co.uk/2013/01/25/github_ssh_key_snafu/)

</comment></comment></comment></comment><comment><USER35> It depends heavily on your threat model. Just about any key is an improvement over using passwords to authenticate. If you want protection from state-level actors, you need to be really careful and consistent.

Regarding key types:

\- DSA keys (ssh-dss) suffer from several issues (fewer bits, bad RNGs in Debian, other issues), and modern versions of OpenSSH deprecate it.

\- RSA is pretty standard, and generally speaking is fairly secure for key lengths >=2048. RSA-2048 is the default for ssh-keygen, and is compatible with just about everything.

\- ECDSA is largely considered compromised because the constants NIST chose for the cryptosystem weren't well documented how they got them, and the assumption is that the NSA chose them to provide a "backdoor" (so it would provide the same security for a general attacker, but significantly easier for them). This was confirmed as being theoretically possible, and there is of course concern that the NSA could potentially leak those constants, instantly breaking the security of this cryptosystem.

\- ED25519 is more or less the same as ECDSA, but was put together by DJB. The big advantage here is speed. EC crypto is much faster to sign, slightly slower to verify, and equivalent security can be achieved with fewer key bits.

\- Notes for the future: both RSA and ED25519 become insecure against quantum computing (integer factorization and discrete log are both in BQP).

Generally, use RSA if you work with older servers that only support it, or ED25519 if you like shiny things. Otherwise it's a bit of a tossup.

Regarding using separate keys:

\- I follow the philosophy that a private key should _never_ leave the host it was generated on. If you aren't sharing keys between machines, you remove the risk that you'll accidentally share it publicly.

\- Beyond that, I'd recommend at a minimum having separate work/personal keys. Keeping separate keys for each user/host you want to log into is a tad excessive, but can be useful for key revocation/rotation.

Regarding passphrases on keys:

\- _Yes_. FDE is sometimes trivial to bypass, and you want to be protected in case someone sets your ~/.ssh folder to be synced to dropbox/samba/etc. You can use an agent to keep the decrypted keys in memory, but I'd avoid using agent forwarding.

Regarding bastion hosts:

\- You didn't ask about this, but it is essential for a "best practice" setup.

\- Bastion hosts are small VPS hosts that basically run sshd and have a static IP. You disallow any ssh traffic except from your bastion hosts to your servers.

\- You'll want to have at least 2 bastion hosts with different hosting services, in case one isn't available.

\- Run sshd on your bastion host on a port other than 22. Not for security, but for reducing log volume.

\- Run fail2ban on your bastion host, even if you've disabled password authn. Again, not for security, but for reducing log volume.

\- Set up fail2ban to alert when a new IP successfully logs in.

Other stuff:

\- SSH can use certificates for authentication, and this can make the key distribution problem much easier to solve. I have a script that makes this easier.

\- Push for everyone in your organization to use SSH keys, and only SSH keys.

\- Defense in depth. All it takes is skipping one step and you expose yourself. Assume that something that was exposed has been compromised. An attacker only needs to succeed once.

tl;dr - the defaults are fine and password protect your keys.

</comment><comment><USER36> From a pragmatic end-user perspective.

1) Disable passwords and only allow keys even for root with PermitRootLogin without-password

2) public-key authentication has somewhat unexpected side effect of preventing MITM per this security consulting firm [http://www.gremwell.com/ssh-mitm- public-key-authentication](http://www.gremwell.com/ssh-mitm-public-key- authentication)

</comment><comment><USER37> I upgraded to ed209 the other day as well.

Two questions came up, how many iterations to use via "-a ", and should I add the private key to my home folder repo in version control? I don't want to lose it in a disk crash, but don't want to give it to bithub either.

</comment><comment><USER38> > Is it better to use a different passphrase on each key, or does using the > same one not matter much?

Using a passphrase is _highly_ recommended except for server-to-server accounts, which should be locked down (and specify the specific command that server can execute in the authorized_keys file - Userify[1] supports this).

You should _definitely_ use a different passphrase for keys stored on separate computers, and it's not a bad idea to use a different passphrase for separate keys stored on the same computer, especially if they have different servers they can access. However, practically speaking, if your computer was compromised (ie keylogger etc) then it's game over anyway.

> Does increasing the amount of bits in a key really have an effect on the > security of the key, or does it not make much difference in a real-world > use?

Yes, it does make a difference, depending on what you mean by "real-world". Anyone less than a state-level actor will probably be unable to cost- effectively attack even a 1024 bit key, but that won't be true for long. We suggest 2048 bit keys if you are using RSA, with 4096 if you prefer extra security and don't mind slight latency during a connection, or ED25519 for keys on systems that support it. Generally the defaults are pretty good. We have a HOWTO for different OS's here: [https://userify.com/docs/generating- ssh-keys-on-ec2/](https://userify.com/docs/generating-ssh-keys-on-ec2/)

> How much less secure is it to not use a passphrase on a key?

From the server's perspective, it's EXACTLY the same, but from the client (your laptop's) side, it's completely different. While it's possible that your laptop could still contain your decrypted key in its key manager's RAM or suspended state (ie unencrypted swap file etc), the use of a passphrase even on (actually, ESPECIALLY on) a non-full-disk encrypted system will raise the level of effort to access your key to near-impossibility levels, especially from non-state actors, whereas a key that has NO passphrase is a piece of cake. Use a passphrase EVEN WITH full disk encryption (for example, the evil maid attack)

> Should you use a different key per user account, per server, or per use-case > (i.e. personal or work)?

If you're using a different key and storing them on different computers, you should probably use a different passphrase on each key. The passphrase (or even if one exists) is not visible to remote servers (or Userify[1] - <USER2> provide a free-text field that becomes your authorized_keys on remote servers.)

You don't need to use a different key per user account, although you can. You also should not use a different key per server.. that will turn into a management nightmare. It's perfectly ok to use one key everywhere, but you should probably use a different key on your laptop and desktop, or if the keys have different levels of access (Userify[1] can automate that for you too).

> How/Where should private keys be stored on a device using them?

Ideally on a device using full-disk encryption, including swap and laptop suspend space, to prevent access to a decrypted key in RAM (you are using a passphrase, right?). However, FDE does not protect you from other compromises on your system (i.e., another user that gains escalation to root and installs a key logger), and does not protect against a compromise of your BIOS (i.e., Intel UEFI) or boot process (evil maid attack again).

> What are some of the pros and cons from a security standpoint, and how may > doing different things affect the usability of a key?

Keys are safer than certificates because there are less moving parts and no outside requirements for your internal CA or dependency on a CA that might go down. Keys can be a management nightmare at scale, but there is software to manage them (ie Userify[1], ManageEngine[2], BeyondTrust[3], ssh universal key manager[4], keybox[5] (free/open source), etc). If you are doing a small project with few team members, you can also do management with Chef, Puppet, etc, or just by hand.

In terms of usability, a real key solution that manages keys across entire groups of servers with a few clicks can be really helpful... you can do all of the regular SSH things like tunneling (replace stun/sslwrap, etc), proxying all of your other traffic (SOCKS5), keep SSH connection alive (autossh etc), smart ban based on failed attempts (fail2ban, deny hosts), forward encrypted X11 or VNC connections, forward SSH itself (tunnel SSH within itself), and so much more.

We're going to start blogging about all the awesome things you can do with SSH soon, since it's really an amazing and deep protocol.

1\. Userify [https://userify.com](https://userify.com) Free cloud and on- premises versions available; full disclosure: I work there

2\. ManageEngine: [https://www.manageengine.com/](https://www.manageengine.com/)

3\. BeyondTrust: [https://www.beyondtrust.com/](https://www.beyondtrust.com/)

4\. SSH Universal Key Manager: [http://www.ssh.com/](http://www.ssh.com/) (no TLS?)

5\. Keybox [http://sshkeybox.com/](http://sshkeybox.com/)

</comment><comment><USER39> If you use multiple identities, and want to reduce the odds of accidentally using the wrong one, then having different passwords is a good idea.

</comment><comment><USER40> I would also recommend using two-factor authentication (see services like Duo or Twilio's Authy) along with password-protected keys.

<comment><USER41> Absolutely use 2FA, but it's no guarantee.

With large scale hacks in mind and apropos of the Yahoo hack, an attacker has _miniscule_ chances of getting into _your_ account, but 500 million accounts / a 6-digit auth code means with a full compromise (ie, username and plaintext passwords, which the Yahoo compromise was _not_ ), the attacker would still get into 5 accounts.

Given how much full email access is "keys to the kingdom" given password resets, thats the ( _tiniest_ ) bit worrying.

</comment></comment><comment><USER42> Relevant xkcd: [https://xkcd.com/538/](https://xkcd.com/538/)

</comment><comment><USER43> [https://github.com/philipWendland/IsoApplet](https://github.com/philipWendland/IsoApplet) \+ some blank java cards + card reader. Something about Yubico rubs me the wrong way.

<comment><USER44> Use a GPG Card - much simpler than acquiring blank Java cards.

<comment><USER43> And what is hard exactly about acquiring blank Java cards? Not harder than ordering anything else over the Internet.

<comment><USER44> Well, finding a reliable seller in Europe seems to be hard.

<comment><USER43> We live in the age of globalization, these guys better be delivering worldwide, they ask $25 for it.

[http://javacardos.com/store](http://javacardos.com/store)

Or if you have a friend that knows Russian you can use this [http://www.smart- card.ru/_catalog/?search=jcop](http://www.smart-card.ru/_catalog/?search=jcop)

</comment></comment></comment></comment></comment><comment><USER45> What about for the host key of the server (assuming ssh2)?

<comment><USER21> RSA and Ed25519 only, in my opinion. Don't use DSA or ECDSA.

</comment></comment><comment><USER46> Most important is - keep it safe

Passphrase is strongly advised

</comment><comment><USER47>
        Is it better to use a different passphrase on each key, or does using the same one not matter much?

If the keys are for the same thing (i.e. your personal `id_rsa` and `id_ed25519`), then I'd personally be comfortable with the same passphrase. Different passphrases should be used for different purposes (e.g. you shouldn't use your personal passphrase on work-specific keys).

        How much less secure is it to not use a passphrase on a key?

Depends on the situation. I personally err on the side of caution and use a passphrase on all keys unless it's not physically possible.

If you expect to be moving your SSH keys across machines (e.g. to use your same personal key on both your laptop and your desktop), then they should absolutely be passphrase-protected, even if they're only transferred via encrypted media.

        Should you use a different key per user account, per server, or per use-case (i.e. personal or work)?

There's not really a right or wrong answer to this besides "don't reuse the same key everywhere". I personally maintain one key (really two: one RSA, one ED25519) for all of my personal devices, and maintain a strict policy of full- disk encryption on such devices. I've occasionally maintained separate work keys so that I'm not ever in a position where I need to make my personal keys available to an employer.

Meanwhile, for situations where a server needs to connect to another machine via SSH, each such server gets its own key. That way, if a server is compromised or decommissioned, I can revoke access by key.

        Does increasing the amount of bits in a key really have an effect on the security of the key, or does it not make much difference in a real-world use?

It makes a significant difference. More bits → exponentially more attempts required to brute-force it.

        How/Where should private keys be stored on a device using them?

Depends on the device.

A reasonable balance between security and practicality is for any portable media (including portable devices, like laptops/tablets/phones) to be encrypted (in addition to the key itself being passphrase-protected). Better security would be to extend this to non-portable media and machines as well (but this is painful to enforce on servers unless you have physical access).

The directory in which keys are stored should only be accessible to the OS user actually using those keys (so, for example, `~/.ssh` should have permissions `drwx</comment><comment>` when viewing with `ls -la`).

Basically, server SSH keys should be treated like you'd treat your SSL/TLS keys.

        What are some of the pros and cons from a security standpoint

...of?

        and how may doing different things affect the usability of a key?

Pretty much everything involves security v. convenience tradeoffs. Generally, the more secure, the less convenient, and vice versa. While absolute security is ideal, a lack of convenience makes it more difficult to effectively enforce (e.g. as part of a company-wide security policy) unless you're willing to put in the work to build up an effective workflow around it.

</comment><comment><USER46> I agree with following comment.i was wrong. Thanks asdfaoeu for it.

<comment><USER26> > Private key is a "password", we need to treat it as such!

This is harmful advice in my opinion. A key has sufficient entropy to resist brute force attacks and is never directly exposed to a server. The same key between multiple servers is fine.

</comment></comment><comment><USER48> i can recommend this link:

Upgrade your SSH keys! [https://blog.g3rt.nl/upgrade-your-ssh- keys.html?_utm_source=...](https://blog.g3rt.nl/upgrade-your-ssh- keys.html?_utm_source=1-2-2)</comment>