The reason for Go was that much of the research was based on AI algorithms like Monte-Carlo.
What was "solved" with AlphaGo was using deep learning machine learning which are effectively black boxes. There was a certain assumption in the question for AI researchers academically that it would be an understood algorithm as an AI agent like a Prolog application, not a brute forced model. That's still not the case that we have a "solved" strategy and all we can do is watch it play as if it is a deaf mute player.
So there still is no "tic-tac-toe" known winning strategy to Go or anything.
That doesn't make AlphaGo any less impressive or any less practical, but it even has its own readout issues. It can't even read ladders without hard coding it in, for instance, because it becomes a long enough depth search. This is one of the first things a newbie would learn.
It's just a 19x19 board, so it was always known if you could read all the possible outcomes you could see all the possibilities and win. This is just looking at all possible outcomes and picking the best one, not knowing how to play. Creating models of data that is 2, 3, or even 4+ dimensions is always possible, just depends on how much computing power you can throw at it. The created models are essentially aggregate simplifications to play quicker.
Generalized intelligence is so much different. You have to define the problems themselves that you are trying to solve, figure out what the variables are, and solve it. Then you have to operate and run the machinery to create those experiments. Outside of a scenario that you've taken actual physical territory as an intelligence, I can't see how it would get there (think Terminator or BSG, doesn't have to be malicious but they'd have to be in control of the physical area autonomously).
But the hardest part is defining the problems independently given the sheer number of problems they'd need to define second to second just to solve basic tasks, and they'd likely have millions of variables with millions of possible values.
Yeah that's a lot better. Don't get me wrong, I love playfulness, especially in documentation. It's just that before you even really know what a product is or does it seemed like it was worded like "don't even try to figure out what we are doing here and execute untrusted code" or something, haha.
I totally understood what you were trying to do, I just think if I interpreted it that way at first, others might as well. I at least had your other stuff to go off of to eventually get me to figure it out, whereas people encountering your page on the internet wouldn't. Was just trying to help :)
Initially, I was pretty thoroughly perplexed by what this actually did since all I did was click the original link and didn't even see this post text. I figured it out through mostly the 2017 link above. I have a pretty good idea now and see its value.
That being said, when looking at your actual website initially with no context, I couldn't really figure out what it did. My first instinct was to hit the "Docs" button.
The "Don't README" header and the just download my code and run it and figure out how it works later mantra with regard to an end-to-end encryption software (or software in general) was very off-putting to me. I actually wasn't very interested in figuring out what your software did at that point, as it just was flashing red-flag in my head. Was it malware? Was it really end-to-end encrypted?
Just a suggestion, you might want to reword some of that front landing page of the Docs page. I understand your wanting to convey that it "just works", but you might want to convey a bit better somehow what exactly what is just working in the first place, and do so in a way that isn't screaming "don't try to figure out how it's working". Maybe also advertise a bit more clearly that it's open source.
The whole "unless you really want to" is a little weird, too. Every end-to-end encryption software you use you should understand fully what encryption is being used, especially when targeting developers handling core secrets for major organizations or what have you.
I just spent the whole weekend patching whatever the last kernel vuln was and had to plan around like 20 people's schedules. I thought Meltdown/Spectre was bad, this year is already feeling like that year in repeat.
15 years as a sysadmin, anyone have suggestions for my next career move? Thanks.
But seriously it doesn't make much sense to me, but that actually might be a comprehension problem on my part. It does sound very trolly. Thanks for warning me :)
> So when people come up with labels like 'schizopost' or 'word salad'
"word salad" is not a label made up by dumb people, it's generally a alternate term for schizophasia. It's also a very old term. Whether dumb people repurposed it or not is another question. Speaking from personal experience, word salad is generally not controllable and not a pleasant thing that you would "want" to use to express yourself, you generally want to stop and regain control of yourself but simply can't or have already given up hope of regaining control over your speech patterns. It's generally not very pleasant and despair inducing, and you get very lost and fall into a, well, kafka-esque nightmare (/me looks at my name).
> Disorganized thinking (speech). Disorganized thinking is inferred from disorganized speech. Effective communication can be impaired, and answers to questions may be partially or completely unrelated. Rarely, speech may include putting together meaningless words that can't be understood, sometimes known as word salad.
> In very severe cases, positive thought disorder manifests as unintelligible speech in which neither the individual words nor the sentences being strung together seem to correspond to any discernable overall meaning – ‘word salad’ or schizophasia, e.g. “Oh, it [life in a hospital] was superb, you know, the trains broke, and the pond fell in the front doorway” (McKenna & Oh 2005), or “They’re destroying too many cattle and oil just to make soap. If we need soap when you can jump into a pool of water, and then when you go to buy your gasoline, my folks always thought they should, get pop but the best thing to get, is motor oil, and, money. May may as well go there and, trade in some, pop caps and, uh, tires, and tractors to grup, car garages, so they can pull cars away from wrecks, is what I believe in. So I didn’t go there to get no more pop when my folks said it. I just went there to get a ice-cream cone, and some pop, in cans, or we can go over there to get a cigarette” (Andreasen 1986).
I really liked my System76 laptop until the AC adapter died. I looked around on their site to buy accessories and it wasn't there. Eventually I found you have to open a support ticket to get a replacement.
Not only did it take multiple days for them to respond (me without laptop), their resolution was to attach an invoice for one despite me asking for two. I didn't want to open a new ticket so I just looked online for an AC that had the same voltage/amp/etc and head, then ordered three. I have multiple desks...
The three arrived approximately a week before the one they sent out.
Also, you can't actually open these the way they've glued them shut inside by attaching the heatsink to the outer case. Might be a manufacturing defect but definitely can't open mine after unscrewing the bottom.
Never buying a System76 laptop again after this thing dies.
Debian and Fedora have always been my two recommended distros for people. They are the upstream providers of the packages for most distros, and in the case of Ubuntu it has always been a bad choice.
Even from day one, forking Debian and breaking a bunch of packages as they went off on their own, then years later going oops how do we fix this Daddy Debian? Adding Amazon to their search by default in Unity initially. Creating a new desktop protocol to replace X11 rather than work with the Wayland teams so they could rush to ship their phone that nobody wanted.
Canonical is just a good marketing company. They want to do things their way and screw over as many Linux developers as they can to get their way.
If you mean my software I mentioned if something breaks I'm still required to fix it. I just doubt that will happen at this point and have other tasks to do.
I had a similar problem with the YouTube plugin for Kodi recently. Turned out to be some weird Python 3.10 regression that took over a month to fix.
For ProtonVPN you can also use the OpenVPN config files they provide to avoid any Python client issues. Ironically I have a Bash script written around that to generate individual ovpn files as needed from the zip for myself.
That's what Python2.7 is and why every major proprietary product won't adopt anything else. It's also why it won't go away.
All of my Python 2.6-2.7 scripts haven't been touched in 10 years in production and they aren't likely to ever be updated. I actually now refuse to write new Python that isn't compatible with both 2&3 for this reason. Python3 refuses to stabilize.
That's also definitely true for universities with enough reputation and infrastructure to score large contracts/grants with private sector corporations (or mega US defense contractors).
I also know of a couple of chemistry professors and one is new and his PhD was overseas in Saudi Arabia and he basically said it was just large scale brute force data analysis and discovery of chemicals in Python with a small amount of lab work to prepare the datasets. Basically there's a huge pipeline for this sort of work to discover new chemicals in labs, get a PhD out of it, but it's all just sort of an engine that functions to brute force the chemical possibilities not real meaningful research. I never asked but I assume the results just get fed into a pharma company or something.
Then you have those chemists on the opposite end, ready to retire, who are working on cold fusion because why not it's interesting to study even if it goes nowhere.
Our whole society has kind of turned into a giant web of a machine that can't be untangled without ripping everything apart. Some of it is stupider than others, but most of it is kind of a bullshit layer on top of a bullshit layer. We obviously see that in IT as well, with marketing tools that are just wrappers for simple underlying tech that anyone could set up. Sometimes there is significant value added, sometimes there is none (or even negative value).
I don't know where I'm going with this so I'm going to stop typing.
> This incentive structure distorts research. What to do about it? I'm not exactly sure but having university administrations who see research as a means to make money, rather than an end in itself, is not the way.
A lot of the reasons of this distortion is due to the lack of funding from government in state universities which keeps going down as the cost of running a university keeps going up. Because of the rising costs, things get pushed to extremes and the accountants/administrators are put between a rock and a hard place.
Depending on the university in question, it might not be just about "making money" but just not shutting the university down and trying to swim upstream in a never-ending battle.
Worst case scenario it's basically just a wrapper for GPG, so you can always get at the password if you have access to your GPG keyring.
I've also never had to directly install it on Linux, it seems to come pre-installed on most distros recently (I think it's a part of GNOME or something, even though I don't use that).
> I always try to assume breach in my thought processes, but I recognize that this lead to overengineered solutions because sometimes the mitigation is not worth the cost.
I agree with this mindset, I do the same. But at the same time, yes you do have to realize that sometimes it's not worth it. For instance, there are two types of attack you might encounter, a strong nation-state and a drive-by botnet using known exploits and weak passwords to grab the low hanging fruit. If you are patched and using strong passwords, you aren't going to be affected by the drive-by botnet. If you are patched and using MFA and whatever strong credentials, a zero-day sat on by a nation-state is going to plow through anyway. Then they have gotten into that outer ring as a user and you are trying to protect against privilege escalation. Most things to protect against that here that are actually going to work are going to be strong process control or integrity checking (Windows), or Mandatory Access control systems (SELinux), or just basic user silo-ing and not running things as privileged accounts (either one). Most of that is going to be on the OS design itself or architecture of the process.
So we go to privilege escalation exploits. Take this year, at time of writing this is March. I have been patching nothing but privilege escalation flaws on Linux machines (I don't admin Windows, so I don't know that landscape) all year in 2022. It's only been three months. There's no short supply of them being discovered, and many of them are mildly, moderately, or entirely mitigated by just using SELinux. Some of them go all the way past it, though, so sometimes it can be futile.
So the nation-state threat in almost any case will likely have the ability to jump right past the zero-day to root level. So what about in-between? Well, learning about attack and if you are stockpiling or developing zero-days, those tend to add up quick or you just get locked out entirely because they get patched. Your skills also ramp up pretty quickly, too, as an exploit hunter. So you either develop a strong foothold or you fall out of the criminal world entirely. I'm sure it's probably the most paranoia-driven and stressful "job" to have while you are striving not to completely fall apart and get locked out due to defense ramping up or locked up (not that trying not to get hacked isn't paranoia-driven enough).
I also want to emphasize, you REALLY don't want to get compromised AT ALL at this point. Patching is probably the best way to do that, and the most important step. The reason being, you can't necessarily prove that you have kicked out the user after you think you have unless you just completely wiped the machine, and even then you have no idea if they got as far as a firmware exploit (in the instance of a nation-state), which is the more terrifying exploits that are being discovered and sought after.
But regardless, if you find out that you've been compromised and you're using a random password, you're going to change that password anyway if you are doing things right.
> I don't use SSH certificates at work because they really don't make sense for me when I am using a strong credential already (HSMs)
And that's a great point, too. HSMs are a great way to secure SSH as it is, and use the same or similar cryptography as SSH certs as long as they are well developed.
What comes to mind for me for a complicated environment where SSH certs don't help is that there might be inter-organizational issues where you have to make a connection work over multiple crazy hops. So for instance, an end-user's laptop has to connect to Citrix from home, then RDP into a local machine in organization A, then over an existing IPSEC tunnel use OpenVPN software to VPN into organization B, then SSH into a server in organization B. Organization B just did things using OpenVPN, and then SSH, but the rest had to be tacked on due to the client's environment. Real world example. So, the best usage in this case was for organization B to use Yubikeys in OTP mode to type the AES signed secrets typed as a keyboard through the multiple connections. Organization B had no control over organization A's infrastructure or ability to tell them to stop doing anything the way they were doing it, but had to consider the security implications of the way they had set their systems up anyway because the "client" was working in this environment. Then there was the issue of training the users, and explaining SSH certs OR keys to them would have been impossible. Telling them to hit a button was hard enough.
I've heard much crazier stories from the military involving piping encrypted sessions over satellite and jumping it over cable connections, etc (including patching live Super Bowl feeds over serial connections for officers which are always fun stories, especially when dealing with legal copyright issues involving the government in the 80s and fudging reasoning), but there are just some things when you are involved with multiple organizations or multiple connections or inter-organization or international things that you just can't control every single detail of. This is going to get more and more complicated as remote-work gets adopted more as well, so these old stories of network insanity are extremely useful for application level connectivity for sysadmins now.
Long story short, sometimes that thing you think is engineered terribly has a reason for it. Usually it involves stupid logistical nightmares, weird requirements, or bureaucratic/legal hopping. It's only going to get worse, too.
The fundamentals are that you need to exceed O(2^N) > 80 bits roughly in complexity of your keys. Adding some padding to that is a good idea because some algorithms can be simplified in theory (for instance AES-128 is actually simplified down to like ~118 already through known math).
This is for symmetric encryption, and for asymmetric the equivalent is ~1024-bits, so padding it up to 2048-bits is generally the "minimum" for RSA, and some of that math is advancing too so bumping it to 4096-bits isn't a bad idea. If you want to be quantum proof, RSA will be broken so moving to something else like EC is nice. AES would be halved O(sqrt(N)), so AES-128 becomes the equivalent of AES-64, so if you want to be quantum proof there you need to jump up to AES-256 (unless you are using XTS/tweak mode, in which case AES-512). Keep in mind quantum also is not exactly short term practical to accomplish at the moment.
You can use whatever technology to accomplish that complexity, be it passwords, SSH keys, or SSH certs. Anything else is just technology architecture noise. Passwords absolutely can clear the O(2^N) > 80 bit threshold. It's just about bytes, and how you store them.
Nobody is going to be brute forcing a sufficiently complex password over the network anytime soon unless it isn't actually random but some default password that looks random.
Just look at the title of this post: "If you're not using SSH certificates you're doing SSH wrong". It's just completely devoid of environment issues, user issues, datacenter issues, and reeks of elitism. There is no "one true way" despite people's insistence that they are the arbiters of truth. I keep reading here about "you should just use serial over network instead of SSH!" but fail to read about how those serial over network connections are usually less secure than SSH itself.
Best practices guides have gone off the rails. They are generally good guidelines, but you have to make sure you are taking into account your own environment and user needs and take them with a grain of salt. Learn for yourself, and read raw facts from real cryptographers and people in the field. Don't take best practices guides as absolute truth, but learn from them.
How does one become a security professional? Maybe not with one of those "become a security professional in 30 minutes" packages then start a blog about how everyone isn't conforming to their tiny worldview. No matter what it'll take >10 years with actual experience, just like any profession. One has to start from the bottom and make their way up. Most environments are too complicated for any "one size fits all" solution:
EDIT: Further discussion on this here is interesting. The top comments go all in on SSH certificates, then down the line people start questioning why passwords are bad in the same ways. A lot of the "SSL certificate" push theorized here from their perspective seems to come from VPN providers that need it from lesser skilled clients/users (think, people who bought VPNs off YouTube video recommendations):
1. We didn't compromise any laptop? It was a thin client.
2. "Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider." -
I'm STILL unsure how its a unsuccessful attempt? Logged in to superuser portal with the ability to reset the Password and MFA of ~95% of clients isn't successful?
4. For a company that supports Zero-Trust. Support Engineers seem to have excessive access to Slack? 8.6k channels? (You may want to search AKIA* on your Slack, rather a bad security practice to store AWS keys in Slack channels )
5. Support engineers are also able to facilitate the resetting of passwords and MFA factors for users, but are unable to obtain those passwords. -
Uhm? I hope no-one can read passwords? not just support engineers, LOL. - are you implying passwords are stored in plaintext?
6. You claim a laptop was compromised? In that case what suspicious IP addresses do you have available to report?
7. The potential impact to Okta customers is NOT limited, I'm pretty certain resetting passwords and MFA would result in complete compromise of many clients systems.
8. If you are committed to transparency how about you hire a firm such as Mandiant and PUBLISH their report? I'm sure it would be very different to your report :)
21. Security Breach Management.
a) Notification: In the event of a Security Breach, Okta notifies impacted customers of such Security Breach. Okta
cooperates with an impacted customer’s reasonable request for information regarding such Security Breach, and Okta
provides regular updates on any such Security Breach and the investigative action and corrective action(s) taken. -
But customers only found out today? Why wait this long?
9. Access Controls. Okta has in place policies, procedures, and logical controls that are designed:
b. Controls to ensure that all Okta personnel who are granted access to any Customer Data are based on leastprivilege principles;
kkkkkkkkkkkkkkk
1. Security Standards. Okta’s ISMP includes adherence to and regular testing of the key controls, systems and procedures of
its ISMP to validate that they are properly implemented and effective in addressing the threats and risks identified. Such
testing includes:
a) Internal risk assessments;
b) ISO 27001, 27002, 27017 and 27018 certifications;
c) NIST guidance; and
d) SOC2 Type II (or successor standard) audits annually performed by accredited third-party auditors (“Audit
Report”).
I don't think storing AWS keys within Slack would comply to any of these standards?
What was "solved" with AlphaGo was using deep learning machine learning which are effectively black boxes. There was a certain assumption in the question for AI researchers academically that it would be an understood algorithm as an AI agent like a Prolog application, not a brute forced model. That's still not the case that we have a "solved" strategy and all we can do is watch it play as if it is a deaf mute player.
So there still is no "tic-tac-toe" known winning strategy to Go or anything.
That doesn't make AlphaGo any less impressive or any less practical, but it even has its own readout issues. It can't even read ladders without hard coding it in, for instance, because it becomes a long enough depth search. This is one of the first things a newbie would learn.
It's just a 19x19 board, so it was always known if you could read all the possible outcomes you could see all the possibilities and win. This is just looking at all possible outcomes and picking the best one, not knowing how to play. Creating models of data that is 2, 3, or even 4+ dimensions is always possible, just depends on how much computing power you can throw at it. The created models are essentially aggregate simplifications to play quicker.
Generalized intelligence is so much different. You have to define the problems themselves that you are trying to solve, figure out what the variables are, and solve it. Then you have to operate and run the machinery to create those experiments. Outside of a scenario that you've taken actual physical territory as an intelligence, I can't see how it would get there (think Terminator or BSG, doesn't have to be malicious but they'd have to be in control of the physical area autonomously).
But the hardest part is defining the problems independently given the sheer number of problems they'd need to define second to second just to solve basic tasks, and they'd likely have millions of variables with millions of possible values.