Torvalds Warns the World: Don't Use the Linux 5.12-rc1 Kernel

[λ the β-Redex Reducer]

I clearly disagree. The most sensible data I'm going to have on my pyra will be ... my game saves. No need to crypt this.

So I ought to let people steal my passwords because the most sensitive data that you will have on your Pyra are game saves? That is not sensible.

I never understound this vision "everything should be encrypted secure and stuff" It's only worth it *if* you have data to secure, else all you do is reduce your performance and add failure points..

I do not have that vision. For example, I do not need encryption on my Android devices. But I am going to use the Pyra for more stuff than only games.

Post automatically merged: Mar 16, 2021

But how do you want that to be ? If the disk is encrypted from factory then ED would have the keys to all the Pyras. Isn't it better to let every one encrypt it by themselves ? You could have some installer that generates the key before installing, but isn't that overcomplicated ? How do you know the installer isn't sending the key elsewhere ? I like encrypted devices, but I don't like the manufacturer doing it. And if I was ED I wouldn't want the responsability either.

I was actually thinking about just reinstalling the OS. That is how I did it with my laptop. I just upgraded from Windows to NixOS and encrypted my disk in the process. I am not talking about encryption by default, I am just saying that I want encryption. But I have no idea how hard reinstalling PyraOS with LUKS encryption will be.

 

[levi]

The main problem will probably be that at present there is no home partition to encyrpt, it's all part of the same filesystem. To use LUKS the easiest way I know is to encrypt an entire block device i.e. a partition. Then you can just cryptsetup it, format it, configure it to be decrypted as part of your boot process, and bob's your uncle.

 

[Bosbeetle]

The whole encryption idea is fine until you have to handle files or datasets in the multiple 100GB range, between different computers, I really dislike my work to have implemented encryption for most of the people I work with. It truly is a nuisance that doesnt live up to the benefit.

 

[Djoga'Ro]

@levi loopback?

 

[λ the β-Redex Reducer]

The whole encryption idea is fine until you have to handle files or datasets in the multiple 100GB range, between different computers, I really dislike my work to have implemented encryption for most of the people I work with. It truly is a nuisance that doesnt live up to the benefit.

I never had any problems with it at all.
Also, what is the benefit according to you? I am not sure if you are making a point that encryption is too ineffective to be worth the supposed hassle or if you are making a point that the extra privacy is not worth the supposed hassle.

Post automatically merged: Mar 16, 2021

The main problem will probably be that at present there is no home partition to encyrpt, it's all part of the same filesystem. To use LUKS the easiest way I know is to encrypt an entire block device i.e. a partition. Then you can just cryptsetup it, format it, configure it to be decrypted as part of your boot process, and bob's your uncle.

Yeah, that is how I have it here. Except I encrypt everything except the boot partition, not just the home partition. But the point still remains, I would probably need my /boot to be a separate partition.

 

[levi]

@levi loopback?

I don't know if you mean loopback into a file. Sure you could do that, but you'll still have to preallocate enough space for it, the same as you will if you actually repartiton the discs. It's also lilkely to be less performant because to read a file you'd need to deal with the file in the parent file system, decrypt it and then read the file out of that file, though I have no idea how much slower it would be.

 

[netcat]

 

[Bosbeetle]

benefit according to you?

The benefit is data not being stolen by groups with competing interests. Up to now non of the unecrypted data has been stolen as well as non of the encrypted. So data not being available in the event of it being stolen is the benefit. Since it hasnt been stolen the benefit is 0 and the hassle is a lot.

Most of the data is raw data that would take a group with competing interest just as much time as us to analyse so even if it were unencryptedly stolen the other groups would not have much use of it. But since science should be "safe" we all burden ourselfs with constantly encrypting and decrypting data that only a handfull or sometimes even one person can make sense of even in unencrypted form.

I think it would be much more usefull to carefully earmark what data is truly sensitive and encrypt that than going the bruteforce way and encrypting everything even if it was not nessecary.

I would even say that it can be harmfull, it is quite easy to loose data to encryption, see all these attacks on universities the last couple of years. But also ive seen some data being lost to bitlocker by overzealous students (with bad memories and a habbit to not save key's or backup documents)

 

[sebt3]

So I ought to let people steal my passwords because the most sensitive data that you will have on your Pyra are game saves? That is not sensible.

Nothing stop you from making an encrypted partition of an sdcard (or the whole card) to store sensitive data.
I'm only arguing it should not be the default to encrypt the whole system. Seriously, what's the point in encrypting /usr or /opt ? none since it only contain free(software) stuff. But the risk of doing so are not low, especially for lambda users.
I'm all for having a wiki page for doing so (or even a dbp automating the process), but i'll stand by my point ; not on the whole system, not by default.

 

[sebt3]

every stupid mobile device is encrypted

Yep, exactly *stupid* device are encrypted by default.
It's stupid since it does have a performance impact and 99% of what you encrypt doesn't worth protection. Smart stuff use encryption wisely

we are crypto anarchists

Speak for yourself. I'm not.
I'm a retrogamer, like pretty much everyone here.

we are freedom loving hackers

Yup, I like my freedom to use encryption only when it's worth it

don't give me technical excuses to existential needs

If your existance depend on a pyra, then you missed something designing your life

 

[levi]

Well yes, encyrypting stuff is tantamount to owning it, so if someone encrypts stuff you own using a key they control, they've more or less stolen it from you. But the only way you can lose stuff you've encrypted yourself if if you lose the key or the password. Both have happened to me in the past, but I've only really lost older less important data.

Edit: @Bosbeetle

 

[λ the β-Redex Reducer]

I think it would be much more usefull to carefully earmark what data is truly sensitive and encrypt that than going the bruteforce way and encrypting everything even if it was not nessecary.

That is also more prone to error. Not only from forgetting stuff, but also from stuff leaking out due to programs. Some programs automatically place things in weird places or in temporary directories. Encrypting everything is much safer. None of the methods is better than the other, they both have different trade-offs.

 

[Bosbeetle]

Well yes, encyrypting stuff is tantamount to owning it, so if someone encrypts stuff you own using a key they control, they've more or less stolen it from you. But the only way you can lose stuff you've encrypted yourself if if you lose the key or the password. Both have happened to me in the past, but I've only really lost older less important data.

Edit: @Bosbeetle

I hardly "own" any data, allmost all data I use are owned by multiple people. I think encryption might work well on personal systems but enforcing it in businesses seems nice but leads to problems. Especially because you work with complete groups on the same data.

I think Im leaning towards sebt3 ideas.

 

[λ the β-Redex Reducer]

Seriously, what's the point in encrypting /usr or /opt ?

Having fewer partitions.

But the risk of doing so are not low, especially for lambda users.

What risks?

but i'll stand by my point ; not on the whole system, not by default.

And I stand by my point: At least /home, at most everything except for /boot, and not by default.

 

[levi]

Having fewer partitions.

I normally partition off my /boot partition separately, because it can theoretically be useful to recover a system if you lose other partitions. I also partition off /home normally so that I can't stop the system logging due to filling up my home directory with crud. It can also be useful to partion off /var since that's where most logging goes, but that said that's probably the partition that I mostly need to expire old data off, especially on my more resource constrained systems, because that's also where old package archives go.

And I stand by my point: At least /home, at most everything except for /boot, and not by default.

Yes, seems sensible. It's my way of working as well.

 

[netcat]

I'm a retrogamer, like pretty much everyone here.

cryptogamer

encrypting /home should be an install time option. that's all I'm saying. pretty basic feature. maybe all user writable paths.

of course it must be fast. completely transparent. I'll do some benchmarks.

 

[sebt3]

What risks?

You're lucky enough to never had decryption issues at boot time. You're lucky. But your good luck doesnt mean everyone will be that lucky. Have a google search. It's not as if it wasn't usual.
So lets make thing clean. Say you're encrypting the whole system (excluding /boot or not), then if you cant decrypt it at boot, your only option will be to reflash to be able to use your pyra. But then all your sensible data that goes with it are lost too. If you dont encrypt the whole system, but only your user data, if for some reason decryption doesnt happen, you still have a valid system to debug your issue. Your data aren't lost (just yet) and you have some tools at hand to analyze/fix your issue.
If losing your sensible data is not an issue, then why willing to encrypt it in the 1rst place ?

encrypting /home should be an install time option.

Send patch to aTc. if he (and ED) accept it, then it'll be a feature... You'll want to write a good wiki page on how to debug and fix it if it ever fail.

 

[netcat]

Send patch to aTc. if he (and ED) accept it, then it'll be a feature...

this is exactly what i intend to do. my motivation is for the community. of course i can setup my pyra any way i can imagine.

You'll want to write a good wiki page on how to debug and fix it if it ever fail.

of course..
you're spreading FUD btw. it's not particularly difficult and the risks can be mitigated.

 

[netcat]

what i'm really curious about, is how fast it can be.

 

[sebt3]

you're spreading FUD btw. it's not particularly difficult and the risks can be mitigated.

s/FUD/experience/ there I fixed that for you. Got the issue once on a production server. I wasnt particularly happy about this. My clients and users even less...