With “guarantees” I meant things like whether you want to have perfect forward secrecy, or whether you want to provide some degree of deniability, and so on, not so much what kinds of guarantees you’re relying on although they’re definitely also good to keep in mind.
“As secure as possible” is a very all-encompassing goal which doesn’t really say much – what I was trying to get at with my point about the guarantees you want to make is that you’ll want to have a clear idea of what you actually mean with “as secure as possible” so you’ll know what sort of eg. architectural decisions to make before you do a lot of work and paint yourself into a corner.
It’s a very ambitious project, but I can guarantee it’ll probably be very interesting to work on and you’ll learn a lot regardless of the outcome, and I’m definitely rooting for you.
I have a background in distributed systems and some background in security (I’m by no means a cryptography expert but I do know more about the subject than average developers), and I’d say that at this stage you shouldn’t worry too much about meeting all parts of some guideline or another; they’re often geared more towards bigger teams and slightly more established projects. What I think could benefit you would be first of all to have a clear idea of what exactly you want to accomplish (from a security standpoint, not necessarily so much from a functionality standpoint) if you don’t already have have one, ie. what sort of guarantees do you want to be able to make. Doesn’t have to even be a public document at first, just some notes and sketches for yourself. Then you’d want to find other projects with similar guarantees and aims and see how they did things, find research papers on the subjects and so on. Security guidelines can be useful, but generally it’s more useful to understand why something is in a guideline in the first place. For a project such as yourst I would personally really emphasize design documents and research over code at an early stage, because you need to have a clear goal in mind before you start cranking out code which might turn out to be worthless (at least to some degree) after you run into problems with your approach. Not saying that the documentation has to be public, just that you / the team know exactly what the goal is.
“Encrypted P2P chat” can mean vastly different kinds of projects, with very different aims. For example, do you want perfect forward secrecy? If so, you’d want to find out the challenges associated with it, especially in relation to interactivity since you’re building a P2P architecture, etc. etc. Same with anonymity / user “traceability” like I mentioned earlier; you need to have a clear picture of what kinds of guarantees do you want the users to have to be even able to say what kinds of best practices you’d have to follow.
Sorry, that turned into a bit of a ramble and might be completely obvious to you already, since I have no idea about your background and the level of research you’ve already done.
Yeah, was the C++ dev just “pre-empting” the PHP devs by ordering all their beers for them so they don’t do it one by one and sing the rest of the song?
Right that makes sense.
But yeah, after glancing through the links you provided, I’d agree that you’ll definitely need to pay someone for an audit / review, there are so many pitfalls and gotchas when it comes to encryption alone, and depending on the guarantees you want to be able to make you’ll find even more pitfalls and gotchas – especially if you want to make even relatively light guarantees about anonymity. The classic problem is that even with encrypted payloads the metadata / protocol itself leaks information, which might or might not be a problem depending on what your guarantees are.
I’d suggest writing at least some level of documentation for the protocol. I’d assume a lot of the more security-minded folks – who your app seems to be targeting – won’t be too enthusiastic about using a chat service that promises security but doesn’t tell you how it plans on achieving it.
I, uh… I don’t get it. Somebody help an idiot out? I haven’t had my morning cuppa yet so it might just be a lack of caffeine.
Is there a description of the protocol somewhere?
Or a FAT meme you’re too young to understand? I honestly can’t remember if NTFS needs defragging or not, I haven’t used Windows since Win7
Programming is also for nerds.
Therefore, tests are for programmers.
◼
YOU CAN’T TELL ME WHAT TO DO, YOU’RE NOT EVEN MY REAL DAD
On the other hand most Linux desktop users are Normie’s, think Steam deck and so on.
Jesus fuck what a statement. Your parents probably regret having you.
Management said that writing tests takes too much time and eats into the time that could be used to write features for the app, so they decided that we’re not writing tests. They were always green anyhow
Probably the majority
The big problem is rather that a lot of innovation has been absorbed by the big companies via buyouts
Which ultimately does seem to lead to innovation slowing down. The big players buy out any potential smaller competitors, and very often just outright kill the products / services they inherited in the acquisition.
Ooo nice, thank you for the tip.
I wonder where I could get a physical version. Somewhere other than Amazon that is, they do have it but I’d like to avoid them if at all possible because, well, Amazon. I searched Adlibris which is a Nordic online bookstore but they didn’t have it, unfortunately.
I’m a fan of physical books nowadays. I read e-books for a few years but I felt like I didn’t remember what I read nearly as well as I do if I read an actual paper book, and apparently there’s actually some empirical evidence for this being a wider phenomenon
The BSD book does seem interesting from a historical perspective, BSD is one of Ye Olden UN*X distros after all. Thanks for the recommendations! I think I’ll try to get my hands on a dead trees version of the BSD book.
Oh and did you specifically mean “The Design and Implementation of the 4.4BSD Operating System”? Looks like there’s one for FreeBSD as well
I actually don’t know nearly enough about OS design, and I’ve been toying with the idea of learning more for like 20 years now but never manage to get around to it. How’s that book hold up, considering it was (apparently?) published in '96? I’d assume a lot of the basics are still the same, and since it’s a book about the “evolution” of UNIX the historical parts will still be interesting in any case
Anybody here have experience with older models of these laptops? I’ve been thinking of moving over to a more open platform, so this headline caught my eye
Huh, I never actually gave any thought to how the SysRq key works. Interesting thing to learn after all these decades, heh
Not all that cute though