2024-03-31 00:15:03 So I've been on a crypto binge lately, and this afternoon I decided what I think the #1 job responsibility of the crypto community should be. They need to move us past this "never roll your own crypto" era we seem to be living in now, into one where the best wisdom is "always roll your own crypto, using best available open source tools designed to help you do that." 2024-03-31 00:15:21 They need to turn it into something that it is feasible to reliably do well on your own. 2024-03-31 00:15:51 And that should include generating your own unique and properly functional "magic numbers" that might be involved. 2024-03-31 00:16:11 pi, for example 2024-03-31 00:16:15 The need to trust ANYONE external to your own organization needs to be gotten rid of. 2024-03-31 00:16:45 bad news about those external deps cough lzma cough 2024-03-31 00:17:01 One person should be able to do it. Get the suite construction tools, run them, and wind up with your own personal setup that only you know the important details of. 2024-03-31 00:17:42 And of course those tools should be open source, or else the trust problem isn't really solved. 2024-03-31 00:19:21 I'm still just shaking my head over the way the world accepted an encryption standard that MANDATED the use of particular government-specified numbers. 2024-03-31 00:21:09 pretty sure NSA kinda rammed through through the process, but that might be the sour grapes side's story 2024-03-31 00:21:40 (patent encumbered stuff has also been rubber stamped by IETF) 2024-03-31 00:21:44 Probably, but the notion that anyone thought of it as "secure" for even a second blows my mind. 2024-03-31 00:23:17 the crypto and infosec communities are both bogged down with "this is too important and you're not smart enough to do it right, you must use tools made by the experts" and the experts produce things like gpg that nobody can figure out how to use 2024-03-31 00:23:30 Yeah - we need to get past that. 2024-03-31 00:23:40 agree 2024-03-31 00:23:44 good luck 2024-03-31 00:23:51 No kidding. 2024-03-31 00:23:53 openbsd wrote signify for packages instead of rolling with PGP or whatever 2024-03-31 00:24:18 I'm sure if anyone ever started making real progress in that direction they'd encounter all kinds of... impediments. 2024-03-31 00:25:38 such as DARPA pulling your funding? (hypothetically, but that was probably due to Theo bad mouthing some adventure in iraq) 2024-03-31 00:26:16 That, or having some nasty scandal allegedly involving you pop up in the news, or whatever. 2024-03-31 00:26:31 Wind up on the wrong end of a "wrong address" police raid... 2024-03-31 00:26:51 Whatever it took, basically. 2024-03-31 00:28:10 That happened at one point to a Canadian guy who was working on a distributed file storage system that had a side feature of potentially exploding the number of Tor nodes active in the world. 2024-03-31 00:29:21 I've felt for a long time like Tor is tolerated primarily because so far the government is able to run enough server warehouses full of Tor nodes to stay on top of it. 2024-03-31 00:33:42 latest @ >body >pfa >hfa >dfa ( this is kind of terrible) 2024-03-31 06:05:14 which python 2024-03-31 06:05:16 Ooops. 2024-03-31 06:05:18 Sorry. 2024-03-31 06:35:16 Hey, anyone familiar with sshuttle? 2024-03-31 06:35:36 It kind of "wraps up" network forwarding. 2024-03-31 06:36:13 I just used it to forward all of my net traffic through my seedbox over in the Netherlands. 2024-03-31 06:36:59 speedtest.net showed about 350 Mb/s download speed with my standard connection - that went down to about 200 Mb/s forwarded. 2024-03-31 06:37:06 That's still pretty good, though. 2024-03-31 06:37:35 Command is simple: sshuttle --dns -r user@host:port 0/0 2024-03-31 06:38:38 Checked whatsmyip and the ip reprot from speedtest.net; they both confirmed the traffic was forwarded. 2024-03-31 06:43:14 It's better than the standard port forwarding you do with ssh directly, because that winds up being a sort of "TCP over TCP," which is not terribly performant. 2024-03-31 06:44:26 KipIngram you on the right channel? 2024-03-31 06:44:41 Looks right. 2024-03-31 06:45:19 It wasn't really meant to be "topical" - I just thought it was a neat package and wanted to mention it in case anyone hadn't heard of it. 2024-03-31 06:46:17 Haven't really been Forthing a whole lot recently - I've been kind of off on a cryptography binge. 2024-03-31 10:55:18 Al2O3: he's one of these "the topic is just a suggestion" types 2024-03-31 14:36:33 Well, more just someone who's been around here for 10-12 years (or more? - I lose track) and has watched how the channel tends to work. 2024-03-31 14:36:58 Take a stroll through the log sometime - you'll find quite a lot of things getting talked about. 2024-03-31 16:56:12 https://www.youtube.com/watch?v=jqjtNDtbDNI 2024-03-31 16:56:14 Wow. 2024-03-31 16:59:28 Yeah, have you not seen the kerfuffle? :P 2024-03-31 17:15:24 No, I don't actually "monitor" this stuff very systematically. Just stumble onto things now and again. 2024-03-31 17:15:54 I can't say this one surprises me either, though - open source is... well, OPEN, and of course sneaky players are going to try to pull things. 2024-03-31 17:16:16 We just have to be ever vigialant, and it sure would help if we would stop making things more and more complicated and keep them "easier to inspect." 2024-03-31 17:16:44 I can't even really follow makefiles anymore - they just kept making that more and more obtuse over the years. 2024-03-31 17:16:55 Originally it was SO simple and common-sense. 2024-03-31 17:17:40 I understand that the stuff they did they felt "made it easier for developers," but the people it needs to be easy for is the mass of the general public that you hope will help you make sure things like this don't happen. 2024-03-31 17:17:54 When it becomes "experts only," you lose a lot of your public vetting. 2024-03-31 17:18:24 This thing is a compression format and I'm not entirely sure what benefits it has over e.g. zlib 2024-03-31 17:19:01 Maybe "slightly better compression" shouldn't be enough to add more code which has to be maintained 2024-03-31 17:19:03 Yeah, exactly. For our really important tools (security important) the emphasis should be on solidity and simplicity, not performance, feature richness, etc. 2024-03-31 17:22:12 Apparently this one was tricky - the back door wasn't actually in the utility source. That would have been obvious. Instead, part of the test rigging overwrote the compiled result after the fact. 2024-03-31 17:22:22 but maintaining stuff isn't resume enhancing, while making new and bigger bloat is 2024-03-31 17:22:32 Yeah. 2024-03-31 17:26:27 It's usually easy to see how forces like that drive us down these roads. I've got all these complaints about how we evolved our processors over the years, but it's absolutely clear how economics pushed it exactly the way it went. 2024-03-31 17:26:54 He who can run your legacy C code fastest wins. 2024-03-31 17:55:27 KipIngram> Apparently this one was tricky it's worse than that. the backdoor targets sshd, which normally doesn't link with liblzma, but does on debian systems because debian patches sshd source to link with libsystemd so that it can send systemd daemon notifications, and libsystemd pulls in liblzma 2024-03-31 17:56:04 in my opinion there are a ton of lessons the open source community could learn from this. will they? doubt it. 2024-03-31 17:57:34 also, xz isn't exactly the new hot fad. if you guys had never heard of it before now, you might be living under a rock. 2024-03-31 17:59:00 but i will say this is exactly the kind of shit that has me interested in forth 2024-03-31 18:00:55 i've never been comfortable with gnu autotools and the unintelligible soup it spews out, i've never been comfortable with the binaries gcc produces and the amount of junk that goes into them that i have no idea what it's for, and i've never been comfortable with embedded build systems like yocto that allow teams to pull in random source from the web without ever actually seeing the source, and then it 2024-03-31 18:01:02 goes into your embedded OS and pulls in who knows what dependencies and if you give any shits about security whatsoever you're fucked 2024-03-31 18:02:27 (p.s. the libsystemd link can be replaced with about 20 lines of C, with error checking and whatnot) 2024-03-31 18:02:50 yeah, i don't doubt it 2024-03-31 18:04:47 this is exactly the sort of nonsense that's why what i'm practicing now in my spare time is to hone a development pattern that looks more like this: you write a very small forth environment in a single ISO C99-compliant c file (i'm currently keeping mine under 1K LOC), and then you use that forth vm to write your target compiler for whatever platform you want 2024-03-31 18:05:01 and then you write your application there 2024-03-31 18:05:18 all tracked together in one repo, all kept very small 2024-03-31 18:06:42 right now i'm building small minimalistic ELF binaries for linux, and it's actually not that hard. my assembler is just a little over 200 LOC, the platform/elf header/core vocabulary part is almost 300 LOC 2024-03-31 18:07:04 the core is incomplete though, so that will get bigger. but the point is, it doesn't actually take much to do this. 2024-03-31 18:07:16 https://bootstrapping.miraheze.org/wiki/Main_Page 2024-03-31 18:09:59 GeDaMo: i lost a lot of time in this circular chicken/egg stuff trying to achieve a self hosting portable do-it-all compiler like the "real compiler guys" like to achieve 2024-03-31 18:10:27 it was a huge leap forward for me to finally reject those people and those papers and settle for less 2024-03-31 18:10:48 I think small core is the right idea 2024-03-31 18:11:46 for me, i think the "light bulb" moment was when i quit trying to imagine a very abstract, retargettable thing like llvm or gcc, and instead started thinking of it as a macro assembler where your macro language is forth 2024-03-31 18:12:18 everything gets real simple when you look at it that way 2024-03-31 18:32:07 zelgomer: Agree with lots and lots of that, especially the discomfort with modern build tools and so on. 2024-03-31 18:32:24 I share those feelings quite a lot. 2024-03-31 18:32:59 I remember when it clicked how the Forth assembler worked, it was just appending bytes to the dictionary 2024-03-31 18:33:15 I knew that machine code was just bytes in memory but it seemed too simple :P 2024-03-31 18:33:19 I don't feel like I can truly truly trust something unless I've done it myself. In theory I could study something done by someone else carefully and come to trust it, but kind of the pont here is that that has become harder and harder to do as they continuously complicate this stuff. 2024-03-31 18:34:22 And Forth makes it easier to do things myself, which is exactly why I like it so much. 2024-03-31 18:40:02 GeDaMo: the other "click" for me was the cmforth { } style target switch 2024-03-31 18:41:26 I don't think I know that one 2024-03-31 18:41:51 it wasn't enough for me to just read "oh he uses { to define target words and } to switch back to host words". the part that i've never seen clearly explained, and maybe cmforth doesn't actually leverage this because i don't think he was using it to cross-compile, but in my case, the magic of { } is that it gives you a way to build "hooks" into your assembler 2024-03-31 18:42:00 Ah, the metacompiler thing 2024-03-31 18:42:49 I've done something similar with HOST and TARGET vocabularies 2024-03-31 18:44:01 whenever i've done this in the past, i struggled with it because my assembler source makes use of "create , c, does>" type stuff to actually implement the assembler itself, so you can't just redefine , and c, to go into the target image. simultaneously, you /have/ to define them so that when the assembler is /actually assembling/, it needs to use "," and "c," to write into the target image 2024-03-31 18:44:42 so you could just go "okay there are new words, 't,' and 'tc,' for writing to the target" and then you define your assembler in terms of those, but that's ugly 2024-03-31 18:46:47 i use { } as a way to define an overlay vocabulary, then i load the assembler, so i get to do stuff like this: imm8 r8 :noname 80 assemble, { c, } ; when 2024-03-31 18:47:15 the magic is that if { c, } has been defined before the assembler source is loaded, then it uses that. if it hasn't, then it falls through to the host c, 2024-03-31 18:47:32 and elsewhere in the assembler source i use c, that's not wrapped in { } to build host words 2024-03-31 19:31:38 Yeah, sanely separating host and target access in Forth isn't the cleanest thing in the world. 2024-03-31 19:32:31 It's usually pretty clear what we want to do, but getting it so that you can cross-compile target code on the host and then later meta-compile that same source on the target is kind of clunky. 2024-03-31 19:34:31 So does anyone make an "RSA dongle"? I'm picturing a USB stick that will mount as a storage device, that you can somehow get your private key or keys into - it would then never ever allow those to be read back out. But you could drop documents onto and the stick itself would do your private-key-dependent RSA actions for you. Drop the plaintext on and the cipher text would just appear and could be read off. 2024-03-31 19:34:50 That should be a fairly simple device - that's the kind of thing I could actually make for myself if I wanted to. 2024-03-31 19:35:45 And yes - I do see that establishing that private key and getting it securely stored in the first place would be subject to all kinds of attack vectors. 2024-03-31 19:36:10 But I'm quite confident that I could make it so once it was in there it would never come out again. 2024-03-31 19:36:29 I guess the right way would be to actually generate the key pair on-device. 2024-03-31 19:37:05 So, a "canned GPG" system? 2024-03-31 19:37:29 Seems like that could completely dodge all the possibilities of back doors on your computer, etc. 2024-03-31 19:37:48 And Forth would be a great dev language for that. 2024-03-31 19:38:53 I guess a thing to watch out for would be all these ways people use power consumption and so on to ferret out keys. 2024-03-31 19:39:21 Ideally you'd design it so it always consumed exactly the same amount of power - just flat as a board - even if that meant wasting some of it. 2024-03-31 19:39:34 Make the timing of all the various paths the same, etc. 2024-03-31 19:40:27 If I had one of those and use it routinely, I'd put it on a leather string and wear it around my neck. 2024-03-31 19:51:12 yeah I been debating with a local hacker about if such a computer is posdible 2024-03-31 19:52:56 I say it is because stuff like sram cells work as latches but dram cells dont 2024-03-31 19:53:57 a sram cell always consumes the same of amount of power regardless of which state it is in 2024-03-31 20:06:44 Well, now if you're going to let someone crack it open and instrument it internally I guess it might be fairly challening. 2024-03-31 20:07:15 I mean, it would need to do stuff with the private key. But it seems like it would be simple enough to make it draw flat power from the computer. 2024-03-31 20:08:52 My first cut at it would be to go for "secure provided I keep physical possession." 2024-03-31 20:09:52 I don't really have any reason to think MY secrets would be particularly valuable to anyone. I'd just like to defeat "casually sweeping me up" along with a whole bunch of other people. 2024-03-31 20:11:24 The thing is, though, to use it you'd still have to use your computer to create and read plain text, so using it because your "computer might not be secure" doesn't seem to buy a whole lot, does it? 2024-03-31 20:12:05 Ultimately you need a trustable system you can use a keyboard and monitor with. 2024-03-31 20:14:14 and to keep Ken Thompson away from it 2024-03-31 20:34:01 Well, having your private keys decisively protected still seems to have some value. It's not the whole story, but it's something. 2024-03-31 21:23:42 Maybe you put a port for a keyboard and a low-performance display right on it, so you'd basically use the computer to power it and provide an untrusted network interface. And you COULD copy plain text onto and off of it, but if you wanted to you could use those local ports to keep the clear text from ever going through the computer at all. 2024-03-31 21:24:04 Wonder if all that could fit in a dongle-size gadget? 2024-03-31 21:24:47 And sure - someone could physically modify your keyboard and monitor while you weren't there, but... that's making you a rather high priority target. 2024-03-31 21:26:07 Let me rephrase that question - would all of that fit in a dongle-size gadget people like us could build. As opposed to some mass-produced micro-minaturized thing. 2024-03-31 21:27:47 https://hackaday.io/project/195010-pocket-pad 2024-03-31 21:27:57 I see this, which is promising sized: 2024-03-31 21:27:59 https://g-ecx.images-amazon.com/images/G/01/aplusautomation/vendorimages/8e826593-5513-440f-89b4-4754167c8acf._CB304017044_.jpg 2024-03-31 21:28:32 Oh, that's pretty cool too, GeDaMo. 2024-03-31 21:30:16 So use case one, the thing completely encapsulates your private GPG keys. And use case two, if you're really serious, you connect an independent keyboard and monitor and use it to interface your plain text. 2024-03-31 21:48:24 Also, the option of a keyboard would let you include keys with passphrases in the setup.