What tool can encrypt a laptop's data instantly when it's closed, and how do you set it up?

Register now
You must login or register to view hidden content on this page.
You have not described what the "hack" was so all of this is educated guess.


If you don't have a specific knowledge, you should deploy a solution proposed by @0xDEADBEEF - a Teleport.


Ofc, never expose critical service or infrastructure to public. We don't know if you used that VPS for internal needs or were simply hosting a public facing website.

If you used Ubuntu as Linux O/S that means that you can filter traffic properly with default policy DROP - not REJECT (higher CPU usage and notification to adversary) - for all chains and allow only specific ports with both packet state and source and destination address filtering.
 
like i said, my network knowledge is far less competent than some other security aspects.
the https port has to be opened, since the web site has to be served to visitors (like on any other server)
the application was something fairly trivial using cgi, nothing complex, so i am sure any kind of injection was not possible

keep in mind server was set to communicate with SSH (RSA), and passphrase.
bruteforcing that is possible, but you and I would never try that, i am sure with a reason

jump server is a great idea, no question about.
cloudflare was something i implemented later to prevent them even knowing server's ip

anyhow, my point was that even as a above average user who pays attention a lot, things can go south.
below average or average people are better of using something secure out of the box like Apple does, and i am sure @0xDEADBEEF agrees with me
@mraleph i am not saying you are not right, but that type of security(IBM) is very hard to implement

****EDIT****
You have not described what the "hack" was so all of this is educated guess.
i wish i knew more. i just know files leaked. that is all.
it was my guess server got hacked, but did it actually happen, or not - it is just a speculation right now.
this example is far from ideal, i was just sharing my experience in a bar manner, none of this can't be used for a proper professional debate since a lot of things are missing (including the log of access).
sole purpose was to say that bad things can happen no matter what (but in fact we do not know if they actually happened on the way I think they did)
 
Last edited:
Back to OP's question; zero-day vulnerability may exist - even for cryptographic primitives and systems, CA and HA systems, network and system management services. It's up to architects and manager to identify risks and threats.

But, in our line of business - we already identified possible vectors for even those zero-days. There are no black swans - unknown unknowns - even regarding quantum computation and its impact on security of cryptographic systems. With properly segregated users, services and networks you can either limit damage or mitigate the risk completely, even for black swans.

Standard procedures starting with "update system on a regular basis", "implement security upgrades" and similar are for average users. We are facing polimorphic threats - for those, we don't have off the shelf solution. Just like a complex corporate and banking setup across jurisdictions

Rest assured that there are deployed and operational robust secure HA systems facing public network for which we didn't need z/OS and its ecosystem to have a leverage over adversaries.

Hell no, who would do a brute force. Some script kiddies maybe. Encrypted certificate is a good choice Rainbows for RSA, perhaps ed25519 would be a better choice... Both will be degraded when QC is deployed so why not use faster solution?

Apple is a black box. For average user it's secure until it isn't. And, you should not be complacent - it isn't secure - not by IBM definition

With @0xDEADBEEF an OPSEC thread will be written and possible about security of Apple and other declared-secure products and services.

I actually believe that you know a lot - Elbrus comment was very good, beside others - quite a lot and it is a pleasure discussing with you.
 
Reactions: 0xDEADBEEF
get vera crypt its great and nobody can bypass that unless they know the password
there are multiple ways to bypass Veracrypt, for example bruteforcing the password or retrieving the encryption keys from computer's RAM.

imagine your hard drive is 1 TB, you decrypt the Veracrypt partition and it has 500 GB size. guess what the guy with a gun would ask you next?

But, TPM should be disabled and not be used in the first place.
TPM is your friend if set up correctly.
you should use TPM to calculate the firmware/bootloader/kernel checksums, to make sure your system was not tampered with. check this for more info: Heads Threat model
you must not use TPM to store your encryption keys.

We internally deprecated AES
this is a good idea. AES is a global standard and hardware AES acceleration exists in every single CPU and even inside microcontrollers like STM32 or ESP32, and that could potentially mean that 3-letter guys have "very accelerated" devices capable of brute-forcing AES...

it was managed through browser interfaces like many otherd VPS/droplets
the VPS control panel could have had vulnerabilities, I don't know which one you was using but for example you could google for "vesta RCE" or "webmin RCE" to get an idea.
 

Any O/S CDE/FDE solution has its intrinsic vulnerabilities. Depending on a threat model, some may be mitigated, but there are certain that can't be - at least in every case. Retrieving the encryption keys from RAM is one those intrinsic implementation vulnerabilities. There is a TRESOR which is a kernel patch but it relies on AES. Beside TRESOR, both Intel and AMD implemented SME (Secure memory encryption).

For any O/S CDE/FDE, AES should not be used as a single algorithm - Serpent or Twofish are far superior. In a (VeraCrypt) cascade, AES should be used in a middle.

Brute-forcing may be mitigated by using passphrase with minimum 16 chars from whole ASCII chars printable scope in a (pseudo)random pattern

Bash:
genpasswd() {
        local l=$1
        [ "$l" == "" ] && l=16
        tr -dc '~!@#$%^&*()_+[]{}:"|;\,./<>?1234567890qwertyuiopQWERTYUIOPasdfgHJKLASDFGHJKLzxcvbNMZXCVBNM' < /dev/random | head -c ${l} | xargs -0
}

TPM is a black-box. I may agree - there are historical parallels - that using enemy's tools may lead to higher security. Calculating the checksums may be one of those cases.

Using decoy or hidden volumes in any case - abduction, criminal proceedings or similar high stress environments - may lead to loss of higher values and not only data when adversary has elementary understanding of the storage and arithmetic.
 
imagine your hard drive is 1 TB, you decrypt the Veracrypt partition and it has 500 GB size. guess what the guy with a gun would ask you next?
So you need to learn how Veracrypt works, so you would not ask such questions which have no relvance!
 
So you need to learn how Veracrypt works, so you would not ask such questions which have no relvance!
imagine your hard drive is 1 TB, you decrypt the Veracrypt partition and it has 500 GB size. guess what the guy with a gun would ask you next?
I understand both of your points, but for this, as irrelevant as it may seem to the regular Joe, it happens more often than you can imagine, and it is NOT done by "criminals" (the way some of us have been brainwashed to what criminals are).

The solution to this is:

  1. Security Risks
  2. Private Military Companies: Blackwater
It works like a charm! If you are unfamiliar with this, start learning or pay one of them to teach you or give you classes.

I "inherited" this from my mentors over +40 years ago!
These X-Men are NO joke!
They have NO filters!
They do NOT mince words, and your trespassers WILL meet their makers!
These X-Men take preemptive strikes to a whole new level!
 
So you need to learn how Veracrypt works, so you would not ask such questions which have no relvance!
you are right, my question was not really relevant because Veracrypt does not work as I've thought.
I've thought that it creates two separate partitions that would be easy to distinguish because each partitions's size would be smaller than the total container size, or because the hidden partition's header would be visible among the zero's in the free space after the end of the data written to the main partition.
but in reality there is only one, single partition in either "normal" or in a "double bottom" container, and it fills the whole size of the Veracrypt encrypted file (or encrypted hard drive), and also Veracrypt does not have "free space" as we know it - every single empty sector of the file/drive is filled with random data not with zeros.
I have just created a Veracrypt "double bottom" container and compared it to a normal drive:


on a normal drive there are zeroes after my text file filled with "A"s, showing that it is a free space, but on a Veracrypt container there is random data after my file filled with "A"s, so it will be very hard to determine if it is just a free space or there is another encrypted container.

I've never bothered to learn how that "double bottom" stuff works because it does not fit my treat model: in the country I'm from (and highly likely in the country I reside in too) you just will be tortured until you tell all passwords to all containers, both visible and hidden
and as such I don't believe in any hidden containers and simply do not keep any sensitive information on a permanent storage in my computer.
 
Last edited:
For any O/S CDE/FDE, AES should not be used as a single algorithm - Serpent or Twofish are far superior. In a (VeraCrypt) cascade, AES should be used in a middle.
Good to know ,thanks for the info, it's easy to setup with veracrypt.
 
Reactions: mraleph and jafo
Register now
You must login or register to view hidden content on this page.