Filling SSD with Random Data for Encryption with Dm-Crypt
I need to encrypt an SSD drive and I have opted to use dm-crypt. This is not something I do on a regular basis.
So far I have successfully cleared the memory cells of my SSD with the ATA secure erase command. I have also filled the entire disk with random data using:
dd if=/dev/urandom of=/dev/sdx bs=4096 status=progress.
My question is in regards to the final step, which is encrypting the devices (my partitions) with the cryptsetup utility.
Since I’ve already filled my entire disk with random data, will I need to refill my partitions with random data after creating and encrypting them? In other words, will the random data that I generated with dd still reside inside of the encrypted partitions that i create?
linux encryption ssd dm-crypt
edited Dec 16 at 22:04
Rui F Ribeiro
38.9k1479129
asked Oct 26 '17 at 17:45
justinnoor.io
348218
add a comment |
I need to encrypt an SSD drive and I have opted to use dm-crypt. This is not something I do on a regular basis.
So far I have successfully cleared the memory cells of my SSD with the ATA secure erase command. I have also filled the entire disk with random data using:
dd if=/dev/urandom of=/dev/sdx bs=4096 status=progress.
My question is in regards to the final step, which is encrypting the devices (my partitions) with the cryptsetup utility.
Since I’ve already filled my entire disk with random data, will I need to refill my partitions with random data after creating and encrypting them? In other words, will the random data that I generated with dd still reside inside of the encrypted partitions that i create?
linux encryption ssd dm-crypt
edited Dec 16 at 22:04
Rui F Ribeiro
38.9k1479129
asked Oct 26 '17 at 17:45
justinnoor.io
348218
What are you trying to achieve? Preventing someone from getting to your data when you haven't entered the pass phrase, or preventing someone from even knowing that there is data there?
– Petro
Oct 26 '17 at 17:59
Adding random data after a trim is more or less pointless - the crypto headers kinda give it away anyway. The point with hard drives was to overwrite any potential old data there. That's achieved with a secure erase.
– vidarlo
Oct 26 '17 at 18:28
maybe related unix.stackexchange.com/a/387261/30851
– frostschutz
Oct 26 '17 at 18:32
add a comment |
I need to encrypt an SSD drive and I have opted to use dm-crypt. This is not something I do on a regular basis.
So far I have successfully cleared the memory cells of my SSD with the ATA secure erase command. I have also filled the entire disk with random data using:
dd if=/dev/urandom of=/dev/sdx bs=4096 status=progress.
My question is in regards to the final step, which is encrypting the devices (my partitions) with the cryptsetup utility.
Since I’ve already filled my entire disk with random data, will I need to refill my partitions with random data after creating and encrypting them? In other words, will the random data that I generated with dd still reside inside of the encrypted partitions that i create?
linux encryption ssd dm-crypt
edited Dec 16 at 22:04
Rui F Ribeiro
38.9k1479129
asked Oct 26 '17 at 17:45
justinnoor.io
348218
I need to encrypt an SSD drive and I have opted to use dm-crypt. This is not something I do on a regular basis.
So far I have successfully cleared the memory cells of my SSD with the ATA secure erase command. I have also filled the entire disk with random data using:
dd if=/dev/urandom of=/dev/sdx bs=4096 status=progress.
My question is in regards to the final step, which is encrypting the devices (my partitions) with the cryptsetup utility.
Since I’ve already filled my entire disk with random data, will I need to refill my partitions with random data after creating and encrypting them? In other words, will the random data that I generated with dd still reside inside of the encrypted partitions that i create?
linux encryption ssd dm-crypt
linux encryption ssd dm-crypt
edited Dec 16 at 22:04
Rui F Ribeiro
38.9k1479129
asked Oct 26 '17 at 17:45
justinnoor.io
348218
edited Dec 16 at 22:04
Rui F Ribeiro
38.9k1479129
asked Oct 26 '17 at 17:45
justinnoor.io
348218
edited Dec 16 at 22:04
Rui F Ribeiro
38.9k1479129
edited Dec 16 at 22:04
Rui F Ribeiro
38.9k1479129
edited Dec 16 at 22:04
Rui F Ribeiro
38.9k1479129
38.9k1479129
asked Oct 26 '17 at 17:45
justinnoor.io
348218
asked Oct 26 '17 at 17:45
justinnoor.io
348218
asked Oct 26 '17 at 17:45
justinnoor.io
348218
348218
What are you trying to achieve? Preventing someone from getting to your data when you haven't entered the pass phrase, or preventing someone from even knowing that there is data there?
– Petro
Oct 26 '17 at 17:59
Adding random data after a trim is more or less pointless - the crypto headers kinda give it away anyway. The point with hard drives was to overwrite any potential old data there. That's achieved with a secure erase.
– vidarlo
Oct 26 '17 at 18:28
maybe related unix.stackexchange.com/a/387261/30851
– frostschutz
Oct 26 '17 at 18:32
add a comment |
What are you trying to achieve? Preventing someone from getting to your data when you haven't entered the pass phrase, or preventing someone from even knowing that there is data there?
– Petro
Oct 26 '17 at 17:59
Adding random data after a trim is more or less pointless - the crypto headers kinda give it away anyway. The point with hard drives was to overwrite any potential old data there. That's achieved with a secure erase.
– vidarlo
Oct 26 '17 at 18:28
maybe related unix.stackexchange.com/a/387261/30851
– frostschutz
Oct 26 '17 at 18:32
What are you trying to achieve? Preventing someone from getting to your data when you haven't entered the pass phrase, or preventing someone from even knowing that there is data there?
– Petro
Oct 26 '17 at 17:59
What are you trying to achieve? Preventing someone from getting to your data when you haven't entered the pass phrase, or preventing someone from even knowing that there is data there?
– Petro
Oct 26 '17 at 17:59
Adding random data after a trim is more or less pointless - the crypto headers kinda give it away anyway. The point with hard drives was to overwrite any potential old data there. That's achieved with a secure erase.
– vidarlo
Oct 26 '17 at 18:28
Adding random data after a trim is more or less pointless - the crypto headers kinda give it away anyway. The point with hard drives was to overwrite any potential old data there. That's achieved with a secure erase.
– vidarlo
Oct 26 '17 at 18:28
maybe related unix.stackexchange.com/a/387261/30851
– frostschutz
Oct 26 '17 at 18:32
maybe related unix.stackexchange.com/a/387261/30851
– frostschutz
Oct 26 '17 at 18:32
add a comment |
1 Answer
1
active
oldest
votes
dd if=/dev/urandom of=/dev/sdx bs=4096 status=progress
This command will overwrite the entire drive with random data. That random data will stay there until you write other data, or secure-erase, or TRIM.
In other words, will the random data that I generated with dd still reside inside of the encrypted partitions that i create?
Normally this is the case.
However, it's not always obvious when TRIM happens. For example, mkfs or mkswap/swapon silently imply TRIM and you have to use additional parameters to disable it. I do not know if partitioners picked up the same idea and TRIM newly created partitions. If using LVM instead of partitions, note that lvremove / lvresize / etc. does imply TRIM if you have issue_discards = 1 in your lvm.conf. Other storage layers such as mdadm support TRIM as a simple pass-through operation.
cryptsetup open by default does not allow TRIM unless you specify --allow-discards, however some distributions might choose to change those defaults.
After all, it's very unusual to random-wipe SSD for encryption. The only use case I can think of is getting rid of old data while not trusting the hardware to do this for free when you TRIM or secure-erase.
Even with encryption, it's normal for free space to be visible on SSD. Most people will want to use TRIM weekly/monthly to avoid possible performance degradation in the long term, so distributions might follow that trend and use allow-discards on encrypted devices by default.
Once trimmed, your overwriting with random data was for naught.
But as long as you are in control, and disable TRIM in everything you do, the random data will stay.
answered Oct 26 '17 at 18:45
frostschutz
25.8k15280
Yeah I won’t be using TRIM. Basically, I wasn’t sure if my partitions were going to overwrite the random data that I generated with /dev/urandom. So I will go ahead and make my partitions. Take care.
– justinnoor.io
Oct 26 '17 at 20:32
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f400674%2ffilling-ssd-with-random-data-for-encryption-with-dm-crypt%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
dd if=/dev/urandom of=/dev/sdx bs=4096 status=progress
This command will overwrite the entire drive with random data. That random data will stay there until you write other data, or secure-erase, or TRIM.
In other words, will the random data that I generated with dd still reside inside of the encrypted partitions that i create?
Normally this is the case.
However, it's not always obvious when TRIM happens. For example, mkfs or mkswap/swapon silently imply TRIM and you have to use additional parameters to disable it. I do not know if partitioners picked up the same idea and TRIM newly created partitions. If using LVM instead of partitions, note that lvremove / lvresize / etc. does imply TRIM if you have issue_discards = 1 in your lvm.conf. Other storage layers such as mdadm support TRIM as a simple pass-through operation.
cryptsetup open by default does not allow TRIM unless you specify --allow-discards, however some distributions might choose to change those defaults.
After all, it's very unusual to random-wipe SSD for encryption. The only use case I can think of is getting rid of old data while not trusting the hardware to do this for free when you TRIM or secure-erase.
Even with encryption, it's normal for free space to be visible on SSD. Most people will want to use TRIM weekly/monthly to avoid possible performance degradation in the long term, so distributions might follow that trend and use allow-discards on encrypted devices by default.
Once trimmed, your overwriting with random data was for naught.
But as long as you are in control, and disable TRIM in everything you do, the random data will stay.
answered Oct 26 '17 at 18:45
frostschutz
25.8k15280
Yeah I won’t be using TRIM. Basically, I wasn’t sure if my partitions were going to overwrite the random data that I generated with /dev/urandom. So I will go ahead and make my partitions. Take care.
– justinnoor.io
Oct 26 '17 at 20:32
add a comment |
dd if=/dev/urandom of=/dev/sdx bs=4096 status=progress
This command will overwrite the entire drive with random data. That random data will stay there until you write other data, or secure-erase, or TRIM.
In other words, will the random data that I generated with dd still reside inside of the encrypted partitions that i create?
Normally this is the case.
However, it's not always obvious when TRIM happens. For example, mkfs or mkswap/swapon silently imply TRIM and you have to use additional parameters to disable it. I do not know if partitioners picked up the same idea and TRIM newly created partitions. If using LVM instead of partitions, note that lvremove / lvresize / etc. does imply TRIM if you have issue_discards = 1 in your lvm.conf. Other storage layers such as mdadm support TRIM as a simple pass-through operation.
cryptsetup open by default does not allow TRIM unless you specify --allow-discards, however some distributions might choose to change those defaults.
After all, it's very unusual to random-wipe SSD for encryption. The only use case I can think of is getting rid of old data while not trusting the hardware to do this for free when you TRIM or secure-erase.
Even with encryption, it's normal for free space to be visible on SSD. Most people will want to use TRIM weekly/monthly to avoid possible performance degradation in the long term, so distributions might follow that trend and use allow-discards on encrypted devices by default.
Once trimmed, your overwriting with random data was for naught.
But as long as you are in control, and disable TRIM in everything you do, the random data will stay.
answered Oct 26 '17 at 18:45
frostschutz
25.8k15280
Yeah I won’t be using TRIM. Basically, I wasn’t sure if my partitions were going to overwrite the random data that I generated with /dev/urandom. So I will go ahead and make my partitions. Take care.
– justinnoor.io
Oct 26 '17 at 20:32
add a comment |
dd if=/dev/urandom of=/dev/sdx bs=4096 status=progress
This command will overwrite the entire drive with random data. That random data will stay there until you write other data, or secure-erase, or TRIM.
In other words, will the random data that I generated with dd still reside inside of the encrypted partitions that i create?
Normally this is the case.
However, it's not always obvious when TRIM happens. For example, mkfs or mkswap/swapon silently imply TRIM and you have to use additional parameters to disable it. I do not know if partitioners picked up the same idea and TRIM newly created partitions. If using LVM instead of partitions, note that lvremove / lvresize / etc. does imply TRIM if you have issue_discards = 1 in your lvm.conf. Other storage layers such as mdadm support TRIM as a simple pass-through operation.
cryptsetup open by default does not allow TRIM unless you specify --allow-discards, however some distributions might choose to change those defaults.
After all, it's very unusual to random-wipe SSD for encryption. The only use case I can think of is getting rid of old data while not trusting the hardware to do this for free when you TRIM or secure-erase.
Even with encryption, it's normal for free space to be visible on SSD. Most people will want to use TRIM weekly/monthly to avoid possible performance degradation in the long term, so distributions might follow that trend and use allow-discards on encrypted devices by default.
Once trimmed, your overwriting with random data was for naught.
But as long as you are in control, and disable TRIM in everything you do, the random data will stay.
answered Oct 26 '17 at 18:45
frostschutz
25.8k15280
dd if=/dev/urandom of=/dev/sdx bs=4096 status=progress
This command will overwrite the entire drive with random data. That random data will stay there until you write other data, or secure-erase, or TRIM.
In other words, will the random data that I generated with dd still reside inside of the encrypted partitions that i create?
Normally this is the case.
However, it's not always obvious when TRIM happens. For example, mkfs or mkswap/swapon silently imply TRIM and you have to use additional parameters to disable it. I do not know if partitioners picked up the same idea and TRIM newly created partitions. If using LVM instead of partitions, note that lvremove / lvresize / etc. does imply TRIM if you have issue_discards = 1 in your lvm.conf. Other storage layers such as mdadm support TRIM as a simple pass-through operation.
cryptsetup open by default does not allow TRIM unless you specify --allow-discards, however some distributions might choose to change those defaults.
After all, it's very unusual to random-wipe SSD for encryption. The only use case I can think of is getting rid of old data while not trusting the hardware to do this for free when you TRIM or secure-erase.
Even with encryption, it's normal for free space to be visible on SSD. Most people will want to use TRIM weekly/monthly to avoid possible performance degradation in the long term, so distributions might follow that trend and use allow-discards on encrypted devices by default.
Once trimmed, your overwriting with random data was for naught.
But as long as you are in control, and disable TRIM in everything you do, the random data will stay.
answered Oct 26 '17 at 18:45
frostschutz
25.8k15280
edited Oct 26 '17 at 18:52
answered Oct 26 '17 at 18:45
frostschutz
25.8k15280
answered Oct 26 '17 at 18:45
frostschutz
25.8k15280
answered Oct 26 '17 at 18:45
frostschutz
25.8k15280
25.8k15280
Yeah I won’t be using TRIM. Basically, I wasn’t sure if my partitions were going to overwrite the random data that I generated with /dev/urandom. So I will go ahead and make my partitions. Take care.
– justinnoor.io
Oct 26 '17 at 20:32
add a comment |
Yeah I won’t be using TRIM. Basically, I wasn’t sure if my partitions were going to overwrite the random data that I generated with /dev/urandom. So I will go ahead and make my partitions. Take care.
– justinnoor.io
Oct 26 '17 at 20:32
Yeah I won’t be using TRIM. Basically, I wasn’t sure if my partitions were going to overwrite the random data that I generated with /dev/urandom. So I will go ahead and make my partitions. Take care.
– justinnoor.io
Oct 26 '17 at 20:32
Yeah I won’t be using TRIM. Basically, I wasn’t sure if my partitions were going to overwrite the random data that I generated with /dev/urandom. So I will go ahead and make my partitions. Take care.
– justinnoor.io
Oct 26 '17 at 20:32
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f400674%2ffilling-ssd-with-random-data-for-encryption-with-dm-crypt%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
What are you trying to achieve? Preventing someone from getting to your data when you haven't entered the pass phrase, or preventing someone from even knowing that there is data there?
– Petro
Oct 26 '17 at 17:59
Adding random data after a trim is more or less pointless - the crypto headers kinda give it away anyway. The point with hard drives was to overwrite any potential old data there. That's achieved with a secure erase.
– vidarlo
Oct 26 '17 at 18:28
maybe related unix.stackexchange.com/a/387261/30851
– frostschutz
Oct 26 '17 at 18:32