I remember meeting Rob briefly at one of the Atlanta Linux Symposium, what a great memory. My work life wouldn't be the same without the comments, experience and insight I gained here. Big thanks.
Honestly I could care less about another SSD technology - having good NVRAM on the memory bus is one of the most exciting things in system design I've seen in a long time.
I may be wrong - but in my experience a minimum of 10% of runtime at load, and at least 25-30% of OS code is all about hiding the fact that storage speed sucks and we have to stuff everything through a storage protocol. New IO designs could open up some very cool technologies that currently depend on clunky NAND/flash limitations.
Sorry, I was evaluating SSH security protocols and was looking to add moduli generation and DH exchanges last year.
Ideally, it would be nice to generate a high-quality moduli for each new connection. 8 minutes in your case, and more than an hour on an ARM core. Forever in terms of algorithms and network connections.
I've got 383 spams so far today from the new gTLD domains for this one account, it's just not worth the effort. I bounce them back the messages with a contact address "in case you received an error" Not a peep yet.
And this is *after* I rbl and rhsbl filter! I should sell this is a spam feed. 100% fresh, prime grade A spam. Yummy.
WARNING: This takes forever. Also, according to man ssh-keygen:
It is important that this file contains moduli of a range of bit lengths and that both ends of a connection share common moduli.
It's not possible to regenerate and share many moduli quickly - hence the reuse of moduli. SSH has support for x25519 algorithms - this definitely means I'll be moving away from pre-computed DH moduli also.
It would be a little work, but by simply observing the changes in the register file step by step, you could make some good guesses at what instruction was executed. That gives you a portion of the decrypted executable code. If you can get a few 16 byte blocks (AES blocksize), then you can reverse the key.
The other issue is that the only modes they could likely use to encrypt the data would be ECB, CTR or XTS. There are many known attacks on those modes when you have leaking cleartext.
Your views are completely understandable, given your situation.
But honestly I think this is terrible - as a society - to know this to be the new normal. This is saying that we have given up as a society on actual premises of society. If we don't believe in safe neighborhoods, respect for individuality, a broad acceptance of differing views and a willingness to demand our basic rights then what is left?
We have given up on a big part of the freedoms we deserve to live our lives as we see fit. Such thinking will propagate upwards into adulthood and across the legal system over time. Viewing the outside world as only for adults is more than a disservice to childhood.
Agreed. I started using cash a few months ago so that I could keep better track of my spending, but the side benefit is a smaller digital footprint. I don't live in a high crime area, so the tradeoff is mostly positive.
Amen! I'm know there were some gems in the rough, and also some amazing apps that I never saw, but by-and-large the emphasis on shiny marketing and top tens over quality has overshadowed the market for a couple of years.
I have some genuine good ideas I'd like to throw at an app, but I'm looking at the market and I don't really want to touch it.
What about the amount of pollutants released with the launch of this satellite? Solid rockets and hydrazine aren't exactly environmentally friendly when you burn a million pounds in 12 minutes. The production of H2 and LOX is pretty dirty also, even if the final product is water.
I may sound a little pedantic, but at least I'm not roaming the globe looking like Chuckles the CO2 clown...
I second straightalk. You don't need a credit card - just buy the $45 dollar sim kit and you can choose att, tmobile or verizon - a full month unlimited talk, text, data all included. They also have a 60 dollar international plan.
Don't screw up the activation - dont port your number. Just get a new number - otherwise you have phone hell. And straighttalk phone service is awful. But the phone service is great. Go figure...
These guys have a simple and cheap way to produce hydrogen on demand for fuel cells.
I think the only way we're going to transition the current oil economy into zero emissions is to combine the best tech from electric cars with a liquid fuel.
Not as sleek, awesome or expensive... but Ammonia fuel cells are getting pretty good these days. Ammonia is already produced across the planet as fertilizer by the ton. And it can be produced already using several processes from oil, natural gas, propane, biologicals and of course recycled sewage.
Ammonia has a higher energy density than hydrogen, is easier to store, and can be transported easily at 8-10 bars of pressure. Lastly, ammonia is the second most widely produced commodity chemical in the world.
Only downside, it's poisonous. On the upside, you can easily smell a leak at safe levels 1ppm. I think hydrogen would asphyxiate people if there was a slow leak, as it's odorless.
I disagree. Having worked in everything from multinational companies to 3 man start-up companies I think I've seen quite a bit of the dev world.
I think a well balanced team usually consists of older and younger developers myself.
What you want to avoid as a manager is encouraging cliques and age-based group stratums. Socially people will naturally tend to separate by age somewhat, but by spreading your experienced devs in with the less experienced you create new niches and groups that center around productive aspects such as projects, platforms, and responsibilities.
A few tricks I've used is allow developers to volunteer for project milestones. This gives you good cross-communication setup between project and age groups and allows devs to find their fit if you structure your projects right.
Another trick is to encourage creativity and social rewards. Having code meetings where the entire crowd gets to work through some code together. Each meeting, a different person or team brings part of their project to present and explain their design choices and algorithms for the rest of the team. The team gets to learn a bit, and also can positively (or occasionally negatively) critique the code and look for problems. This can work across projects and departments as well.
You need to encourage social activities across groups as well, but be careful not to cut into outside time too much. Older devs generally have lives outside of work. So limit your after-work socializing and instead encourage innovative activities with 15 minute coffee breaks together or an after-meeting walk.
If you're having problems motivating older developers then it's quite likely that you're not building, managing and deploying your experience properly. You need to do more than toss them in a cube with a set of project milestones. Younger people will do better in that environment if only because they will have more time to sacrifice.
Older people have already done their "lone wolf" time, and generally expect better management and organization. They expect resources to get the job done efficiently and want to be learning and mentoring, not just chugging out LOC. Most of them won't complain as devs tend to be introverts for the most part. If you want productive feedback then you need to empower groups with responsibilities beyond milestones. They need to have time to evaluate and analyze. They need to have time to go over designs and understand, give input, and have their input rewarded.
The secret is to create balanced work environments that allow your workers to be both productive and growing. Having static organizational structures that boxes devs into platforms and languages for years creates experience lags and power bubbles. Having work/slave relationships creates revolving doors. Having loose organizations creates deadline creep and project failure.
In the end, there are plenty of organizations successfully employing developers into retirement age. What you want is an organization that manages goals and expectations by delegating work to teams that are organized with mixed experience and socially rewarded for meeting deadlines. Management should be open to criticism and giving out criticism when necessary. Teams should as well.
Lastly, realize that most developers aren't strictly motivated by dollars. Most people are far more motivated to work towards a goal when the reward is linked with their goals and creativity. Developers need to have the room to try things and fail at them, refine and build on those experiences. If you build that into your development process then you will reduce product and project failures enormously.
I think the article is complete bollocks, but simple basic DSP isn't that difficult if you use a simple codec. Hell, even a morse code type system with basic CRC checking wouldn't take more than 16k. It doesn't have to deal with echo (high frequency is rather directional), it doesn't have to deal with doppler (few moving objects), and it's obviously a secondary communications channel.
The thing that gives it away for me is that something could embed so deeply without being detected, as USB and networks are heavily scanned these days.
I have written plenty of kernel code, bios code and the like. The effort to get such perfect code running without causing crashes or being detected on the network would be enormous. If it's at all possible, it would certainly require government level funding.
I'm not saying it isn't possible - but it's just very, very unlikely.
Use/dev/random and Monolith... dd from random into a file the same size as your cleartext, use Monolith to xor the files into a third file, secured file. The random file is essentially your key, so it must be kept separate from your secured file to be safe.
Tyrone, you know how much I love watching you work, but I've got my country's 500th anniversary to plan, my wedding to arrange, my wife to murder and Guilder to frame for it; I'm swamped.
Thanks for that, I found it separately also, and read a few of the papers referenced. I tend to agree that this madness is a bit overblown. Reducing the time by 15% is really impressive overall, but when our anticipated sieving times for a typical 2k-4k keysize are measured in months and years that isn't a huge difference.
Basically, from my first read, this is just a better sieve, a system which should find smooth numbers faster by choosing better starting points and using faster tests. I wouldn't call it a general break in RSA, and while it might certainly be a better sieve than GNFS, it's no silver bullet either. I can't imagine anyone breaking RSA numbers like this unless they're very well funded.
Slashdot Mirror
Holy carp nuggets! Happy birthday /.!
I remember meeting Rob briefly at one of the Atlanta Linux Symposium, what a great memory. My work life wouldn't be the same without the comments, experience and insight I gained here. Big thanks.
Honestly I could care less about another SSD technology - having good NVRAM on the memory bus is one of the most exciting things in system design I've seen in a long time.
I may be wrong - but in my experience a minimum of 10% of runtime at load, and at least 25-30% of OS code is all about hiding the fact that storage speed sucks and we have to stuff everything through a storage protocol. New IO designs could open up some very cool technologies that currently depend on clunky NAND/flash limitations.
Thanks for the feedback.
Sorry, I was evaluating SSH security protocols and was looking to add moduli generation and DH exchanges last year.
Ideally, it would be nice to generate a high-quality moduli for each new connection. 8 minutes in your case, and more than an hour on an ARM core. Forever in terms of algorithms and network connections.
I've got 383 spams so far today from the new gTLD domains for this one account, it's just not worth the effort. I bounce them back the messages with a contact address "in case you received an error" Not a peep yet.
And this is *after* I rbl and rhsbl filter! I should sell this is a spam feed. 100% fresh, prime grade A spam. Yummy.
When the NSA leaks happened, investigates this and promoted this as a possible attack vector.
NOTE - You can generate a new set of moduli like so:
# ssh-keygen -G moduli-2048.candidates -b 2048
# ssh-keygen -T moduli-2048 -f moduli-2048.candidates
Put the results in /etc/ssh/moduli
WARNING: This takes forever. Also, according to man ssh-keygen:
It is important that this file contains moduli of a range of bit lengths and that both ends of a connection share common moduli.
It's not possible to regenerate and share many moduli quickly - hence the reuse of moduli. SSH has support for x25519 algorithms - this definitely means I'll be moving away from pre-computed DH moduli also.
It would be a little work, but by simply observing the changes in the register file step by step, you could make some good guesses at what instruction was executed. That gives you a portion of the decrypted executable code. If you can get a few 16 byte blocks (AES blocksize), then you can reverse the key.
The other issue is that the only modes they could likely use to encrypt the data would be ECB, CTR or XTS. There are many known attacks on those modes when you have leaking cleartext.
Your views are completely understandable, given your situation.
But honestly I think this is terrible - as a society - to know this to be the new normal. This is saying that we have given up as a society on actual premises of society. If we don't believe in safe neighborhoods, respect for individuality, a broad acceptance of differing views and a willingness to demand our basic rights then what is left?
We have given up on a big part of the freedoms we deserve to live our lives as we see fit. Such thinking will propagate upwards into adulthood and across the legal system over time. Viewing the outside world as only for adults is more than a disservice to childhood.
Just check the IP range of your VPS servers first. Thanks ColoCrossing....
http://lowendtalk.com/discussi...
This is how things are supposed to be. The legal system was designed for individuals "to be secure in their persons, houses, papers, and effects."
Agreed. I started using cash a few months ago so that I could keep better track of my spending, but the side benefit is a smaller digital footprint. I don't live in a high crime area, so the tradeoff is mostly positive.
Amen! I'm know there were some gems in the rough, and also some amazing apps that I never saw, but by-and-large the emphasis on shiny marketing and top tens over quality has overshadowed the market for a couple of years.
I have some genuine good ideas I'd like to throw at an app, but I'm looking at the market and I don't really want to touch it.
What about the amount of pollutants released with the launch of this satellite? Solid rockets and hydrazine aren't exactly environmentally friendly when you burn a million pounds in 12 minutes. The production of H2 and LOX is pretty dirty also, even if the final product is water.
I may sound a little pedantic, but at least I'm not roaming the globe looking like Chuckles the CO2 clown...
Should be straightalk customer service is awful, as I said the phone service is great.
I second straightalk. You don't need a credit card - just buy the $45 dollar sim kit and you can choose att, tmobile or verizon - a full month unlimited talk, text, data all included. They also have a 60 dollar international plan.
Don't screw up the activation - dont port your number. Just get a new number - otherwise you have phone hell. And straighttalk phone service is awful. But the phone service is great. Go figure...
2NH3 -> N2 + 3H2
These guys have a simple and cheap way to produce hydrogen on demand for fuel cells.
I think the only way we're going to transition the current oil economy into zero emissions is to combine the best tech from electric cars with a liquid fuel.
Not as sleek, awesome or expensive... but Ammonia fuel cells are getting pretty good these days. Ammonia is already produced across the planet as fertilizer by the ton. And it can be produced already using several processes from oil, natural gas, propane, biologicals and of course recycled sewage.
Ammonia has a higher energy density than hydrogen, is easier to store, and can be transported easily at 8-10 bars of pressure. Lastly, ammonia is the second most widely produced commodity chemical in the world.
Only downside, it's poisonous. On the upside, you can easily smell a leak at safe levels 1ppm. I think hydrogen would asphyxiate people if there was a slow leak, as it's odorless.
Blame Canada!
Sorry... Couldn't resist.
I disagree. Having worked in everything from multinational companies to 3 man start-up companies I think I've seen quite a bit of the dev world.
I think a well balanced team usually consists of older and younger developers myself.
What you want to avoid as a manager is encouraging cliques and age-based group stratums. Socially people will naturally tend to separate by age somewhat, but by spreading your experienced devs in with the less experienced you create new niches and groups that center around productive aspects such as projects, platforms, and responsibilities.
A few tricks I've used is allow developers to volunteer for project milestones. This gives you good cross-communication setup between project and age groups and allows devs to find their fit if you structure your projects right.
Another trick is to encourage creativity and social rewards. Having code meetings where the entire crowd gets to work through some code together. Each meeting, a different person or team brings part of their project to present and explain their design choices and algorithms for the rest of the team. The team gets to learn a bit, and also can positively (or occasionally negatively) critique the code and look for problems. This can work across projects and departments as well.
You need to encourage social activities across groups as well, but be careful not to cut into outside time too much. Older devs generally have lives outside of work. So limit your after-work socializing and instead encourage innovative activities with 15 minute coffee breaks together or an after-meeting walk.
If you're having problems motivating older developers then it's quite likely that you're not building, managing and deploying your experience properly. You need to do more than toss them in a cube with a set of project milestones. Younger people will do better in that environment if only because they will have more time to sacrifice.
Older people have already done their "lone wolf" time, and generally expect better management and organization. They expect resources to get the job done efficiently and want to be learning and mentoring, not just chugging out LOC. Most of them won't complain as devs tend to be introverts for the most part. If you want productive feedback then you need to empower groups with responsibilities beyond milestones. They need to have time to evaluate and analyze. They need to have time to go over designs and understand, give input, and have their input rewarded.
The secret is to create balanced work environments that allow your workers to be both productive and growing. Having static organizational structures that boxes devs into platforms and languages for years creates experience lags and power bubbles. Having work/slave relationships creates revolving doors. Having loose organizations creates deadline creep and project failure.
In the end, there are plenty of organizations successfully employing developers into retirement age. What you want is an organization that manages goals and expectations by delegating work to teams that are organized with mixed experience and socially rewarded for meeting deadlines. Management should be open to criticism and giving out criticism when necessary. Teams should as well.
Lastly, realize that most developers aren't strictly motivated by dollars. Most people are far more motivated to work towards a goal when the reward is linked with their goals and creativity. Developers need to have the room to try things and fail at them, refine and build on those experiences. If you build that into your development process then you will reduce product and project failures enormously.
Anyway, just my ramblings...
Well, I LOL'ed... but alas no modpoints.
I think the article is complete bollocks, but simple basic DSP isn't that difficult if you use a simple codec. Hell, even a morse code type system with basic CRC checking wouldn't take more than 16k. It doesn't have to deal with echo (high frequency is rather directional), it doesn't have to deal with doppler (few moving objects), and it's obviously a secondary communications channel.
The thing that gives it away for me is that something could embed so deeply without being detected, as USB and networks are heavily scanned these days.
I have written plenty of kernel code, bios code and the like. The effort to get such perfect code running without causing crashes or being detected on the network would be enormous. If it's at all possible, it would certainly require government level funding.
I'm not saying it isn't possible - but it's just very, very unlikely.
Use /dev/random and Monolith... dd from random into a file the same size as your cleartext, use Monolith to xor the files into a third file, secured file. The random file is essentially your key, so it must be kept separate from your secured file to be safe.
http://monolith.sourceforge.net/
And we just crossed the line from science to sex...
Tyrone, you know how much I love watching you work, but I've got my country's 500th anniversary to plan, my wedding to arrange, my wife to murder and Guilder to frame for it; I'm swamped.
Thanks for that, I found it separately also, and read a few of the papers referenced. I tend to agree that this madness is a bit overblown. Reducing the time by 15% is really impressive overall, but when our anticipated sieving times for a typical 2k-4k keysize are measured in months and years that isn't a huge difference.
Okay, here's the slides from a talk:
https://www.cryptolux.org/mediawiki-esc2013/images/c/cd/Joux-EM-multiuser-ESC2013.pdf
And a paper which is related:
http://eprint.iacr.org/2013/095.pdf
Basically, from my first read, this is just a better sieve, a system which should find smooth numbers faster by choosing better starting points and using faster tests. I wouldn't call it a general break in RSA, and while it might certainly be a better sieve than GNFS, it's no silver bullet either. I can't imagine anyone breaking RSA numbers like this unless they're very well funded.