Bad decrypt with OpenSSL using Terminal
I looked into tinkering with encryption using OpenSSL on Terminal.
Using the command below I managed to encrypt a file under AES256.
openssl enc -aes-256-cbc -e -in /Users/user/desktop/filename -out /Users/user/desktop/filename
This command successfully encrypts my file. However when I do the decryption with the following command,
openssl enc -aes-256-cbc -d -in /Users/user/desktop/filename -out /Users/user/desktop/filename
The file fails to decrypt, changes the target file to a zero kB empty file, and displays the message
error reading input file
This issue does not occur if I set the decrypt output to a different file name such as
openssl enc -aes-256-cbc -d -in /Users/user/desktop/filename -out /Users/user/desktop/filename2
Did I violate a basic principle? I'm starting to dabble into coding and want to know why the second command does not work (since it's convenient).
This is the source I came across:
https://apple.stackexchange.com/questions/272808/how-can-i-password-protect-files-in-macos
I did some searching however could not find any information on failed decrypt that lead to the deletion of the file. I was also not able to recover the missing file(not important but was a dummy).
Thanks!
macos encryption openssl macos-mojave
asked Nov 15 '18 at 6:13
LinLin
63
|
show 2 more comments
I looked into tinkering with encryption using OpenSSL on Terminal.
Using the command below I managed to encrypt a file under AES256.
openssl enc -aes-256-cbc -e -in /Users/user/desktop/filename -out /Users/user/desktop/filename
This command successfully encrypts my file. However when I do the decryption with the following command,
openssl enc -aes-256-cbc -d -in /Users/user/desktop/filename -out /Users/user/desktop/filename
The file fails to decrypt, changes the target file to a zero kB empty file, and displays the message
error reading input file
This issue does not occur if I set the decrypt output to a different file name such as
openssl enc -aes-256-cbc -d -in /Users/user/desktop/filename -out /Users/user/desktop/filename2
Did I violate a basic principle? I'm starting to dabble into coding and want to know why the second command does not work (since it's convenient).
This is the source I came across:
https://apple.stackexchange.com/questions/272808/how-can-i-password-protect-files-in-macos
I did some searching however could not find any information on failed decrypt that lead to the deletion of the file. I was also not able to recover the missing file(not important but was a dummy).
Thanks!
macos encryption openssl macos-mojave
asked Nov 15 '18 at 6:13
LinLin
63
1
Yes, you did violate a basic principle - you are writing to the same file, as you are reading from, it is more interesting why the encryption is working at all too.
– gusto2
Nov 15 '18 at 8:48
@gusto2+ depending on how stdlib works it might read one bufferful before the rest gets clobbered, but on my Linux (which is not MacOS of course) the encryption output is only the fixed header plus one padding block (with no real data). Lin: did you check the size of the encryption result against its input, before destroying it?
– dave_thompson_085
Nov 15 '18 at 9:00
@dave_thompson_085 The files were pdf's and Word documents. They were 65kb and 631kb. Both became zero kb after the decrypt output.
– Lin
Nov 15 '18 at 10:09
Were they 65kb and 631kb after encryption but before decryption? And did that encryption use the output name equal to the input name?
– dave_thompson_085
Nov 16 '18 at 5:58
@dave_thompson_085 Apologies for the tardiness, I had to verify that again. I converted a word file and it had 631kb, now it's just 32 bytes(after using the same designation for -in and -out. When decrypted with a different designation it does not recover and drops to 'zero bytes'. At this point it's a bit of a hit & miss, and can conclude that using the same designation for -in and -out, whether encrypting or decrypting, will probably result in complete file loss.
– Lin
Nov 20 '18 at 10:18
|
show 2 more comments
I looked into tinkering with encryption using OpenSSL on Terminal.
Using the command below I managed to encrypt a file under AES256.
openssl enc -aes-256-cbc -e -in /Users/user/desktop/filename -out /Users/user/desktop/filename
This command successfully encrypts my file. However when I do the decryption with the following command,
openssl enc -aes-256-cbc -d -in /Users/user/desktop/filename -out /Users/user/desktop/filename
The file fails to decrypt, changes the target file to a zero kB empty file, and displays the message
error reading input file
This issue does not occur if I set the decrypt output to a different file name such as
openssl enc -aes-256-cbc -d -in /Users/user/desktop/filename -out /Users/user/desktop/filename2
Did I violate a basic principle? I'm starting to dabble into coding and want to know why the second command does not work (since it's convenient).
This is the source I came across:
https://apple.stackexchange.com/questions/272808/how-can-i-password-protect-files-in-macos
I did some searching however could not find any information on failed decrypt that lead to the deletion of the file. I was also not able to recover the missing file(not important but was a dummy).
Thanks!
macos encryption openssl macos-mojave
asked Nov 15 '18 at 6:13
LinLin
63
I looked into tinkering with encryption using OpenSSL on Terminal.
Using the command below I managed to encrypt a file under AES256.
openssl enc -aes-256-cbc -e -in /Users/user/desktop/filename -out /Users/user/desktop/filename
This command successfully encrypts my file. However when I do the decryption with the following command,
openssl enc -aes-256-cbc -d -in /Users/user/desktop/filename -out /Users/user/desktop/filename
The file fails to decrypt, changes the target file to a zero kB empty file, and displays the message
error reading input file
This issue does not occur if I set the decrypt output to a different file name such as
openssl enc -aes-256-cbc -d -in /Users/user/desktop/filename -out /Users/user/desktop/filename2
Did I violate a basic principle? I'm starting to dabble into coding and want to know why the second command does not work (since it's convenient).
This is the source I came across:
https://apple.stackexchange.com/questions/272808/how-can-i-password-protect-files-in-macos
I did some searching however could not find any information on failed decrypt that lead to the deletion of the file. I was also not able to recover the missing file(not important but was a dummy).
Thanks!
macos encryption openssl macos-mojave
macos encryption openssl macos-mojave
asked Nov 15 '18 at 6:13
LinLin
63
asked Nov 15 '18 at 6:13
LinLin
63
edited Nov 15 '18 at 6:23
Lin
asked Nov 15 '18 at 6:13
LinLin
63
asked Nov 15 '18 at 6:13
LinLin
63
asked Nov 15 '18 at 6:13
LinLin
63
63
1
Yes, you did violate a basic principle - you are writing to the same file, as you are reading from, it is more interesting why the encryption is working at all too.
– gusto2
Nov 15 '18 at 8:48
@gusto2+ depending on how stdlib works it might read one bufferful before the rest gets clobbered, but on my Linux (which is not MacOS of course) the encryption output is only the fixed header plus one padding block (with no real data). Lin: did you check the size of the encryption result against its input, before destroying it?
– dave_thompson_085
Nov 15 '18 at 9:00
@dave_thompson_085 The files were pdf's and Word documents. They were 65kb and 631kb. Both became zero kb after the decrypt output.
– Lin
Nov 15 '18 at 10:09
Were they 65kb and 631kb after encryption but before decryption? And did that encryption use the output name equal to the input name?
– dave_thompson_085
Nov 16 '18 at 5:58
@dave_thompson_085 Apologies for the tardiness, I had to verify that again. I converted a word file and it had 631kb, now it's just 32 bytes(after using the same designation for -in and -out. When decrypted with a different designation it does not recover and drops to 'zero bytes'. At this point it's a bit of a hit & miss, and can conclude that using the same designation for -in and -out, whether encrypting or decrypting, will probably result in complete file loss.
– Lin
Nov 20 '18 at 10:18
|
show 2 more comments
1
Yes, you did violate a basic principle - you are writing to the same file, as you are reading from, it is more interesting why the encryption is working at all too.
– gusto2
Nov 15 '18 at 8:48
@gusto2+ depending on how stdlib works it might read one bufferful before the rest gets clobbered, but on my Linux (which is not MacOS of course) the encryption output is only the fixed header plus one padding block (with no real data). Lin: did you check the size of the encryption result against its input, before destroying it?
– dave_thompson_085
Nov 15 '18 at 9:00
@dave_thompson_085 The files were pdf's and Word documents. They were 65kb and 631kb. Both became zero kb after the decrypt output.
– Lin
Nov 15 '18 at 10:09
Were they 65kb and 631kb after encryption but before decryption? And did that encryption use the output name equal to the input name?
– dave_thompson_085
Nov 16 '18 at 5:58
@dave_thompson_085 Apologies for the tardiness, I had to verify that again. I converted a word file and it had 631kb, now it's just 32 bytes(after using the same designation for -in and -out. When decrypted with a different designation it does not recover and drops to 'zero bytes'. At this point it's a bit of a hit & miss, and can conclude that using the same designation for -in and -out, whether encrypting or decrypting, will probably result in complete file loss.
– Lin
Nov 20 '18 at 10:18
1
1
Yes, you did violate a basic principle - you are writing to the same file, as you are reading from, it is more interesting why the encryption is working at all too.
– gusto2
Nov 15 '18 at 8:48
Yes, you did violate a basic principle - you are writing to the same file, as you are reading from, it is more interesting why the encryption is working at all too.
– gusto2
Nov 15 '18 at 8:48
@gusto2+ depending on how stdlib works it might read one bufferful before the rest gets clobbered, but on my Linux (which is not MacOS of course) the encryption output is only the fixed header plus one padding block (with no real data). Lin: did you check the size of the encryption result against its input, before destroying it?
– dave_thompson_085
Nov 15 '18 at 9:00
@gusto2+ depending on how stdlib works it might read one bufferful before the rest gets clobbered, but on my Linux (which is not MacOS of course) the encryption output is only the fixed header plus one padding block (with no real data). Lin: did you check the size of the encryption result against its input, before destroying it?
– dave_thompson_085
Nov 15 '18 at 9:00
@dave_thompson_085 The files were pdf's and Word documents. They were 65kb and 631kb. Both became zero kb after the decrypt output.
– Lin
Nov 15 '18 at 10:09
@dave_thompson_085 The files were pdf's and Word documents. They were 65kb and 631kb. Both became zero kb after the decrypt output.
– Lin
Nov 15 '18 at 10:09
Were they 65kb and 631kb after encryption but before decryption? And did that encryption use the output name equal to the input name?
– dave_thompson_085
Nov 16 '18 at 5:58
Were they 65kb and 631kb after encryption but before decryption? And did that encryption use the output name equal to the input name?
– dave_thompson_085
Nov 16 '18 at 5:58
@dave_thompson_085 Apologies for the tardiness, I had to verify that again. I converted a word file and it had 631kb, now it's just 32 bytes(after using the same designation for -in and -out. When decrypted with a different designation it does not recover and drops to 'zero bytes'. At this point it's a bit of a hit & miss, and can conclude that using the same designation for -in and -out, whether encrypting or decrypting, will probably result in complete file loss.
– Lin
Nov 20 '18 at 10:18
@dave_thompson_085 Apologies for the tardiness, I had to verify that again. I converted a word file and it had 631kb, now it's just 32 bytes(after using the same designation for -in and -out. When decrypted with a different designation it does not recover and drops to 'zero bytes'. At this point it's a bit of a hit & miss, and can conclude that using the same designation for -in and -out, whether encrypting or decrypting, will probably result in complete file loss.
– Lin
Nov 20 '18 at 10:18
|
show 2 more comments
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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%2fstackoverflow.com%2fquestions%2f53313453%2fbad-decrypt-with-openssl-using-terminal%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- 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%2fstackoverflow.com%2fquestions%2f53313453%2fbad-decrypt-with-openssl-using-terminal%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
1
Yes, you did violate a basic principle - you are writing to the same file, as you are reading from, it is more interesting why the encryption is working at all too.
– gusto2
Nov 15 '18 at 8:48
@gusto2+ depending on how stdlib works it might read one bufferful before the rest gets clobbered, but on my Linux (which is not MacOS of course) the encryption output is only the fixed header plus one padding block (with no real data). Lin: did you check the size of the encryption result against its input, before destroying it?
– dave_thompson_085
Nov 15 '18 at 9:00
@dave_thompson_085 The files were pdf's and Word documents. They were 65kb and 631kb. Both became zero kb after the decrypt output.
– Lin
Nov 15 '18 at 10:09
Were they 65kb and 631kb after encryption but before decryption? And did that encryption use the output name equal to the input name?
– dave_thompson_085
Nov 16 '18 at 5:58
@dave_thompson_085 Apologies for the tardiness, I had to verify that again. I converted a word file and it had 631kb, now it's just 32 bytes(after using the same designation for -in and -out. When decrypted with a different designation it does not recover and drops to 'zero bytes'. At this point it's a bit of a hit & miss, and can conclude that using the same designation for -in and -out, whether encrypting or decrypting, will probably result in complete file loss.
– Lin
Nov 20 '18 at 10:18