Liberte Linux

[Badger52]

https://dee.su/liberte

Wondered if anyone has been playing around with this.
Initial goals were a bootable hardened OS on a thumbdrive, so I'd acquired a 32GB specimen just in case. I also wanted to be able store a large variety of references (e-books, pdf's, etc.) on the thing, hence the size. I don't have as many as Sigaba so it turns out I may have over-engineered the size just a tad.

Ostensibly worked up by some Russians back when they were operating in a truly hostile environment and the term 'hacker' was an honorific. Well supported to this day. It seems pretty hardened, but pretty much plug & play although a bit of thought is good before you run the setup batch file, such as:

• Think of a strong password before you start because you will get asked this at setup, and anytime you mount the thumbdrive to boot into Linux.
• Think of how you want your regular files to look that aren't part of the OS's directory structure.
• Find out what key(s) interrupt the boot sequence of your computer so you can tell it to boot off the thumbdrive.

Turns out the OS only needs to eat up about 230MB of the drive and I left it on the 4GB model I tested, and still have plenty left for file storage, which is regular FAT32 stuff, racked & stacked how I want. The OS will look into and use those files; when in the OS that file structure is under the /boot directory. The thumbdrive can also be used conventionally when just running Windoze.

Setting it up is ridiculously easy (an attractor). Simply download the bundle, EXTRACT it (not run or open) TO the root level of the thumbdrive, run the setup.bat file that gets placed there, and you're done. Then SHUTDOWN (as in, OFF) the computer, and turn it back on AND INTERRUPT the bootup sequence so you can select the thumbdrive to boot from instead of your regular hard-drive.

Most of the way through that nice old-school scrolling you'll get prompted for the strong password you thought up. Upon setting that up it will mount your thumbdrive as an encrypted volume and you'll get to the Liberte' Linux desktop. You will get asked for that password anytime it is asked to boot up.

There is a good editor built-in similar to Word (but about 10x faster), it will recognize presence of a wired or wireless LAN, it has a Tor-ified browser built-in (Epiphany) and runs pretty good so far. Upon clicking the far left desktop icon you can get options to reboot, shutdown, etc. It also has a 'claws' mail application for peer-to-peer email w/o an email server in the middle between other like systems. (More to research on this.)

The shutdown sequence will dismount the volume, clean up any traces, and then the screen will halt dead at the end of that scrolling. Unplug thumbdrive, finish your java (no pun) and go about your travels. Or reboot yourself back into whatever your home computer's mainstream OS is.

Seems so far to make a nice grayman type of OS for when out/about the hinterlands. Just wondered if anyone else running it and if they had any tips, gotchas, nice workarounds.

[TFA303]

Many thanks - I've been looking for a good solution like this, and hadn't had much luck with Puppy Linux.

[Dusty]

Originally Posted by Badger52

https://dee.su/liberte
It also has a 'claws' mail application for peer-to-peer email w/o an email server in the middle between other like systems.

How does that work?

[perdurabo]

Originally Posted by Dusty

How does that work?

Looks like Tor and I2P another anonymous networking stack using X.509 certs and Tor-style addressing for "e-mail" addresses.

http://dee.su/cables

[Badger52]

Edit: after typing & seeing perdurabo's post, THANK you.

Originally Posted by Dusty

How does that work?

No idea Dusty but it's intriguing, and is on my ferret list for this weekend if I can survive the deluge of Easter Bunny hunters coming over...

Claws being an application, I think that stations running that system are identified in some way across the network, much the way a Tor-ified browser builds its picture of Tor-relays when it fires up & goes hopping about the globe.* It apparently does support core PGP functions & has a news-reader as well. The potential can't be ignored so I need to dig more. Unfortunately what I know about Claws right now is worth less than a box of small rifle primers.

It seems Claws as an app isn't unique to this version of Linux (there's a Windows version) so I'd be interested in reviews from anyone who's running it & not paid by some magazine advertiser to write nice things. I just need to dig more.



* Think Google (including one's Gmail account) doesn't keep track of your computer & where they expect you to be coming from? Just come in with a Tor-ified browser that says you're now in Ceylon (sorry, Sri Lanka).

[DIYPatriot]

Originally Posted by Dusty

How does that work?

In a system I developed, we had secure and un-secure methods of transmission. Since the only major differences were encryption and failed message delivery, I'll just point out the overview of how our systems operated, securely, in a Peer to Peer email system.

Let's say that Dusty wants to send an email, bragging about a recent barehanded pig kill where he jumped out of a tree with a knife between his teeth, to Barbarian. They each have their own laptop (we'll call each laptop a node) and are connected to a network (even this can be secured or not). For grins, let's say they are on a public network. Each node has a unique ID. This unique ID, or node ID, is registered in an encrypted data store. An application or background look-up service (as I refer to it) provides authentication and queries to this list.

Each person has an email address that has been bound to a certificate provided by a trusted third party. Each certificate contains a public key. The assumption, at this point, is that each person has access to a private key on their computer (used later to decrypt the encrypted message they receive).

Using the custom email application that has been tailored for this sort of thing, the inbox only stores notifications that a message has been received. The content of the actual message is not stored in this notification. However, it resides elsewhere in a secured manner with a special id. Later on, you'll see some benefits to this.

Message Creation:
Dusty creates a new message and types in Barbarian's email address. The look-up service is running in the background and authenticates Barbarian's email address and retrieves the key associated with it; extracting his public key.

A session key is generated and used to encrypt the contents of the message. Next, a message ID is generated in order to uniquely identify the message (for retrieval OR as our clients love this feature - removal prior to or after a message has been sent). Ever send something to the wrong person? Or wish you could truly recall a message? Well, now you can if you utilize this. It's no longer "throw it over the fence and wait for the boom". Some of our messages have expiration timers and that sort of thing. Also, they can't be forwarded if that user does not have the rights to forward their messages or a particular message that the sender did not want forwarded.

Once the message is mapped to a key and everything is encrypted and ready to be "sent" - remember, the message body and notification are two separate entities, then the encrypted message is stored on the closest node. In order for this to work, in real time, the nodes have to be powered on and connected. After the message has been sent, the retrieval function will begin.

Message Retrieval
Barbarian cranks up his email client and checks for new messages. How? The app queries the background/look-up service to find any missed messages so that it may be synchronized. This background service keeps a tab on available nodes at all times, complete with any messages that are destined for Barbarian.

If an email has been obtained, then that message is retrieved and decrypted with the session key that the original sender inserted into the message. The original sender is unaware of this, as is the recipient, since the application does this for both parties. All they ever see is a computer screen with a slick little form.

Upon successful message reception, the background service updates itself so that it won't deliver the same message over and over. This is where things can get fun. Remember when I said that a sender can zap an errant message or prevent that message from being forwarded and shared? This is where that technology is leveraged. True, it must also exist in the email client, it is the actual service that plays God.

There's a WHOLE lot more to this than what I typed. I wanted to provide a mid-level view of my particular implementation of P2P emailing capabilities.

Please bear in mind that there are other ways of achieving this. I've written direct socket communication apps (think chat/instant messaging) and I've written apps that require a physical interface, such as a dongle with encrypted information on it, that must exist in order to authenticate the sending and receiving of messages. The sky is the limit.

BTW...I would bet my next month's pay that my way is not the best way, but I know it works. There are many before me that are truly the experts in this field. I'm sure some 13 year old at MIT could do this in her sleep. I just had to throw something together for a client when we were dealing with an extremely sensitive issue and time, as well as urgency, was a critical factor. Since then, things have evolved.

[Badger52]

Originally Posted by DIYPatriot

In a system I developed,... whole post.

OK, that was so good I'm givin' you a pass for putting Dusty in the same message text with Rosie O'Donnell.


Seriously, thank you. As I dig into this - and my goal is to remain at what I hope will be a simple implementation of Claws - the functionality you described will be a big help when it comes time this weekend (hopefully) to play with it. A very brief read of the install seems to pre-suppose some things but I'll nug it out. What could go wrong?

Question RE latency (or maybe lack of it). In terms of the nodality of the traffic stream, the actual service level achieved sounds like it could be similar to WINLINK, where someone connected might send a message via com'l internet to a relay in Perth, AUS and I can fire up the HF, hit a CONUS relay and the message is there in literally a few minutes, or will still be there later if I choose to wait.

Thanks again. I'm seeing several uses for this capability.
Gotta go get a ham sandwich...

[Dusty]

You two bear watching.

[Dragbag036]

Originally Posted by DIYPatriot

Each person has an email address that has been bound to a certificate provided by a trusted third party. Each certificate contains a public key. The assumption, at this point, is that each person has access to a private key on their computer (used later to decrypt the encrypted message they receive).

My question may not make since, but I will ask as I am a nug.

1.Who is the Third party who holds your certificate? And from my understanding, unless you are the terminal (third party storage), then you have the ability for compromise.

2. How/what type of encryption is placed in the message, and how would the other individual know that this is the key?

3. Is the email decryption taking place in a persistent/non-persistent area of your os thumbdrive/partition drive?

Just trying to get it straight in my head.

[Badger52]

It seems the distribution of Liberte Linux already establishes both types of addresses (both Tor and I2P) if you wish, viewable by the pop-up located in the menu right above the Claws client selection for Yr Hmbl Idiot. They are long godawful hashes, but the client system takes care of remembering them anyway. The Claws client already has the Tor version embedded for you.

I'll just have to find someone to send a test message to as it "appears" to my untrained eye to be setup. This will be a weekend play & fingers x'd it remains something simple enough to also dump on a thumbdrive and teachable to someone else.

DIYP: If you've got a Tor or I2P address can you PM that to me and perhaps I can get a test done of this thing this weekend? I don't know if there is a way to test the functionality absent that the way GnuPG has with Adele in Germany standing by with her nice acknowledgements.

[Badger52]

Dragbag your questions are great ones & well above 'nug' level imo.
I'm curious to see any answers to them. The mail client supports PGP as an add-in & GnuPG is easy enough to add-in. But the assumption of the embedded encryption has me both concerned & intrigued.

A plain-vanilla implementation of PGP (in my case GnuPG for Windoze) and where I don't even publish my public key & use only when necessary seems both simpler, and it works. And using that I can use any mail relay I choose.

Thanks for asking. I like the OS and its bootable capability and the embedded Epiphany browser, but not sold on the cables mail mechanism.
Much to learn.

[badshot]

There's also a portable suitcase for field satellite internet some guys put together over there for Arab springers you might wish to look into.

Liberte sounds like a nice all included nix, being a control freak I build my own hardened OS with Gentoo but will check it out on a USB...

Thanks badger..

PS:
If you can use AES with really long passwords and sent it with RSA

[DIYPatriot]

Originally Posted by Badger52

Question RE latency (or maybe lack of it). In terms of the nodality of the traffic stream, the actual service level achieved sounds like it could be similar to WINLINK, where someone connected might send a message via com'l internet to a relay in Perth, AUS and I can fire up the HF, hit a CONUS relay and the message is there in literally a few minutes, or will still be there later if I choose to wait.

Thanks again. I'm seeing several uses for this capability.
Gotta go get a ham sandwich...

In our implementation, the latency was exactly as you described. The original msg would persist at the nearest node b/c I designed it to broadcast to all connected and available/authenticated nodes. Once the message was retreived and downloaded (if applicable...remember the earlier security controls to prevent unwanted forwarding, etc) it would be removed from the background listener's archive of available messages for download to the peer. The message would persist until the recipient retrieved it via synchronization requests OR it could expire or be removed on the fly by the original sender or an admin level person. Apologies for the delay or any typos. I'm in the field and using a touchscreen

[badshot]

Originally Posted by DIYPatriot

In our implementation, the latency was exactly as you described. The original msg would persist at the nearest node b/c I designed it to broadcast to all connected and available/authenticated nodes. Once the message was retreived and downloaded (if applicable...remember the earlier security controls to prevent unwanted forwarding, etc) it would be removed from the background listener's archive of available messages for download to the peer. The message would persist until the recipient retrieved it via synchronization requests OR it could expire or be removed on the fly by the original sender or an admin level person. Apologies for the delay or any typos. I'm in the field and using a touchscreen

I'm curious and from an engineering standpoint..what language did you build it with?

Hate the touch screens and auto complete...

[DIYPatriot]

Originally Posted by Dragbag036

My question may not make since, but I will ask as I am a nug.

1.Who is the Third party who holds your certificate? And from my understanding, unless you are the terminal (third party storage), then you have the ability for compromise.

2. How/what type of encryption is placed in the message, and how would the other individual know that this is the key?

3. Is the email decryption taking place in a persistent/non-persistent area of your os thumbdrive/partition drive?

Just trying to get it straight in my head.

You can't be any more of a nug than I. Each day, it seems, I learn just exactly how little I know. To answer your q's I'll try my best. I'm low on sig and pwr at the moment.

1. No matter what, you're ALWAYS open for compromise. Nothing is fool proof. Our third party is VeriSign. We've used them on many endeavors and they're kinda the industry std on this sort of thing. Ultimately, we wrote several checks and balances, including the key stored on the master dongle. Think of roaming code garage door openers. Just short of biometrics, its pretty secure. No breaches that I'm aware of to date.

2. We employed an AES scheme. To answer the 2nd part of ur question, please try this link. I learn with hands on experience or pictures. On my cell, I see a decent example of how public/private keys work.

3. Originally, it took place in memory bc our eqpt did not have a thumb drive and we weren't guaranteed a dedicated partition. Besides, in the event something or someone was compromised, the app could (and did) wipe its memory after use. I believe they've changed this since I initially worked on this project.

I can't stress enough that I am not the final authority on this topic. I just have real world experience delivering a solution when no one else on my team had a clue what to do. Time was critical. When I think back on it, I see some areas we could've improved and others we mightve over developed for fear of compromise.