Cup o' Go

This week Jonathan and Shay go deep into FIPS, cryptography, and security, and interview Alex Scheel about it as well!

โ˜… Support this podcast on Patreon โ˜…

Creators & Guests

Host
Jonathan Hall
Freelance Gopher, Continuous Delivery consultant, and host of the Boldly Go YouTube channel.
Host
Shay Nehmad
Engineering Enablement Architect @ Orca
Editor
Filippo Valvassori Bolgรจ
Sound Designer / Audio Editor based in Milan

What is Cup o' Go?

Stay up to date with the Go community in about 15 minutes per week

Shay Nehmad:

This show is supported by you. Stick around till the ad break to hear more about that. This This is Cup of Go for November 22, 2024. Keep up to date with the important happenings in the Go community in about 15 minutes per week. I'm Shay Nehmad.

Jonathan Hall:

I'm Jonathan Hall. Hey, Shay. You know what FIPS means? Wrong answers only.

Shay Nehmad:

Oh, wrong answers only. I think it means fast Internet, please, soon because you're kinda breaking up.

Jonathan Hall:

Yeah. I I only know wrong answers to what FIPS means. I think it's, fast and no. It can't be fast and furious. I don't even I don't have any idea what it means.

Jonathan Hall:

I hope we can, learn what it means because they're adding it to go.

Shay Nehmad:

Oh, they're adding Phipps to go. Why would they change math? No. We already did that joke, actually.

Shay Nehmad:

Well, actually, if any government agents are listening in, a, you don't need to, like, you don't need to tap our our inter this episode is going out publicly. Just without all the crap that, Filippo bleeps out like

Jonathan Hall:

that's the joke.

Shay Nehmad:

So, yeah, this episode is gonna be about crypto and almost strictly about crypto. We have a interesting interview with Alex Scheel, who's gonna, like, try to help us understand what all this crypto nonsense and FIPS is about. In in a nutshell, FIPS is?

Jonathan Hall:

Federal I don't even remember what it stands for. It's a federal, encryption standard. By the way, when you say crypto, we don't mean Bitcoin. We're talking about the old crypto cryptography. Yeah.

Jonathan Hall:

The OG. OG crypto.

Shay Nehmad:

So, yeah, it's a government standard for software vendors. Meaning, if you wanna sell your software to the US government or any of its subsidiaries, you're gonna need to be FIPS compliant. And it's all about your or maybe you're gonna wanna be FIPS compliant. And it's all about post quantum cryptography or just, like, cryptography in general, trying to make sure that your software won't be able to like, the data that you store for the government is safe in a post quantum world. There's one main proposal we wanna talk about.

Shay Nehmad:

Right? 70200. So what's this proposal?

Jonathan Hall:

So 70200 is the proposal to add a FIPS 140 module selection mechanism. Although, I think that title is outdated now. Basically, the idea is make it possible to opt in to build a FIPS compliant go binary. As we'll hear in the interview, FIPS compliant essentially means that certain crypto libraries have been certified. And once they're certified, they cannot change at all even for like serious, security bugs that are discovered, you know, that has to go through a recertification process.

Jonathan Hall:

So there'll be an option. The the proposal is that there's an option to specify which, version of a FIPS certified go library you want to use when you're building your Go code.

Shay Nehmad:

So in order to have this and by the way, this was a module selection at first, but now it's a environment variable. So you just turn on GoFips 140, and your software is, post quantum safe.

Jonathan Hall:

In theory. Yeah.

Shay Nehmad:

So there's a lot of, like, a long tail of proposals related to crypto. If you open the proposal tracker right now I don't know if it's a proposal project tracker, on GitHub. Almost only going to see crypto related things right now just because there are many small proposals. Well, I don't know if they're small. But there are many proposals related to crypto that sort of have to go in together to make this whole thing work.

Shay Nehmad:

Other than having the build flag, you have to actually have the support for all these key generation curve IDs blah blah blah things that honestly Jonathan and I talked about and we're not smart enough to understand. So we're definitely not smart enough to explain in detail. Right. But just to try to try to explain the at least the first part. Right?

Shay Nehmad:

And by the way, we had a talk about post quantum on the show. We I think we had 2. Right? 1 with Filippo and one with, Juan Barczyk and, and Gilada. So there are 2 episodes in the back already with, the smart people who are actually doing this stuff.

Shay Nehmad:

Just as a very basic thing. Right? If you wanna pass secret messages, between you and your friend and there are very smart people who are trying to figure out these, messages, you wanna encrypt them. And if you just use one code and the strongest code you can with a normal computer right now, and then this message is stored somewhere, what's gonna happen in the future? Like, what's this post quantum mean?

Jonathan Hall:

So so yeah. The the issue with this post quantum thing is, like, maybe somebody captures those messages now, and they can't read them now. But in, you know, 5 years or 10 years or 20 years, maybe they can read them. And if there's information in there that is still valid and and and exploitable in in that time frame, That can be serious stuff.

Shay Nehmad:

Yeah. So the whole, I think, premise like, this is obviously a super complicated and highly advanced topic. Mhmm. But, specifically, the draft we're talking about right now are o always boiled down to the same thing is enhancing security, for example, in TLS by combining like the traditional things we have right now like elliptical curve, Diffie Hellman key exchanges with, post quantum key mechanisms. Since you do both at the same time and you're sort of blending the results, you have a hybrid key, a key that's normal and you can work with right now with normal computers, but also keys that are safe that even if quantum computers eventually break the traditional, cipher, which is, by the way, not promised, but I think mathematically, they proved that it will happen.

Shay Nehmad:

The additional post quantum key encapsulation mechanism continues to provide security. Like, your session is gonna be encrypted even if quantum computers are built and they work and they can do all the things that, they promise that they will do. Obviously, I think it's worth noting why this is obviously hugely important for government entities. Let's go to the, like, highest security levels possible. I know the DOD.

Shay Nehmad:

Right?

Jonathan Hall:

The nuclear codes, they're encrypted somewhere, and someone 10 years later can decrypt them.

Shay Nehmad:

Yeah. And if no matter which government you support, by the way, I know we have, listeners from non Western state. No. Seriously.

Jonathan Hall:

Yeah. Oh, definitely.

Shay Nehmad:

We have listeners from non Western states. I think you would feel more comfortable if you knew that your nuclear codes are not they won't be deciphered even if they are captured by country or a government you consider to be your enemy, even if they have quantum computers before your government does. I think this is sort of obviously, the I don't know if the nuclear codes are actually encrypted and are actually important because I think the president has to remember them. And with the ages of our current president, it's probably the 2580. So it's just a down thing on the keypad.

Shay Nehmad:

don't know. I don't wanna get all conspiratorial on you.

Alex Scheel:

What's the combination? 12345. 12345. Yes. That's amazing.

Alex Scheel:

I've got the same combination on my luggage. Prepare Spaceball 1 for immediate departure.

Shay Nehmad:

Yes,

Alex Scheel:

sir. And change the combination on my luggage.

Shay Nehmad:

So the this is the thing that Go is moving towards, and it's moving towards it in the standard library, which is different. Right? Not all languages are doing this right now.

Jonathan Hall:

Yeah. So I mean, we'll we'll talk more about that in the interview, but, a big part of this, it looks like a ton that is happening in crypto, and it and it is, but a lot of it is just moving things from the go laying slash x package space into the center library so that they can be included in this FIPS certification thing. So I don't know which version they'll land in. If I imagine some will come in 124 others in 125, But we're gonna see a lot of crypto additions to the GhostHunter library over the coming, I would say, year or maybe even longer.

Shay Nehmad:

Yeah. And and you can see it really built on one on top of another. A great example is, 67516 where support for controlling the curve ID for a TLS, connection has been added. Right? So you just added the option to control which curve algorithm, like, which crypto algorithm you're gonna use.

Shay Nehmad:

And now this was in September. Right? Now 2 months later, we're adding curves that are specifically useful for post quantum world. Just adding these options to the enam and only using them if you're using the build flag. Right?

Shay Nehmad:

The FIPS one forty build flag is turned on, then you'll pick the curve I you have to pick the curve IDs that are compliant with FIPS by default. So this is this has been a long time coming and and we've built I think we've built this pretty, like step by step. It's a very gradual process which I think is very cool to see because the standard is not gradual. It's just out and you have to be compliant to it or else. Like, there are versions but they they they only make things more difficult.

Shay Nehmad:

But it's nice to see that in order to make Go compliant, we're still adhering to what Go usually does which is very, rigorous, very slow. You start in x and then you merge it in and it's like a build flag and it's unable by default, etcetera, etcetera. Although some of these proposals do include changes to default values if they are not breaking. So if there's a non breaking change that improves security without taking a big performance hit, Go is gonna do it, which is sort of awesome because your software is becoming more secure just by updating dependencies, which is usually the opposite of what happens. Right?

Shay Nehmad:

But just the code that you compile is gonna be more secure.

Jonathan Hall:

That's right. So, we're gonna talk more about FIPS and security in the interview in just about 5 minutes. So stick around for that. We have a couple other items we do wanna talk about, of course, before we get there. First up, we have a blog post from Jacob Jaros.

Jonathan Hall:

I hope I'm saying his name right. Writing secure Go code. So it's still on the security topic. It's a really easy to digest blog post, especially if you're new to programming or new to Go or new to security. These are some sort of common sense tips to to get you off on the right foot.

Jonathan Hall:

The first one is use the latest version of Go. Keep your Go version up to date because security fixes are happening all the time in both the most recent and the second most recent major versions of Go. So as as we're recording, that's 1.23 and 1.22. Next up, it talks about some tools you can use, GoVet, static check, GoLink CLIint, tools that will just do a static analysis for your code. And, depending on configuration can warn you about security vulnerabilities.

Jonathan Hall:

And, the last one, I'll talk about here, although there are others in the article, is detecting race conditions. We don't always think of race conditions as security related, but they certainly can be. If you have 2 pieces of code running concurrently that are writing or reading to the same part of memory without being properly controlled, you can, get some nasty things. It can often lead to crashes but can also just lead to unexpected results, including security problems. So check out this article if you're not familiar already with, yeah, with writing secure code.

Jonathan Hall:

If that's a new topic to you, this will be a quick a quick primer on the topic.

Shay Nehmad:

So I think some of the advice here is a no brainer just because the effort is so low even if you have just a tiny bit of upside, and these are things you should do anyway. Right? Keeping Go version up to date, very minimal effort. I saw a really big recent project upgrading from 1, like, to 19 to 1 19 to 123. No hiccups.

Shay Nehmad:

Just change the version and rebuild. Everything works. The Go tooling thing, you should do it anyway. Right? Running go vet, your ID is probably doing it for you.

Shay Nehmad:

Static check, you could install it. Honestly, if you're using Golang clint, you don't really have to, I think, because it's probably included. So these things I think are are a no brainer. They should happen by default in any Go project, like, regardless. However, go test minus race is the first piece of advice in this blog post where I'm pretty sure not all Go projects do it by default.

Shay Nehmad:

And I'm wondering if you think like, everybody wants to write secure code. Do you think every project should just try to do this by default? Like, would would you hand this item on the checklist to to any project?

Jonathan Hall:

Yeah. I mean, I I the only time I don't run race all the time is when I'm have c go enabled equals 0 because you have to have c go enabled to run the race detector. So when I have a project that I build with c go enabled equals 0, I first run it with the race detector and c go on, and then I also run my tests with the with c go off just to make sure that it works both ways. I can't think of a reason you wouldn't want the race detector. And not and not just from security, but just from a simple, I don't want bugs in my code standpoint.

Jonathan Hall:

You should always run the race detector.

Shay Nehmad:

Yeah. Although it is worth noting, the go race detector detects, race data races in between go routines. And this is not the only strain of, like, race condition vulnerability that exists. Of course. If you have 2 go, programs running on the same like, 2 different processes running on the same server and they have a race condition, the Go test flag is not gonna detect that, right, because it's only in process.

Shay Nehmad:

And some real I think the Juniper vulnerability was was that.

Jonathan Hall:

It's also worth pointing out that the Go race detector will only detect races that actually happen. It so, you know, the fact that you don't detect a race when you're on your test doesn't mean there aren't potential races if your tests don't trigger those races.

Shay Nehmad:

Oh, that's true obviously as well. You have to if you're gonna have to have a 100% code coverage and also the data has to, like if there are more dynamic parts of your application, that's gonna be kinda difficult. So it doesn't guarantee it. That's for sure. Then you have go vulncheck.

Shay Nehmad:

So I don't think I would recommend this for every project. Right? Only if you're working on enterprise or things that actually have to be very secure would I start worrying about, oh, do my dependencies have vulnerabilities? Because if you're just shipping up up, I don't know, an open source hobby project that you work on for fun, I don't know, people only run locally, that doesn't matter. Right?

Shay Nehmad:

It doesn't matter if I run a CLI locally that that does some something cool for me, it has vulnerabilities. It just doesn't matter because the it's not exposed.

Jonathan Hall:

I suppose it depends on what kind of vulnerability. I mean, you might have a a piece of rogue code that's sending private data somewhere.

Shay Nehmad:

Yeah. But that's not really

Jonathan Hall:

what it could happen.

Shay Nehmad:

Yeah. Yeah. Like, you don't wanna run malicious code. I'm more talking about introducing, like

Jonathan Hall:

Weak crypto.

Shay Nehmad:

Potentially exploitable, things into your into your Go code. And then there's the topic of Go sec, right, that, Jacob recommends here. And that one is is again, obviously sounds like a good thing, but there are a few asterisk. Like, have you turned on, GoSec in any of your recent projects via Go lang sye Island, I assume?

Jonathan Hall:

Yeah. I I do use it and it gives me a fair number of false positives, honestly. I don't know that one. It's not actually just this morning, I had one. I was using a math brand v 2 to generate a delay on a retry and go sec's like, oh, that's an unsecured random number generator.

Jonathan Hall:

Like, I don't care. This isn't, you know, this is a delay for a retry.

Shay Nehmad:

Oh, and also, g 101 is super annoying. Right? You have variables that are named password. I I don't know. In your tests, you save the password to the current test container, and the password is, 12345, just the same as my luggage.

Shay Nehmad:

Right? And then the GoSec will complain, and then you start playing the dance of, okay, so I disable it in in test files. Right? Don't run GoSec on my test files. But then if you store the password, you know, you have a factory function because you wanna create the server for testing in one strain, you want developers to be able to run it locally.

Shay Nehmad:

So it can't be part of your test code because it doesn't compile into your, Go code. Then you have to move it into main, suddenly GoSec is complaining again. So you end up in one of these weird situations where you're trying to be strict but almost all the things that it points out are are not relevant. Right? Bind to all interfaces.

Shay Nehmad:

Yeah. It's a problem but I'm running it in Docker so I'm only exposing one port so I know it's fine. Right? The container is the thing that's limiting the attack surface right now. Use of unsafe.

Shay Nehmad:

Like, what if I need to run some ISAF unsafe code? So I'm like, yeah. 201 usually is great. Right? Don't use a SQL and format.

Shay Nehmad:

But if you're there, you should like, you should already be using, like, SQL c or something. Nobody should be raw dogging SQL in their Go code anyway.

Jonathan Hall:

There's a lot of these sort of things, especially in GoSec, but in other linters too, where they're a great reminder if you don't know the rule already. But once you've learned the rule yourself, you don't need a reminder about it.

Shay Nehmad:

Yeah. I I agree. So the the advice is sort of in this blog post. I think it's laid out pretty well. Starts with the no brainers, very low, effort, high value things that you should probably be doing anyway and then sort of increases in severity or or like how much do you wanna invest in security with the final point being fuzzing which if you don't know a lot about fuzzing is difficult and tricky and time and resource consuming and if you're not doing it in a clever way you might be fuzzing parts of your application that aren't part of the attack surface of the application anyway.

Shay Nehmad:

And it might find failing cases and that's super cool, but I would definitely start with the upper recommendations first before I would go like if you're not running GoSec, run GoSec before you start fuzzing your Right. Endpoints. Right? But I really like this blog post. It's like a very very good checklist and checklists are awesome.

Shay Nehmad:

Right? So really good blog post from, Jacob here. He has a this blog looks really nice. Jacob is also part of Exorcism. He's a mentor there.

Shay Nehmad:

Just a site I like. So shout out, Jacob. Cool, cool stuff. Last thing, on our backlog today is Go Reddit started a hiring board. I don't know if they have always had it and I just was blind, but we put the link in the show notes.

Shay Nehmad:

If you're looking for Go jobs right now, I think Reddit is a good place to find them. Obviously, LinkedIn is the usual place you'll go to, but I think it's cool that the Go community has this sort of thing. I know some meetups do that as well where they post job openings in your local meetups. So wherever you are, look for your Go local meetup if you're looking for a job right now. It's a really good way to find a job.

Shay Nehmad:

Stick around for the ad break and for the super interesting interview with Alex after that. Welcome to our ad break. We wanna run through it really quick because we wanna get to the interview. So to reach us, go to capago.dev where you can find a link to the Slack, the email, all the things. You know it.

Shay Nehmad:

The main thing you can find there other than all the past episodes, the swag store, etcetera etcetera is the link to our Patreon. Thank you all our beautiful patrons for supporting the show, directly financially by contributing $8 a month. This is a hobby and we do it for fun and to learn. I definitely learned a lot today about Phipps. I feel like a Phipps expert didn't know anything about it before this episode but it's also an expensive hobby mostly paying for editing, hosting fees, things like that and Patreon is the best way to make this show sustainable, and we wanna sustain it.

Shay Nehmad:

We're almost at a 2 year mark which is really cool. We also wanted to mention 2 other things. We have a new LinkedIn page. So if the main social media you use is LinkedIn, you can go follow us there. Hopefully, Jonathan wired it all up correctly and the next episode will be published there.

Shay Nehmad:

If not, you know who to blame, not me. And finally, I just wanted to mention, shout out a project called Keep, keephq.dev, developed by 2 good friends of mine. If you're a Go developer, there's a good chance you're working at a company and you have alerts on your system. And if you want to do some AI ops on your alerts, you should check out Keyap. They have a playground and a demo launch, pretty soon on product hunt.

Shay Nehmad:

So, you know, go subscribe there, check it out. If you work in a big enough enterprise, this software is probably relevant to you. They're building really cool stuff all in the open. Unfortunately, not not in Go, but all in the open are very cool. So keep hu.dev.

Shay Nehmad:

Go check them out. And let's go do the interview. Jonathan, you good?

Jonathan Hall:

I'm good.

Shay Nehmad:

Alright. Hello, Alex Schiel. Hello, Jonathan. Welcome to our interview about frogs in pirate suits. I'm excited.

Shay Nehmad:

I don't know a lot about this why are you laughing? Is that not what we're talking about?

Jonathan Hall:

It it sounds right to me.

Shay Nehmad:

Yeah. You said we were doing a FIPS. Is that what it stands for? No? Frogs frogs in the pirate suits?

Jonathan Hall:

Is that actually what it stands for, Alex, or do you have you heard otherwise?

Alex Scheel:

I've heard otherwise. It's federal information processing standards.

Jonathan Hall:

That's boring. I don't talk about frogs in pirate suits.

Alex Scheel:

Sounds like you could, get some mileage with the, bouncy castle team that you talked about. Pirate suits especially.

Jonathan Hall:

Yeah. Yeah. That's awesome. Alright. Well, Alex, thank you for coming on the show and and educating us about what Phipps really is.

Jonathan Hall:

That's the the main topic of our conversation, although we'll talk about other things too. Before we jump into that, would you tell us who you are, what you do, how you're related to Go, and maybe even how you're related to Phipps?

Alex Scheel:

Sure. I'm Alex Shill. I am currently the TSC chair of the Open Battle, project, to support of Hashimoto Vault. I'm employed by GitLab to work on that project, and I have a lot of fun doing that. Previously, I was at Keyfactor where I worked on the bouncy castle cryptographic library which undergoes FIP certification.

Alex Scheel:

Before that, I was at Hashgraph working on vault. Before that, I was at Red Hat where I worked on a PKI solution, called Dogtag PKI, which is commercialized as Red Hat certificate system, which undergoes, both, FIPS simplification and then also common criteria testing as well. So, it has been a bit of history with the FIPS and the various stuff and then

Jonathan Hall:

Yeah.

Alex Scheel:

Obviously, a little bit of go along the way. So

Jonathan Hall:

That's really cool. I I wanna but before we talk about this though, I I I knew that you were involved in OpenBao. I didn't know that you'd worked at HashiCorp before. How do they look up on that? Did you burn bridges?

Alex Scheel:

When I left the first time or well, the only time, I guess. When I left, they were under understanding. Definitely made it about just the license. For me,

Jonathan Hall:

I've worked

Alex Scheel:

at a history of companies that have had very strong positions on open source, and, I am very fortunate to be able to put my money where my mouth is. Yeah. And I had hoped that there was a way that Vault could remain open source. I did not myself start the fork, that was IBM's doing. They have since acquired HashiCorp or started the motions to acquire HashiCorp, which has made this a little more complicated than Yeah.

Alex Scheel:

One would have expected, going into this. But now I started contributing, just giving advice, seeing where the fork would end up. And then with IBM acquiring HSCORP, I seem to have ended up, with the project. So I'm sure, there are people who don't quite look fondly on that, but there are also those who are supportive outside of the company.

Jonathan Hall:

So Sure. Sure.

Alex Scheel:

Depends, I think, on your take on some of this relicensing stuff.

Shay Nehmad:

So basically, going over your employment history, right, or the things you've worked on when the common wisdom of telling developers, oh, don't do encryption. Like, there are smarter people doing it for you. That's you. Right?

Alex Scheel:

I I would argue that there are a lot of smarter people actually doing the encryption. I just try and put the Legos together in, you know, a correct way. But I I try and stay out of the algorithm work myself and do that to the much smarter people in the room.

Shay Nehmad:

Well, I don't know if they're smarter than you, but definitely some people we've had on this show. Right? Like Filippo and the people doing the algorithmic work.

Jonathan Hall:

Filippo Sorda was on a while back. Yeah. Yeah.

Shay Nehmad:

Yeah. Yes. So I I would love to talk about all of these projects, like, in-depth, but we wanted to understand what FIPS is and, like, what's going on with Go and FIPS right now. So why don't you give us an overview? I assume many of the people listening, like, don't know this at all.

Shay Nehmad:

Like, an intro would be useful, I think.

Jonathan Hall:

Talk to us like we're 5.

Alex Scheel:

Cool. So I guess to start, FIPS is a US government standard, put together by NIST. NIST is National Institute of Standards and Technology here in the, US. They put together, I guess, 2 mains volumes of publication around cryptography. They have their FIPS, which is their federal information processing standard collection.

Alex Scheel:

And a fun fact about that is, that section of publications actually, I believe goes up, and my civics is a little missing here, but I think it actually goes up to the Department of, Commerce to sign off on that standard. So think about, you know, all the work that goes into not only just compiling a cryptographic standard in the first place, but then all the governmental, I guess, overhead to get that right and to get that, you know, formally standardized, at the US government level. They also have a different series called special publications, which are more technical documents, I guess, or other technical documents that describe cryptographic algorithms and protocols, and secure ways of using those as well. Why we're here is to talk about a very special FIPS publication, FIPS 140, which has undergone several revisions. 1, 2, 3.

Alex Scheel:

3 is the current latest. And that's really a building block for the government as a whole to standardize algorithms, to, interrupt with non governmental partners. People who sell code to the government, to, who, you know, sell, I guess, airplanes and other things. And these algorithms are kind of the best practices for government to use, outside of the military applications, which are completely separate.

Jonathan Hall:

Mhmm. Okay.

Alex Scheel:

And so they had a bit of a bad rap, I guess, for a long period of time.

Jonathan Hall:

They meaning the government?

Alex Scheel:

Well, the standards, I guess. Okay.

Jonathan Hall:

The standards. Yeah. Okay.

Alex Scheel:

Standards. Reserving government, you know, judgment on the government.

Shay Nehmad:

I think everybody loves the government.

Jonathan Hall:

Who doesn't? What's not to love?

Alex Scheel:

It's something. Yeah. But the the standards, like, in the broader, like, cryptographic community, I guess, especially people who don't work in the government or don't necessarily care about selling to the government, haven't necessarily looked on the FIPS standards, you know, in a generally positive light because they've had a lot of, like, old practices that we've moved on from. For a long time, for instance, they didn't standardize edg 19, Bernstein's elliptic curve that a lot of people generally thought was a good graphic elliptic curve. Instead they have the p series of curves.

Alex Scheel:

They've, I guess, recently did some work to allow HKDF, for instance, otherwise they had some other KDFs that they recommended instead. And so all of this has made the set of standards debatable, I guess, to some whether or not they're worth implementing, outside of government use. What's happened, I guess, is with, especially the Dash 3, there's been a big push to start doing post quantum in there to add some of these other missing algorithms that are generally widely regarded as safe and perhaps even best practices. And so 140 dash 3, as it currently stands, isn't the worst piece of advice. I think it's a fairly sane middle ground, which I know will get me in hot water with some people.

Alex Scheel:

But, what's happened is there's also the now been a little bit of adoption outside of strictly that government sales, the government contractor portion. And you see, people like banks requiring some level of support. You see health care. You see payment processors. And are they mandated to use it?

Alex Scheel:

No. Is it a closest thing they can point to, you know, their execs can point to as a generally sane body of advice probably without having to, you know, reinvent it all themselves.

Jonathan Hall:

Mhmm. Mhmm.

Alex Scheel:

And so having PhIP support in Go would mean you could have those conversations with banks, with health care providers, have testing be done much earlier, much easier when you're building Go software that goes, no pun intended, into those places. And so I'm very excited for this work, for that reason. I guess, to give some more background as well, there are obviously sets of algorithms that are approved. Things like AES are currently approved. Things like DES, aren't, but, ChaCha 20 is also not approved.

Jonathan Hall:

Which is a good algorithm, right? So the fact that it's not approved is actually a bad thing.

Alex Scheel:

Yes.

Jonathan Hall:

Or or not not state of the art at least.

Alex Scheel:

Right. Things like ED 25509, for signing recently got approved, but they were not approved for, dipping home and use, which was an interesting emission. I think they're hoping to fix that in a later revision. But what happens is as a vendor, you take your cryptographic module, you draw a box around it on a piece of paper, and you define some policies and technical writing around this to justify why you think it conforms with this specification. You submit it to a lab.

Alex Scheel:

Lab does some testing on given hardware and kicks off this long process of validation and, I guess, consensus within NIST as well as to whether or not this module meets the requirements of FIPs. And if it does, you get a certification at the end, and that's the piece of paper that these government vendors especially really want, is a certificate that says, yes, your cryptographic module that you submitted perhaps even years earlier conforms with these criteria. And that gives them a bit of safety net, I guess, you know, it's not just anyone saying, oh, I have a FIPs module. It's a standards body actually sitting down and agreeing and reviewing your submission and saying yes.

Jonathan Hall:

Alright. So if I understand correctly, GitLab does their own FIP certification of of Go, of other things, I'm assuming

Alex Scheel:

too? I to my knowledge, we don't do any, certifications of our own cryptographic modules. We rely on other people's Okay. Certifications. So

Jonathan Hall:

extending the question a little bit then, I remember reading, we talked about it on the show maybe a year ago. Microsoft does their own builds of Go that are FIP certified or whatever. So this one, that would no longer be necessary if Go itself does that, is that correct? They wouldn't need to do their own or would they still have reason to do that?

Alex Scheel:

It depends is the short answer of that.

Jonathan Hall:

Okay. So it's over, and we're done. It depends. Exactly.

Alex Scheel:

So there there's a couple of interesting reasons why people do cryptographic module validations. So in general, they're very expensive. I I forget what the actual dollar cost is, but I think for a fresh module certification, it's on the order of a 100,000 Okay. US, which is a significant chunk of money. And so if you don't need it, you won't be doing your own validation.

Alex Scheel:

You try and use a different module that's already certified. So I believe and I haven't validated this, but I believe the GitLab uses other people's modules. For instance, RadHat publishes a module that if you're running on the rel platform, they support and have certified. And so you can go build your Go package on a rel platform and use their open SSL that they've certified. What one of the reasons for doing this, is or for for potentially wanting your own certification is there are different levels of FIPS.

Alex Scheel:

There's level 1, which is the basic, software module, but level 2 and 3 and higher, have additional safety validation guarantees. Things like, are you using a HSM? Can your keys be extracted? Is there tamper evident mechanisms to, say, destroy keys in the event that somebody were to start attacking your HSM with an ax or something. And so for the most part, I believe all the modules in the community are a level 1, and don't necessarily interact with HSMs, hardware security module.

Alex Scheel:

Yeah. It's like

Jonathan Hall:

a YubiKey or something like that? Or

Alex Scheel:

Yeah. They go from, like, YubiKey size level USB devices all the way up to PCIe cards, or, actual, like, rack mounted server like toasters.

Jonathan Hall:

Okay.

Shay Nehmad:

I'm gonna you mentioned that the standard is, like, very good advice and more vendors or or I guess more people are pointing to it as, like, good advice. And Go enabling people to build more secure software is nice. I am wary though, like, I'm sort of confused even. Usually, government regulations tend to lag behind what's going on in the industry, and the only place I've heard about post quantum is government, regulation. How comes this is different?

Shay Nehmad:

Right? It's not like the, the government is especially, useful in regulating, I don't know, TikTok. Right? Because it's just a big organization that's slow to respond. So how comes in crypto suddenly the like, cryptography, I mean, suddenly the regulation is is ahead of the of the industry?

Alex Scheel:

Yeah. I guess for a couple of reasons. I guess I would be a little hesitant to say it's very good standard. I think it's an adequate standard. I don't know that we have a much more comprehensive standard to point to that, you know, follows modern advice otherwise.

Alex Scheel:

But the the reason why, I guess, they're worried is, there's this thing, that a lot of people are worried about called a store now, Decorplator attack, hold down Decorplator attack. This is especially interesting for governments, as they have a lot of particularly sensitive information that they don't want to leak. And so to some extent, this post quantum push is a natural result of having that type of data, having the resources to pull together a bunch of academics, a bunch of people in act industry to start thinking about this to start solving it. And it takes a lot of time to go, you know, get this stuff deployed. I was at a talk at the University of Michigan recently, by Whit Diffie, and he gave a number somewhere on the order of 75 to a 100 years for a cryptosystem from the time it's initially, like, conceived in the mind of a researcher, much less published and studied to, you know, standardized, to deploy new applications, to, you know, encrypting that first set of data, to how long that data needs to be secure for.

Alex Scheel:

And so, I mean, groups like Microsoft and Google and others are definitely involved in the post quantum process, because they have that types of data, but perhaps your health care in, I guess, hospital, I guess, doesn't necessarily have the resources to be thinking on that time horizon despite arguably having that.

Shay Nehmad:

Well, if my hospital is worrying in a 100 what's going with my data in a 100 years, it better be a really good hospital because it's gonna keep me around till I'm a 130.

Alex Scheel:

One might hope. But, wait.

Jonathan Hall:

Okay. Just to play devil's advocate though, I mean, if they have information on, say, genetic

Shay Nehmad:

your genetics.

Jonathan Hall:

Right? That could affect your children, your grandchildren, and maybe they don't want that out even if you're not still around. So

Shay Nehmad:

Well, my genetics do affect my children. Sure. But that's that's what they're there for.

Jonathan Hall:

If you have some some heart defect genetic heart defect or something, your your children may not want that to be public knowledge, for

Shay Nehmad:

your children. No. I agree. So there are groups that are involved with it already, and it's an adequate standard, not a not a good one?

Alex Scheel:

I think so. I think it does the job well enough now, like, at the current set of revisions to not argue with it too much.

Jonathan Hall:

So even that's an accomplishment considering that it wasn't long ago when, I remembered these t shirts that were popular on the US is that this t shirt is ammunition because I had a little pearl script on it that, you know, is encrypted stuff.

Alex Scheel:

Yes. I I think that, goes back to I mean, part of the reason why this is possible is that open source exception to, you know, export control

Jonathan Hall:

Mhmm.

Alex Scheel:

That lets go publish cryptographic libraries in the first place even. And so I I'd rather take the world we're in than, the world than, we can't have any people at all or much less share it with our neighboring countries.

Jonathan Hall:

Right. Right.

Shay Nehmad:

This is another sort of reason, obviously, when we're talking about the government standard related to cryptography. On the one hand like, a reason I'm suspicious about it. On the one hand, I'm happier for the, I don't know, US, government as I am currently part of the western world to control, like, what crypto you can and can't do but, you know, you'd name dropped a Diffie of Diffie Hellman fame, I assume. So, you know, I can name drop Snowden on the other side and say, oh, this standard is really great at keeping everybody but the US not private enough. So, you know, they can decrypt anything else they want.

Shay Nehmad:

Although, this is sort of the other way around. Right? This is for US government agencies. So this is sort of trying to promise that nobody else can have a backdoor. Hopefully, this standard doesn't include some, oh, and you have the US, like, the president can turn 2 keys and then, you know, they can read everything.

Shay Nehmad:

Right?

Alex Scheel:

Correct. Yeah. It doesn't have that. And it's much different than an export control in that it's, I guess, it's not even really an import control, but it's a a sale to the government control. You have, you know, in any nation, even inside the US, you have no requirement to comply with this particular standard, unless you happen to be doing sales to the government.

Alex Scheel:

And so from that standpoint, it doesn't, like, it it doesn't, you know, behave like the export control of, I guess, eighties nineties and earlier where you couldn't have secure cryptography. This is not restricting what other cryptography you can use. It's just, you know, in particular pieces of software for government use, you should use only this set of approved cryptography.

Shay Nehmad:

Cool. So so putting my tinfoil hat aside for a moment and talking about the positives here, the fact that Go you know, there we have people in Go and even things going into the standard library that make it easier for me as, you know, not cryptography person, develop FIPS compliance software means that for me, it's gonna be easier or my company, it's gonna be easier to sell software to the government that's up to the government standards. Right?

Alex Scheel:

Precisely. Yes. And so there's a lot of, you know, components that go into that, like the TLS stack, you know, has some behavior changes, some algorithm changes that need to occur in fixed mode, that you no longer need to care about if you just set this one flag. And it's very, I guess, for lack of a better word, progressive move by the Go community because not a lot of other languages have first class support. If you build in CE, there's no first class crypto library except pulling in open SSL or NSS or Gnu TLS or whatever, you you know, crypto library and building around that.

Alex Scheel:

And then you have to go find somebody who certified that library either through the open SSL foundation or through your distro. If you're using JAMA, you can pay Oracle lots of money, and go use their desired FIPS library that they ship with the language in the Oracle JDK. But in open JDK, there is no FIPS module. In Rust, I don't believe there's currently a standardized chips module. I think people are building on top of boring crypto and

Shay Nehmad:

Not not a hate on Rust, but there's no standardized many things in Rust. Right. And the things that are that are suggested to go into the standard right now are keywords like yeet. So, you know, I I don't wanna hit on it too much, but

Jonathan Hall:

You do. You do. On the

Shay Nehmad:

one hand on the one hand, it's it's probably good for very low level things that you'd wanna do because of a lot of, a lot of benefits. And it's mature enough, I think. But I don't know if I want all of my government stack to run on on on Rust.

Alex Scheel:

Well, it might be better than c. But

Jonathan Hall:

For sure. Oh, but

Shay Nehmad:

it might be better. Well, my government doesn't have the FIP standard, but for sure, like, anything would be better. You know what? I'm just hating the recent government websites redesigns in Israel have actually been okay. They've been okay.

Jonathan Hall:

I I wanna ask another Phipps related question. So we talked earlier about, very briefly about the sort of the process of getting certified. I'm curious, like, what is the unit of certification? Is it the SHA library? Is it the entire Go project?

Jonathan Hall:

What what is the unit that needs to be become certified?

Alex Scheel:

So it depends a lot on what you're doing. In general, you draw a box just around the cryptographic components that you want certified.

Jonathan Hall:

Like individual components? Like the the RSA module, the DSA module, the SAU module, or like this is the crypto library.

Alex Scheel:

A crypto library as a whole usually.

Jonathan Hall:

Okay.

Alex Scheel:

There are a few places where individual components have been certified. My favorite is, this library called jitter entropy, which chain guard recently put in some of its container images. It's just a random number generator. Okay. Just nothing else.

Alex Scheel:

It has, like, a hash function in there, obviously, because you need, you know, something to build on to

Jonathan Hall:

Mhmm. Mhmm.

Alex Scheel:

You know, build a secure random number generator. But it is literally just a random number generator and a hash function. Nothing else. No, like, public key cryptography. No, you know, ace no symmetric, you know, ciphers.

Alex Scheel:

Just a random number generator. It's it's nice because you don't have to rely on your kernel for random anymore. You can, you know, rely on this module and have it be compliant. But in general, you draw a reasonably boxed a reasonable box around your cryptographic primitive. So your random number generator, your hash function, symmetric ciphers, your asymmetric ciphers, your Diffie Hellman, and you standardize just that.

Alex Scheel:

And the reason why is every update to this requires a recertification. If you have a security vulnerability in something, you need to change your code and thus submit it for recertification. And so there's kinda 2 I don't think I've touched on this, but there's kinda 2 sets of consumers of FIPS modules, for lack of a better word. There are those that require the strict certification. So certification runs on a particular hardware platform.

Alex Scheel:

It's against a particular version of code, and you can't make any modifications outside of that scope. There's others that kinda want FIPS compliance, which is a looser kind of term that says, hey. You generally comply with what's in that standard. You may or may not have a in flight certificate, but we want our security patches because you're you're practically insane to be running, you know, anything these days without security patches. And so that's part of why the proposal from Russ talks about this difference between FIPS, you know, in process versus FIPS, certified.

Alex Scheel:

And so a lot of people want those security updates and so aren't going to be running strictly the standardized version because it takes many months to years Yeah. To get a final standardized version.

Jonathan Hall:

So as an example, if if a vulnerability is discovered in a particular SSL library or something, you you might be running that vulnerable version for months until that is recertified, which kind of defeats the purpose.

Alex Scheel:

Right. And so I believe I haven't dug quite that deep into this GoProposal, but I believe, they're just certifying the primitives. And so TLS is not certified in the scope proposal, I believe, from what I saw, based on the vulnerability count, because there have been more than 4 vulnerabilities in TLS over the last Yeah. Couple of years, 5 years. So I believe TLS is sitting outside of that boundary so that they can ship updates to that TLS stack without impacting VIP's, status.

Alex Scheel:

And so I think they're doing it rather well in the, Go community do this. And I know, Shai, you have different thoughts about Rust, but one of the cool things about, the way, Flippo is doing this is, it enables Rust to eventually seek its own certified crypto module using pure Rust. Go is one of the first non c, non Java, non hardware security module things to undergo this very dynamic language, I guess, is phrase that, that's being standardized. And so it'll be cool to see some of these other languages in the future potentially pick up native Phipps modules as well.

Shay Nehmad:

Yeah. Just to clarify, I I really enjoy Rust. It's just, not it it it's just nice to be on a go show and, like, no shit on on other languages. You did mention you did mention something interesting, like, something that I'm interested in. So this actual security requirements document is is not that long.

Shay Nehmad:

Like it's 11 pages which really surprised me. I don't know if if I'm looking at the wrong thing or something because it it sounds like it's books and books of of actual things I have to do to be FIPS compliant. What, document should I be looking at?

Alex Scheel:

So are you looking at the FIPS 140 dash 3 published document? Yeah. So it's kinda like an RFC in that regard. Right? If you go to your your, is it 855?

Alex Scheel:

For whatever the, you know, the t l s 1 dot 3 RFC is, you you read that RFC, and you're like, oh, that's not bad. And then you start implementing it, and you realize, oh, I need crypto algorithms. Oh, I have to go read all those other documents about that. Oh, I need ASM 1 parsing. I need to go read all those other things.

Alex Scheel:

Oh, I need to know about x509. Oh, I gotta read 5280.

Shay Nehmad:

Oh, so It's

Alex Scheel:

a lot of references. I think FIPS 140 dash 3 also deviated from, dash 2 in that they moved to a lot of ISO specs. And I believe a lot of those are paywalled, which makes it also a little entertaining. But what happens is FIPS 140 dash 3 is more of an entry document in that you get kinda your top level pointers, and then you fan out from there into all of the various crypto algorithms, key sizes, and other documents, that you want. So, like, I believe, s p 800 56 a talks about

Shay Nehmad:

Yeah. I suddenly see all these, references. I was mistaken. This is, this is complicated. Well, we'll put the link in the in the show notes.

Shay Nehmad:

And if somebody finds the paywall documents off a truck and dumps them, in our Slack, Unless that means, CIA agents are gonna come for our houses, that's totally fine by me. And but because I don't have the full standard in front of me, obviously, a lot of the standard, the things we mentioned are about math. Right? You have to adhere to certain like, your encryption shouldn't be shouldn't be broken by something that's, you know, quantum or something like that, post quantum. And there it's a lot of algorithmic stuff.

Shay Nehmad:

Is there anything in the standard about the software delivery life cycle? Like, you must use SBOMs or even coding standards. Like, you must have a code coverage a 100% and you gotta run fuzzing and you gotta run, I don't know, go test minus race on all your implementation. Like, is it, does the, FIPS standard include some code quality standards?

Alex Scheel:

There are I don't have a reference to those off the top of my head. They're not quite as comprehensive as one would like. So one of the things that the cryptographic community really has, the modern cryptographic community is really standardized on, is a formal verification of both algorithms and protocols, and FIPS doesn't yet require that. And so from that standpoint, there are gaps, definitely. They do do some testing throughout this.

Alex Scheel:

One of the really cool things that NIST has, that you can actually send an email and get access to is a testing server where they have a series of they implement this protocol where you can send queries to the server for various challenges, based on different algorithms. And then you can send back your responses and it tells you whether or not your algorithm is implemented correctly. So it does like a mix of standard, like, test cases and, like, RFCs, but also random test cases and then edge cases. Like, is your, you know, key size off by 1 somewhere, in your signing protocol, or have you forgotten to implement, like, a given modulus and some elliptic curve implementation or something. They have a lot of these different test vectors that they subject these modules to, and it kinda splits the FIP certification process into 2 parts.

Alex Scheel:

There's an algorithm certification, and then there's a combined module certification. But a lot of the things like SBOM type stuff and other, like, software delivery requirements are really rolled up into larger standards like common common criteria or FedRAMP or other kind of government adjacent top level software because they want more than just the crypto module to comply with it. Right? We we've put, like, SHA and, you know, whatever else in the small little box and said, this is standardized, but you're not using just sha in your Kubernetes application. You're not using just sha in whatever you want your entire, you know, health records application to comply with more than that.

Alex Scheel:

And so that tends to roll up in a larger government requirement then.

Shay Nehmad:

Yeah. We're using a really great SHA function implemented in Go, that, Filippo validated. But the web app is like node models. Yeah. We just grabbed all the node models we could find off the shelf in NPM and install them.

Shay Nehmad:

Whatever.

Alex Scheel:

And and so, there's a bit of that in FIPS, but it's not quite as end application focused as you see in other places.

Jonathan Hall:

I wanna ask and you may not know the answer because we haven't seen the the final version yet, but what will like the daily use of this be? Obviously, most people won't need it. They could just use the defaults, which is go FIPS 140 equals off. But if you need to use it, what's that gonna look like? Like, how's that gonna change someone's daily workflow?

Alex Scheel:

I think the biggest component is that you'll set, it looks like you're setting a new environment variable, potentially called gophipps, and you'll set it probably to latest, or in progress or whatever value they've chosen that roughly means that, that will be it. You'll get a Linux binary out of that, presumably standardized and very certified on a few platforms, which you could tell your customers about if they care to. But then, it mostly just limits which platforms you're gonna get that final binary on. It won't be certified on Mac. It won't be certified on Windows.

Jonathan Hall:

Okay.

Alex Scheel:

And so I think there might you know, coming back to that point about Microsoft's toolkit toolchain, there might be a case for why that toolchain continues to live, because they support the Windows native cryptographic. Is it CNG, I believe? The latest, or the cryptographic library that Microsoft ships and certifies on Windows.

Jonathan Hall:

What so what I mean, hopefully this is a rare situation. I'm sure it would be by design. But what happens if an API changes in some of the crypto libraries? And so I'm like go so let's say go 1.26 includes a new fancy crypto method, whatever it is. But the certified versions don't.

Jonathan Hall:

Is that is that just gonna mean that like that that seems like a weird situation. Like like you have a different standard library available depending on whether Phipps is on or off seems to be like the obvious repercussion. Do you have any idea how that would be resolved?

Alex Scheel:

So long term, if that algorithm is FIPS, you know, compliant, it will probably kick off a recertification process on the part of the Go team. And they'll, work to include that new algorithm in their module and then swap that over once that's complete. Before then, it depends on the value of your, dips and 40 debug flag. And if you set yourself to strict enforcing mode, that algorithm will panic Okay. And you won't be able to use it.

Alex Scheel:

If you set yourself to the, hey. I wanna be mostly FIPS compliant version of the flag. You'll still be able to use that algorithm. And so it kinda depends on that conversation with your customers at that point. Who are you selling to?

Alex Scheel:

What do they want out of it? You're selling to banks and health care industry. They may not care about strict FIPS certification compliance, And so you're probably more likely to set that value to a more, accepting flag Right.

Shay Nehmad:

Right.

Alex Scheel:

Versus and you might actually be able to pick up that algorithm, and they might take use of it Mhmm. Depending on their own internal policy because they aren't required to comply with it strictly.

Jonathan Hall:

Right. Right.

Alex Scheel:

Whereas if you have a lot of defense contractors and the like, you might set it to a more strict enforcing mode Right. And then panic. Cool. It's not ideal, but

Jonathan Hall:

Yeah. Yeah. But but, you know, what else can you do?

Alex Scheel:

Right. What else can you do?

Shay Nehmad:

So if Phipps is so good and it's built into the standard library, why don't I just turn it by default on all, like, my applications and then I'll be more secure? So I don't know. The chat messages between, Jonathan and I could be post quantum, saved.

Alex Scheel:

I think one of the biggest reasons why you might not want that is because you take a bit of a performance hit. Every key generation operation requires you to validate that your key material is good, which typically involves doing a full, like

Shay Nehmad:

You like send it in an envelope with USPS? No.

Alex Scheel:

No. No. You're not sending them up to your government yet, but,

Shay Nehmad:

you local representative.

Alex Scheel:

No. But something like, you know, verifying that you can encrypt and decrypt successfully with it. There's a lot of startup tests, and so your startup time for your app will be a little slower than on non FIPS builds. And so there's a lot of these weird performance differences, I think, that you'd see that are expected if you're operating in this kind of FIPS world, FIPS environment. But where if you're looking strictly for, you know, fastest numbers, you know, impressing your users the most, you might suggest turning it on.

Shay Nehmad:

So even if I if I'm let's say I'm a business and I do sell to you a federal entity and but I also sell to just a commercial entity that doesn't require FIPS. Right? Just like an e commerce store and they don't care about post like post quantum whatever.

Jonathan Hall:

Right.

Shay Nehmad:

I should give the the non FIPS build to the e commerce guys because they're gonna get a faster product, and they just honestly don't care about, this sort of thing.

Alex Scheel:

Correct. And the other thing with Post Quantum in particular is Go is making improvements for everyone. It's not just for the Phipps. People, FIPS just happens to be the body that's driving the bulk of the post quantum standardization work, and so that tends to be where this comes down from. But, Go is making changes for everyone in the post quantum side.

Alex Scheel:

That will be very widely regarded once they land. And so even your postal customer or whatever your your mailing, your shipping company will be able to take advantage of non FIPS post quantum work and probably be happier without the FIPS build in general, due to the performance.

Shay Nehmad:

Cool. Cool.

Jonathan Hall:

Yeah. Well, I have to say I have a whole new appreciation now for frogs and pirate suits.

Alex Scheel:

I do too.

Shay Nehmad:

Oh, you remember the joke. So we usually ask our interviewees to sort of layout, oh, where can people find them? But I'm gonna go ahead and say that for you because the domain is just fire cypherboy.com.

Alex Scheel:

That is me.

Shay Nehmad:

Dude, that is absolutely fire.

Alex Scheel:

Thank you. I've had it for a bit, and it only cost me, what, $12 a year for a dotcom domain. So as long as somebody else doesn't outbit me, I'm happy.

Shay Nehmad:

In there, you can see a picture of Alex with his violin, which we haven't even mentioned. But you're like a violinist in an orchestra or something? I don't remember.

Alex Scheel:

No. I I just play for fun. I've been playing since I was a little kid and fortunate that I've been able to study with a lot of really great musicians who are in these top orchestras here in the US. And so it's kept me very well entertained and out of trouble from time to time.

Jonathan Hall:

Awesome. How how often do you play?

Alex Scheel:

I practice every day. Nice. For a couple hours, if I can, or 30 minutes if I can. So Yeah. It's a lot of work to keep up with it, at a high level, but, it's very rewarding.

Alex Scheel:

So, it's something completely different than running code.

Jonathan Hall:

Do you have any recordings of your of your performance that we can listen to?

Alex Scheel:

Dude, they're old. So, I've improved a lot since I was last doing recordings. I hope to get back into it. Okay. I have a nice

Shay Nehmad:

They're only FIPS 1 compliant. The strings are not. Strings haven't been, you know, wound in a government controlled facility.

Alex Scheel:

Not yet. But, one day I would like to get back to doing some recordings. So I've

Shay Nehmad:

actually found that a lot of people in tech, are musicians. More than, I think, the their normal share in just, like, you know, gen pop. Do you think like, I don't know if there are any studies on that, but have you found the same? Like, you are surprised by the amount of people you work with that, play an instrument?

Alex Scheel:

Yeah. I think also, it's, you know, rather hard to make a living in being a pure, like, performance major or musician. And so a lot of people find themselves in other hobbies or other professions that, you know, can pay the bills and let them keep up with their hobbies. And so I think tech is a outsized one. There's also I know a lot of people tend to harp on the music and math, you know, kinda overlap, but I think tech is just enough of a you know, if you find the right place to work, I think you can balance your time a lot better than perhaps medical or legal professions.

Shay Nehmad:

Sure. If you're a teacher, it's gonna be hard to find the time to to play music.

Alex Scheel:

Right. Yeah. So

Shay Nehmad:

Wait, Jonathan. Do you play anything?

Jonathan Hall:

No. I I had a guitar for many years ago. I can I can play a couple tunes, but nothing nothing to impress anyone?

Shay Nehmad:

Well, we still outnumber you, here on this call. I'm comfortable with that. Yeah. So people can find you at cypherboy, dot com. Anywhere else they should be, looking or or anything you wanna plug.

Alex Scheel:

Openbound.org, is the, forkliftash code vault that I spend a lot of my time working on and which I will be definitely looking forward to this FIPs and 480 work, to use. And so

Shay Nehmad:

Yeah. And it's generally available. Like, everybody can seriously consider it. Right?

Alex Scheel:

Right. It's, we, GA'd, back in, I believe, August or July. And we have also, we'll we'll be putting out another GRE leaks here in the end of the month. So, I definitely welcome all feedback on it. So Cool.

Shay Nehmad:

Very cool. Very cool.

Jonathan Hall:

One last question, The one we ask all of our guests. When you started learning Go, what surprised you the most or what was the biggest challenge?

Alex Scheel:

Yeah. So the reason why I picked up Go in the first place was, I was in college and I ran across these challenges, called the CryptoPals challenges. Mhmm. And I was doing a lot of c and Java work and just not really enjoying that. And so I was looking for a different language to do that in, and I thought Go was a nice language.

Alex Scheel:

I it always strikes me as a language that no matter what the application is, I can generally look at the code and get a good sense of what it does without a lot of overhead or thoughts, and it didn't have as much like, for being a language where the crypto stuff was supposedly, like, really good. It didn't have a lot of tools to go solve some of these crypto palace challenges as I would have thought. Some of the things were just a little weird at the time. Now this was back in 20 eighteen, so I'm sure a lot of the language has changed, and I'm sure my own programming has changed a lot since then. So, but no.

Alex Scheel:

I think it just struck me as odd that, like, some of these low level cryptographic things that it was trying to do to solve these challenges just weren't there. Like, the algorithms were there definitely, and you could build up on that with, you know, very lovely protocol work. But, like, the low level, like, bit manipulation and some of the fancier math around, big numbers and stuff just wasn't quite what I wanted. Yeah. Yeah.

Alex Scheel:

But, otherwise, I really love language and enjoyed working in it.

Jonathan Hall:

So Well, I like that insight. I don't think I've heard that answer from anybody before. So that's it's nice when we get a new a new answer.

Alex Scheel:

And it could just be that I was sticking to a standard library and avoiding, you know, too many, third party packages at the time. So it was probably my fault more than anyone else's.

Shay Nehmad:

Alright. Well,

Jonathan Hall:

hey, Alex. It has been a pleasure to have you on. It's great to meet you and talk about your your hat collection and your violins and and tech as well. Yeah. Thanks for taking the time.

Alex Scheel:

It's been a lot of fun. Thank you very much.

Shay Nehmad:

Great. Thanks. Next up. Goodbye.