Encrypting PDF with qpdf and only user passwordLVM + LUKS + SSD + Gentoo — making it all work...
What are the ramifications of this change to upcasting spells?
Sous vide chicken without an internal temperature of 165
How did Apollo 15's depressurization work?
Did the twin engined Lazair ultralight have a throttle for each engine?
Is there such a thing as too inconvenient?
Using は before 欲しい instead が
Unity: transform.LookAt(target) not "looking at" target?
Is it allowable to use an organization's name to publish a paper in a conference, even after I graduate from it?
How to decide whether an eshop is safe or compromised
Are there any legal requirements concerning airline pilots and their watches?
What can I do to keep a threaded bolt from falling out of it’s slot
Chess software to analyze games
Convert HTML color to OLE
Why doesn't mathematics collapse down, even though humans quite often make mistakes in their proofs?
Limits and Continuity in Multi variable calculus.
90s(?) book series about two people transported to a parallel medieval world, she joins city watch, he becomes wizard
What animal has fat with the highest energy density?
Story about a demon trying to make a man insane
Why the color Red in Us, what is the significance?
I think my ex-employer secretely kept me in their system as an employee
Count the frequency of items in an array
"Silverware", "Tableware", and "Dishes"
Land Registry Clause
Use of vor in this sentence
Encrypting PDF with qpdf and only user password
LVM + LUKS + SSD + Gentoo — making it all work togetherDm-Crypt system encryption with different keys per userHow to get a usable full disk encryption with different encryptions for different usersfull disk encryption (including swap, possibly plausible deniability as well)How to encrypt Linux (Debian 8) post-installation and what are the consequences?Bad magic number error with travisSSD Encryption / dm-cryptEncrypting home directory on Raspberry pi with password file on USB
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
Does anyone know how to set only the user password for qpdf encryption?
I'm using Debian 10 (buster) and qpdf version 8.4.2-1 from unstable backported to buster.
If I set just the user password (for example userpasswd), and leave the owner password blank (i.e. use the empty string ""), for some file foo.pdf, then the encryption command is just
qpdf --encrypt userpasswd "" 256 -- foo.pdf foo.enc.pdf
but okular, evince and xpdf all open foo.enc.pdf without asking for a password. If I use a password for both, I am asked for a password. I.e.
qpdf --encrypt userpasswd userpasswd 256 -- foo.pdf foo.enc.pdf
But I just want to do the user password encryption.
Also, pdfinfo reports that the file is encrypted.
pdfinfo foo.pdf
[...]
Encrypted: yes (print:yes copy:yes change:yes addNotes:yes algorithm:AES-256)
It seems unlikely that something so simple is buggy, but I don't see what I'm doing wrong here.
Added an issue to QPDF's issue tracker on Github:
Encrypting with just the user password
encryption pdf qpdf
asked Aug 16 at 20:42
Faheem MithaFaheem Mitha
24k18 gold badges87 silver badges140 bronze badges
add a comment |
Does anyone know how to set only the user password for qpdf encryption?
I'm using Debian 10 (buster) and qpdf version 8.4.2-1 from unstable backported to buster.
If I set just the user password (for example userpasswd), and leave the owner password blank (i.e. use the empty string ""), for some file foo.pdf, then the encryption command is just
qpdf --encrypt userpasswd "" 256 -- foo.pdf foo.enc.pdf
but okular, evince and xpdf all open foo.enc.pdf without asking for a password. If I use a password for both, I am asked for a password. I.e.
qpdf --encrypt userpasswd userpasswd 256 -- foo.pdf foo.enc.pdf
But I just want to do the user password encryption.
Also, pdfinfo reports that the file is encrypted.
pdfinfo foo.pdf
[...]
Encrypted: yes (print:yes copy:yes change:yes addNotes:yes algorithm:AES-256)
It seems unlikely that something so simple is buggy, but I don't see what I'm doing wrong here.
Added an issue to QPDF's issue tracker on Github:
Encrypting with just the user password
encryption pdf qpdf
asked Aug 16 at 20:42
Faheem MithaFaheem Mitha
24k18 gold badges87 silver badges140 bronze badges
add a comment |
Does anyone know how to set only the user password for qpdf encryption?
I'm using Debian 10 (buster) and qpdf version 8.4.2-1 from unstable backported to buster.
If I set just the user password (for example userpasswd), and leave the owner password blank (i.e. use the empty string ""), for some file foo.pdf, then the encryption command is just
qpdf --encrypt userpasswd "" 256 -- foo.pdf foo.enc.pdf
but okular, evince and xpdf all open foo.enc.pdf without asking for a password. If I use a password for both, I am asked for a password. I.e.
qpdf --encrypt userpasswd userpasswd 256 -- foo.pdf foo.enc.pdf
But I just want to do the user password encryption.
Also, pdfinfo reports that the file is encrypted.
pdfinfo foo.pdf
[...]
Encrypted: yes (print:yes copy:yes change:yes addNotes:yes algorithm:AES-256)
It seems unlikely that something so simple is buggy, but I don't see what I'm doing wrong here.
Added an issue to QPDF's issue tracker on Github:
Encrypting with just the user password
encryption pdf qpdf
asked Aug 16 at 20:42
Faheem MithaFaheem Mitha
24k18 gold badges87 silver badges140 bronze badges
Does anyone know how to set only the user password for qpdf encryption?
I'm using Debian 10 (buster) and qpdf version 8.4.2-1 from unstable backported to buster.
If I set just the user password (for example userpasswd), and leave the owner password blank (i.e. use the empty string ""), for some file foo.pdf, then the encryption command is just
qpdf --encrypt userpasswd "" 256 -- foo.pdf foo.enc.pdf
but okular, evince and xpdf all open foo.enc.pdf without asking for a password. If I use a password for both, I am asked for a password. I.e.
qpdf --encrypt userpasswd userpasswd 256 -- foo.pdf foo.enc.pdf
But I just want to do the user password encryption.
Also, pdfinfo reports that the file is encrypted.
pdfinfo foo.pdf
[...]
Encrypted: yes (print:yes copy:yes change:yes addNotes:yes algorithm:AES-256)
It seems unlikely that something so simple is buggy, but I don't see what I'm doing wrong here.
Added an issue to QPDF's issue tracker on Github:
Encrypting with just the user password
encryption pdf qpdf
encryption pdf qpdf
asked Aug 16 at 20:42
Faheem MithaFaheem Mitha
24k18 gold badges87 silver badges140 bronze badges
asked Aug 16 at 20:42
Faheem MithaFaheem Mitha
24k18 gold badges87 silver badges140 bronze badges
edited 2 days ago
Faheem Mitha
asked Aug 16 at 20:42
Faheem MithaFaheem Mitha
24k18 gold badges87 silver badges140 bronze badges
asked Aug 16 at 20:42
Faheem MithaFaheem Mitha
24k18 gold badges87 silver badges140 bronze badges
asked Aug 16 at 20:42
Faheem MithaFaheem Mitha
24k18 gold badges87 silver badges140 bronze badges
24k18 gold badges87 silver badges140 bronze badges
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Punchline: most likely what you actually want to do is to use the empty string for the user password and a non-empty string for the owner password, not the other way around. If you do this, people will be able to open the file without supplying a password, but compliant viewers will still enforce the document's security. Opening with the owner password will allow you to modify security in a tool like Adobe Acrobat. Note that qpdf disregards the file's security in all cases and treats the user and owner passwords the same.
I'll try to explain what's going on.
Compliant PDF viewers are supposed to honor the file's security when the file is opened with the user password and allow full "admin" rights to the file when the file is opened with the owner password. As such, it doesn't make sense to provide a user password and not an owner password, as this would mean that not providing a password is more restrictive than providing a password.
In older PDF encryption formats, the file was encrypted by an encryption key that is derived from the user password, and the user password is actually stored in the file encrypted with the owner password. PDF viewers would first try to see if the supplied password is the user password. If so, they can retrieve the key and decrypt the file. If not, they check to see if it's the owner password. If so, they can retrieve the user password, and from there, they can retrieve the key. Newer encryption formats encrypt the actual key independently with both the user password and the owner password, and as such, it is not possible to retrieve the user password with the owner password.
Because of this behavior, some applications will try to open an encrypted password trying the empty string as the user password, and if that fails, they will prompt for a password. Some packages, including qpdf, will try to see if the owner password might be empty even when the user password is not empty, and even though this doesn't really make much sense. That would explain the behavior you are seeing. I believe that older versions of Adobe Acrobat will not allow admin access to the file at all if the user and owner password match or if the user password is set and the owner password is empty because they only attempt to validate the owner password if the supplied password doesn't work as the user password.
Hopefully this explains the behavior you are seeing.
answered yesterday
Jay BerkenbiltJay Berkenbilt
112 bronze badges
New contributor
Jay Berkenbilt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
All the explanation seems right, but the point was to encrypt the file, not add owner restrictions, so it sounds like (excepting older Acrobat) setting both to the same password will suffice.
– Michael Homer
yesterday
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%2f535946%2fencrypting-pdf-with-qpdf-and-only-user-password%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
Punchline: most likely what you actually want to do is to use the empty string for the user password and a non-empty string for the owner password, not the other way around. If you do this, people will be able to open the file without supplying a password, but compliant viewers will still enforce the document's security. Opening with the owner password will allow you to modify security in a tool like Adobe Acrobat. Note that qpdf disregards the file's security in all cases and treats the user and owner passwords the same.
I'll try to explain what's going on.
Compliant PDF viewers are supposed to honor the file's security when the file is opened with the user password and allow full "admin" rights to the file when the file is opened with the owner password. As such, it doesn't make sense to provide a user password and not an owner password, as this would mean that not providing a password is more restrictive than providing a password.
In older PDF encryption formats, the file was encrypted by an encryption key that is derived from the user password, and the user password is actually stored in the file encrypted with the owner password. PDF viewers would first try to see if the supplied password is the user password. If so, they can retrieve the key and decrypt the file. If not, they check to see if it's the owner password. If so, they can retrieve the user password, and from there, they can retrieve the key. Newer encryption formats encrypt the actual key independently with both the user password and the owner password, and as such, it is not possible to retrieve the user password with the owner password.
Because of this behavior, some applications will try to open an encrypted password trying the empty string as the user password, and if that fails, they will prompt for a password. Some packages, including qpdf, will try to see if the owner password might be empty even when the user password is not empty, and even though this doesn't really make much sense. That would explain the behavior you are seeing. I believe that older versions of Adobe Acrobat will not allow admin access to the file at all if the user and owner password match or if the user password is set and the owner password is empty because they only attempt to validate the owner password if the supplied password doesn't work as the user password.
Hopefully this explains the behavior you are seeing.
answered yesterday
Jay BerkenbiltJay Berkenbilt
112 bronze badges
New contributor
Jay Berkenbilt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
All the explanation seems right, but the point was to encrypt the file, not add owner restrictions, so it sounds like (excepting older Acrobat) setting both to the same password will suffice.
– Michael Homer
yesterday
add a comment |
Punchline: most likely what you actually want to do is to use the empty string for the user password and a non-empty string for the owner password, not the other way around. If you do this, people will be able to open the file without supplying a password, but compliant viewers will still enforce the document's security. Opening with the owner password will allow you to modify security in a tool like Adobe Acrobat. Note that qpdf disregards the file's security in all cases and treats the user and owner passwords the same.
I'll try to explain what's going on.
Compliant PDF viewers are supposed to honor the file's security when the file is opened with the user password and allow full "admin" rights to the file when the file is opened with the owner password. As such, it doesn't make sense to provide a user password and not an owner password, as this would mean that not providing a password is more restrictive than providing a password.
In older PDF encryption formats, the file was encrypted by an encryption key that is derived from the user password, and the user password is actually stored in the file encrypted with the owner password. PDF viewers would first try to see if the supplied password is the user password. If so, they can retrieve the key and decrypt the file. If not, they check to see if it's the owner password. If so, they can retrieve the user password, and from there, they can retrieve the key. Newer encryption formats encrypt the actual key independently with both the user password and the owner password, and as such, it is not possible to retrieve the user password with the owner password.
Because of this behavior, some applications will try to open an encrypted password trying the empty string as the user password, and if that fails, they will prompt for a password. Some packages, including qpdf, will try to see if the owner password might be empty even when the user password is not empty, and even though this doesn't really make much sense. That would explain the behavior you are seeing. I believe that older versions of Adobe Acrobat will not allow admin access to the file at all if the user and owner password match or if the user password is set and the owner password is empty because they only attempt to validate the owner password if the supplied password doesn't work as the user password.
Hopefully this explains the behavior you are seeing.
answered yesterday
Jay BerkenbiltJay Berkenbilt
112 bronze badges
New contributor
Jay Berkenbilt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
All the explanation seems right, but the point was to encrypt the file, not add owner restrictions, so it sounds like (excepting older Acrobat) setting both to the same password will suffice.
– Michael Homer
yesterday
add a comment |
Punchline: most likely what you actually want to do is to use the empty string for the user password and a non-empty string for the owner password, not the other way around. If you do this, people will be able to open the file without supplying a password, but compliant viewers will still enforce the document's security. Opening with the owner password will allow you to modify security in a tool like Adobe Acrobat. Note that qpdf disregards the file's security in all cases and treats the user and owner passwords the same.
I'll try to explain what's going on.
Compliant PDF viewers are supposed to honor the file's security when the file is opened with the user password and allow full "admin" rights to the file when the file is opened with the owner password. As such, it doesn't make sense to provide a user password and not an owner password, as this would mean that not providing a password is more restrictive than providing a password.
In older PDF encryption formats, the file was encrypted by an encryption key that is derived from the user password, and the user password is actually stored in the file encrypted with the owner password. PDF viewers would first try to see if the supplied password is the user password. If so, they can retrieve the key and decrypt the file. If not, they check to see if it's the owner password. If so, they can retrieve the user password, and from there, they can retrieve the key. Newer encryption formats encrypt the actual key independently with both the user password and the owner password, and as such, it is not possible to retrieve the user password with the owner password.
Because of this behavior, some applications will try to open an encrypted password trying the empty string as the user password, and if that fails, they will prompt for a password. Some packages, including qpdf, will try to see if the owner password might be empty even when the user password is not empty, and even though this doesn't really make much sense. That would explain the behavior you are seeing. I believe that older versions of Adobe Acrobat will not allow admin access to the file at all if the user and owner password match or if the user password is set and the owner password is empty because they only attempt to validate the owner password if the supplied password doesn't work as the user password.
Hopefully this explains the behavior you are seeing.
answered yesterday
Jay BerkenbiltJay Berkenbilt
112 bronze badges
New contributor
Jay Berkenbilt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Punchline: most likely what you actually want to do is to use the empty string for the user password and a non-empty string for the owner password, not the other way around. If you do this, people will be able to open the file without supplying a password, but compliant viewers will still enforce the document's security. Opening with the owner password will allow you to modify security in a tool like Adobe Acrobat. Note that qpdf disregards the file's security in all cases and treats the user and owner passwords the same.
I'll try to explain what's going on.
Compliant PDF viewers are supposed to honor the file's security when the file is opened with the user password and allow full "admin" rights to the file when the file is opened with the owner password. As such, it doesn't make sense to provide a user password and not an owner password, as this would mean that not providing a password is more restrictive than providing a password.
In older PDF encryption formats, the file was encrypted by an encryption key that is derived from the user password, and the user password is actually stored in the file encrypted with the owner password. PDF viewers would first try to see if the supplied password is the user password. If so, they can retrieve the key and decrypt the file. If not, they check to see if it's the owner password. If so, they can retrieve the user password, and from there, they can retrieve the key. Newer encryption formats encrypt the actual key independently with both the user password and the owner password, and as such, it is not possible to retrieve the user password with the owner password.
Because of this behavior, some applications will try to open an encrypted password trying the empty string as the user password, and if that fails, they will prompt for a password. Some packages, including qpdf, will try to see if the owner password might be empty even when the user password is not empty, and even though this doesn't really make much sense. That would explain the behavior you are seeing. I believe that older versions of Adobe Acrobat will not allow admin access to the file at all if the user and owner password match or if the user password is set and the owner password is empty because they only attempt to validate the owner password if the supplied password doesn't work as the user password.
Hopefully this explains the behavior you are seeing.
answered yesterday
Jay BerkenbiltJay Berkenbilt
112 bronze badges
New contributor
Jay Berkenbilt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered yesterday
Jay BerkenbiltJay Berkenbilt
112 bronze badges
New contributor
Jay Berkenbilt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered yesterday
Jay BerkenbiltJay Berkenbilt
112 bronze badges
answered yesterday
Jay BerkenbiltJay Berkenbilt
112 bronze badges
112 bronze badges
New contributor
Jay Berkenbilt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Jay Berkenbilt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
All the explanation seems right, but the point was to encrypt the file, not add owner restrictions, so it sounds like (excepting older Acrobat) setting both to the same password will suffice.
– Michael Homer
yesterday
add a comment |
1
All the explanation seems right, but the point was to encrypt the file, not add owner restrictions, so it sounds like (excepting older Acrobat) setting both to the same password will suffice.
– Michael Homer
yesterday
1
1
All the explanation seems right, but the point was to encrypt the file, not add owner restrictions, so it sounds like (excepting older Acrobat) setting both to the same password will suffice.
– Michael Homer
yesterday
All the explanation seems right, but the point was to encrypt the file, not add owner restrictions, so it sounds like (excepting older Acrobat) setting both to the same password will suffice.
– Michael Homer
yesterday
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.
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%2f535946%2fencrypting-pdf-with-qpdf-and-only-user-password%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
