Soooo my little encryption tool makes progress. <3

After a short break from development, we had our first successful loaded container yesterday!

This means:
- Protocoll is working
- We can create containers and store/copress files in it
- we're awesome
- I love it
- you are awesome, too!

(Loaded containers will be inaccessible for movement to different directories while our tool is open)

.cnt? :D really? :D
Please tell me you've picked this extension just for this demo :D

@netikras at this moment we use .cnt, but it could also be .motherclucker, because it doesnt matter ^^

@netikras you beat me to that little gem 😂 porn.’cnt’

I’m actually genuinely interested in this. Tell me more! 👌🏼

@irene @badcopnodonuts We're trying to create a new encryption software with an 256 Bit encryption.

On of our main features is that you can lock your container with password and an generated hardware-id. So if your container and password get's stolen they cannot open it on other machines. (Like when the police tries to open the container on their computer) Hardware-ID will currently be bound to the CPU.

(Because of Electron) you can drop file in like in 7-Zip or Winrar, but not out (working on last, electron is a bitch). The files will be shrunk down, and then secured.

Look up my older Rants about this :)

@netikras @badcopnodonuts Oh I just realised now... XD

@irene Yes, we'll have multiple levels of security, currently V1 and V2.

V1 = Password

V2 = Password + HWID

@irene My Backend-Dev said: "I don't use AES" - I don't know what encryption exactly he is using. But I dont think its common

@SteffTek ChaCha/Salsa20? TwoFish? Serpent?

@SteffTek

I can already hear tutorials :D
-----
Now that we have received this cnt, we unzip it. Once unzipped, open the cnt (it might take some time). Here, now the cnt is open and ready for work. To test elasticity of this cnt we can pick the largest thing we have around and try to jam it into the cnt. See, the size of the cnt expands as the object is transfered into it. Now remove this object from the cnt. For better understanding try to fill this cnt with objects of various sizes - you'll see its capacity adapt very nicely.

When finished, close the cnt. If you have a need you can get as many cnts as you want and interact with any of them or all of them at once.
------

boy.. :D :D

@irene Thats a feature I could think of! Well, our encryption backend won't be open source, but we'll love to implement user requests like this one. I'll think we could do something like this ^^

Problem is, for HWID on Linux we need root, so i'll need to create it once per startup because we won't save the root password.

But we'll looking forward to implementing more security features!

@netikras I fucking love it!

Not open? Maybe some custom brewed encryption? That's gonna be a hard pass for many potential users, especially if it's really custom brewed. The first rule of implementing your own encryption algorithms is that you don't.
Also please decouple the 'backend' from the gui, implement some interface. Just in case you want to get rid of your b̶r̶o̶w̶s̶e̶r̶ electron next week..

@Kimmax I'll ask him what encryption, I dont think it's custom brewed.

We'll have a backend and frontend program, so we'll technically could get rid of electron, in case we get to the limits with the features it has. (Like dropping virtual files). We had thaught of that ;)

@SteffTek 👌🏻

@irene for the processorID on linux we're executing a commandline command (dmidecode) and grep the processorID..

Windows is a bit more versitile(?) and let me just use "wmic cpu get processorid" without any permission

MacOS is not yet tested, because I don't have a fucking mac... :D

If you have any better idea, pls tell me :/

Maybe I am dumb, but could someone not overwrite the functionality of grep? And thus potentially spit back a custom hardware ID?

@gerritman123 I don't think that you can override grep, but not sure...

@irene also we are using Java for our backend... I don't think it's possible there to easily get the ID

@irene with grep we dont need to search for the processor id

but he is actually right, you can easily use an alias to manipulate the outcome.. uff

@irene we could easily not use grep, but you can also alias the main command

we'll just try to delete aliases ^^

Next time, use the white color because it makes the censoring more subtle.

@SteffTek overriding system binarys is as simple as placing a file in a specific location on most distros, others might need a setting more, but generally the same. You could also go full yolo and simply override the original file. Dmidecode could also be manipulated

@Kimmax oh ok... You have an better solution?

@SteffTek stop caring about stuff you have no control over. If the machine is compromised, it's over. You could compare hashes of the binarys against known versions and issue warnings of they don't match, but that seems a bit complex, considering the amount of different builds. You could recommend a distro specific tool that does this, but that's about it.

@Kimmax Ok wow, that's the answer I hoped for! Thanks <3

@irene

Also we are using AES 256 Bit, but my backend guy ment that he uses a different IV for every Block. ^^ (also we are really interested now in USB device encryption-level)

@irene I don't have a FUCKING Clue but I trust him <3 Tell you more about in my next post :)

@lunorian could, but maybe you destroyed your CPU ^^

Or if someone steals your data and tries to open it on their PC, not working.

But we'll implement USB-HWID as we speak!

This looks awesome, congrats! 👍

@irene IV = Initialization Vector ^^ like salt For AES

@irene he adds a random IV at the end of every block, so nobody can see patterns (translated bad I guess?)

@irene @SteffTek @Kimmax
That's why making it open-source would be nice ;)

@irene jeah I don't know exactly how to translate his message sooo.. it should at least be safe

@irene Im sure he's using cryptographically safe Random generator. OP mentioned its in Java and this is simple enough to do in Java, the secure version should use additional noise to generate randoms. The biggest security risk happens during IV generation. For a brief moment (and if implemented poorly longer) the IVs are visible in a RAM dump. But after its gone you're pretty safe.

Source: This is similar to how we implement secure file encryption on our servers for private user files so I have some experience with how Java does this, tho no HWID or multiple IVs so thats nice

@irene it isn't, you need the passphrase in a readable form no matter what (either user memory or something more clever). The way you get good security on an automated system is by making sure the attacker needs to jump as many hoops as practical. For example store different parts of the full passphrase in different parts of the machine, or even several servers. The software has to gather the pieces if it wants to encrypt something, or even send it to another server for encryption with its own partial key. The result should be that even if an attacker gets the file, he needs to key, to the key, he might need to find it in the code, the variable and the code itself should be obfuscated and stored as B64, but there might even be another code (or part of it) in the database per user and so on..

This protects the data against various "hacky" attacks, but if your server machine gets compromised its only a question of time and effort

@Hazarth Why would it be problematic when the IVs are in the server's memory? An IV is 'public' information and usually stored / sent in clear text.

The only problems if the IVs are predictable or the same for the same set of data.

@sbiewald if you have the IVs the randomization function starts to be predictable and you get the same kind of attacks as with unsecure random number generation. Its not a *huge* deal, but its still a valid part of an attack depending on how you implemented it. It would be a huge nono if you for example stored it in a static or a constant at start, as that gives the attacker the whole runtime to get it and then start attacking your encrypted data. But even storing it in a local variable doesnt guarantee its going to be overwritten any time soon. Which means that if an attacker can get access to the machine memory while an important file is encrypted, he might be able to steal the IV even if he missed the password minutes or even hours later. I didnt test this myself, but I believe oracle themselves recommend zeroing the IV after encryption

@sbiewald also, I never heard about IVs being public, its literally initialization vector for the encryption library and its a raw array of bytes in java. Its as if you sent a seed to a random function in a message to the user, not a good idea.

Would prefer if it was open source but will you have it verified independently.

@icycrash the frontend is open source. Just not the backend. It won't be obfuscated.

@SteffTek Will be the algorithm or a minimal, reproducible of the encryption algorithm public? Or at least pseudocode, so the algorithm can be (formally) verified?

@Hazarth We are still talking about CBC mode aren't we? If we aren't that might explain it.

As you can see on the attached image, the IV is xored to the first block of plain text.
The idea of the whole mode is to destroy any clear text patterns. The important thing is the IV is unpredictable for future messages.

The IV is relevant information for decrypting the first block legitimately. For all other blocks, the previous cipher text block works as the IV for the next one, hence it is already public information.

@sbiewald yeah no, I wasnt in CBC at all, I was keeping it simple. Yes, if I would consider blocks then the problems I mentioned aren't relevant, I was answering Irenes questions about random number gen security and stayed in the basics. I didnt realize you were Continuing OP's topic of chaining blocks, my bad. In that case you're right that the memory leak isnt a problem pretty much at all, tho Im not well versed in CBC and still not sure about the public IV thing. If you'd care to explain why you'd ever give the user the IV I'll listen

@Hazarth Well, in CBC the IV is simply required for any decryption. I haven't heared of any other encryption algorithm (some stream cipher need an IV, too) / mode of operation and library where this wasn't the case. The security of a library most only spend on the key and the CSPRNG, both not being touched by giving the IV away.
It may even possible, that your library stores the IV with the cipher text already, but I don't know what library you are using.

The IV has to be stored/sent somewhere in plaintext (as it is required for decryption).

Edit: Cannot attach the images.
CBC encryption: https://upload.wikimedia.org/wikipe...
CBC decryption: https://upload.wikimedia.org/wikipe...

@sbiewald I didnt use a library for this, I was just given a task to protect users data and used then built-in Java encryption implementation. Long story short, we're storing the IVs encrypted in the database and linked to the files by uuids only. The IV was generated as a simple random byte array using a cryptographically secure random num. gen and pretty much all of this is hidden from the user (the data we store isnt *that* sensitive, just needed something for Meme-GDPR tbh). So in our implementation the user doesn't even know then data is being encrypted (except for a note that it is, but no input or output is involved at this stage)

@Hazarth Out of curiosity, you do not use the same key to encrypt the data and the IV?

By the way, what I mean with 'public' is 'anyone what has access to the cipher text'. If the user can't access that, there is no need to give then them the IV.

@sbiewald nah, the keys are different, the key for the data is a randomly generated 128-bit key, the IV is encrypted with a known key thats hidden elsewhere

How do I pronounce this extension?
😂

@Ganofins not cunt. It's container 😎