Thanks for reporting; this is a duplicate of https://sourceforge.net/p/ccrypt/bugs/30/.
This is a duplicate of https://sourceforge.net/p/ccrypt/bugs/24/ and https://sourceforge.net/p/ccrypt/bugs/30/.
Forgot, I know nothing about lisp, but if I find something I will add it here
ccrypt ps-ccrypt.el + Emacs 30.1
Great, thanks for the clarification. According to the documentation, (make-vector 31 0) should be both backward and forward compatible. That change was already made with https://sourceforge.net/p/ccrypt/bugs/30/, though I haven't yet made a release since then.
obarray-make has been introduced in Emacs 25.1.
Will this break support for Emacs versions prior to 30.1?
Replace make-vector by obarray-make in Emacs 30.1
I know this is an old topic but this hack fixes the problem: change the 17th byte of the ccrypt binary from value 02 to 03 using a hex editor.
ps-crypt 1.11 breaks with development version of emacs
At least (make-vector 31 0) doesn't seem to break anything for me, so I'm happy to make that change.
Changing (make-vector 31 nil) to (make-vector 31 0) seems to fix it for me, but I'm not an expert and this is only very lightly tested.
ps-crypt 1.11 breaks with development version of emacs
Spelling error in manual page
Thanks. This is a duplicate of 0020-man-page-spelling-error.patch in the Debian distribution. Will be fixed in the next release.
Spelling error in manual page
Option to keep rather than wiping original files.
Thanks for quick response(s) on the matter. Yeah, I'm sometimes in Windows, sometimes in Linux. I reckon your "< > method" works in CMD.EXE environment, W10. However, I hold to the opinion that a simple switch for keeping original files would be great. That way, one who has the need for such possibility and who does not want to type the < > stuff every time won't have to write different batch scripts for different operating systems. Also, such scripts are not made with ease, well at least not with...
Yes, and also, the method mentioned in my response to feature request 8 works, i.e., you can do ccrypt < infile > outfile. This of course presupposes that you are using an operating system that understands pipelines, like "<" and ">". Certainly Mac OS and Linux do; with Windows, it may depend on what kind of command line prompt you are using.
Heh, if I had read the man page just a bit more I would have found the -c switch, which makes it possible to > the output wherever is to my liking. Neat. Anyways, this way I still have to type a phony filename for the output. A e.g. -k(eep) switch that simply uses the same naming uniform but keeps input (regardless of -d or -e for action) would still be highly appreciated! :)
Option to keep rather than wiping original files.
Hi, the ccrypt package was removed from Fedora 38 as compilation fails. Could this be fixed, please?
Hi. We are using ccrypt 1.11 in an Alpine-based Docker image. I have a question. Is glibc used in ccrypt at runtime / compile time? If so, which version? Thanks in advance. Regards, Mattia Micomonaco
Hello Peter, With --disable-libcrypt configuration option, the test is skipped, thus this is OK. Thanks.
I believe the failed test is caused by recent versions of the crypt3 library not being backward compatible. Please use the --disable-libcrypt configuration option (with ./configure). Then ccrypt will work correctly (although the crypt3 test may still fail). Also note that the crypt3 library is only used in unix-crypt mode, i.e., when ccrypt is used with the -u option. Hopefully this is extremely rarely used, as it's been about 25 years since unix crypt even existed. I'll remove this test and the...
The end of the test: Discrepancy for salt zv, password length 4 Discrepancy for salt zv, password length 7 Discrepancy for salt zT, password length 6 Failed: 817 discrepancies. FAIL crypt3-check (exit status: 1)
Crypt3_check fails with GCC 12
I keep ccrypt.exe and cgwin1.dll in a local bin dir within my "Users" directory in Windows, and it is in my user path. I had never used the --recursive option to encrypt whole directory structures before, but when I did try this morning, ccrypt encrypted the first four files in the target directory and stopped. Additionally, ccrypt.exe mysteriously disappeared from its own directory, and I had to re-extract a new copy from its archive. I re-created this several times using different directories and...
I keep ccrypt.exe and ccrypt.dll in a local bin dir within my "Users" directory in Windows, and it is in my user path. I had never used the --recursive option to encrypt whole directory structures before, but when I did try this morning, ccrypt encrypted the first four files in the target directory and stopped. Additionally, ccrypt.exe mysteriously disappeared from its own directory, and I had to re-extract a new copy from its archive. I re-created this several times using different directories and...
Hi NickSoft, thanks for writing. That feature request makes a lot of sense. You have probably already discovered the "-v" option, which tells you which file is currently being encrypted (but does not the progress within each file). That is useful if you are encrypting many files and you want to know how many are finished. Not so useful if you just have one gigantic file. ccrypt is so fast that I never needed a progress bar before for any kind of normal sized file. But indeed, disk dumps are a bit...
Progress display while encrupting
I will end the discussion here and just proceed to advise anyone who is asking against using ccrypt.
At this point you are just flaming me. Here is the definition of "Encryption" from Wikipedia. The information you seem to be misunderstanding is right there in the 4th sentence: "In cryptography, encryption is the process of encoding information. This process converts the original representation of the information, known as plaintext, into an alternative form known as ciphertext. Ideally, only authorized parties can decipher a ciphertext back to plaintext and access the original information. Encryption...
I still think that your FAQs are misleading. The answer to the question "We are thinking of using ccrypt in our company to encrypt our data. Is ccrypt still a strong encryption that is very hard to break?" should be a "No." The response to the question "Does ccrypt implement an authenticated encryption scheme to protect the integrity of the encrypted data? " implies that not providing integrity protection is not a big deal and your suggestion to add an outdated SHA-1 hash at the beginning of the...
Perhaps people expect the author of an encryption tool to provide a proper solution. I was personally asked by a colleague if it is okay to use your application and I had to advise against it. You expect end users to know their way around cryptography which is a false assumption.
I have added this question to the FAQ. The reason it was not there is that nobody has asked this question before. Perhaps not everybody skips the documentation.
This must be some kind of joke. This problem should be mentioned directly on the website and in the security section of the FAQs. Instead you hide this crucial information in the manpages in a section that starts with the false claim that "ccrypt is believed to provide very strong cryptographic security". Actually, I dispute this claim as providing integrity guarantees is part of providing very strong cryptographic security. As I see it right now, ccrypt is outdated cryptographic software that hides...
Missing integrity protection
As this is not a bug report, I am closing it.
Yes, that is correct. The documentation also says this. From the man page: "On the other hand, ccrypt does not attempt to provide data integrity, i.e., it will not attempt to detect whether the ciphertext was modified after encryption. In particular, encrypted data can be truncated, leaving the corresponding decrypted data also truncated, but otherwise consistent. If one needs to ensure data integrity as well as secrecy, this can be achieved by other methods. The recommended method is to prepend...
Missing integrity protection
Allow me to suggest to be your WindowsXP test guy, should you decide to continue with the compiler that you used upto 1.10 :)
I am willing to be your WindowsXP test guy, should you decide to continue with the compiler that you used upto 1.10 :)
In that case it means that I myself could not have performed Solution #2 either? (Compiling myself) I don't know. You have one decisive advantage, which is that you actually own a copy of Windows XP. I imagine that whatever compiler comes with XP would probably work. I haven't had a computer running XP in many years, so it is hard for me to test.
Hi Peter >the problem is that likely I will not have access to an older compiler. In that case it means that I myself could not have performed Solution #2 either? (Compiling myself) >1.7. Is this the latest version that runs on XP? That's actually a terrific idea. I downloaded now 1.8 till 1.11 (wanted to try 1.11 again). The results are: 1.8: Working :) 1.9: Working :) 1.10: Working :) 1.11: Not Working :)) So it seems the problem only starts from 1.11.. All version upto it work great. I tried both...
Hi Peter >the problem is that likely I will not have access to an older compiler. In that case it means that I myself could not have performed Solution #2 either? (Compiling myself) >1.7. Is this the latest version that runs on XP? That's actually a terrific idea. I downloaded now 1.8 till 1.11 (wanted to try 1.11 again). The results are: 1.8: Working :) 1.9: Working :) 1.10: Working :) 1.11: Not Working :)) So it seems the problem only starts from 1.11.. All version upto it work great. I tried both...
Hi Peter >the problem is that likely I will not have access to an older compiler. In that case it means that I myself could not have performed Solution #2 either? (Compiling myself) >1.7. Is this the latest version that runs on XP? That's actually a terrific idea. I downloaded now 1.8 till 1.11 (wanted to try 1.11 again). The results are: 1.8: Working :) 1.9: Working :) 1.10: Working :) 1.11: Not Working :)) So it seems the problem only starts from 1.11.. All version upto it work great. I tried both...
Hi Peter >the problem is that likely I will not have access to an older compiler. In that case it means that I myself could not have performed Solution #2 either? (Compiling myself) >1.7. Is this the latest version that runs on XP? That's actually a terrific idea. I downloaded now 1.8 till 1.11 (wanted to try 1.11 again). The results are: 1.8: Working :) 1.9: Working :) 1.10: Working :) 1.11: Not Working :)) So it seems the problem only starts from 1.11.. All version upto it work great. I tried both...
Hi Peter >the problem is that likely I will not have access to an older compiler. In that case it means that I myself could not have performe Solution #2? (Compiling myself) >1.7. Is this the latest version that runs on XP? That's actually a terrific idea. I downloaded now 1.8 till 1.11 (wanted to try 1.11 again). The results are: 1.8: Working :) 1.9: Working :) 1.10: Working :) 1.11: Not Working :)) So it seems the problem only starts from 1.11.. All version upto it work great. I tried both running,...
Hi Spaceman, the problem is that likely I will not have access to an older compiler. But the changes to ccrypt in the last 15 years have been mostly compatibility updates, so there is nothing wrong in principle with using ccrypt 1.7. Is this the latest version that runs on XP? -- Peter
Hi Peter Thank you very much for the reply. I downloaded v1.7 (file: http://ccrypt.sourceforge.net/download/1.7/ccrypt-1.7.cygwin-i386.zip ) and indeed it now runs well, and I also tested it and it Encrypts and Decrypts well. Is it maybe possible in the next version to compile it to work for XP too? (assuming it does not require any change in the code, and justmeans using a different/older compiler)
Hi Peter Thank you very much for the reply. I downloaded v1.7 (file: http://ccrypt.sourceforge.net/download/1.7/ccrypt-1.7.cygwin-i386.zip ) and indeed it now runs well, and I also tested it and it Encrypts and Decrypts well. Is it maybe possible in the next version to compile it to work for XP too? (assuming it does not require any change in the code, and justmeans using a different/older compiler)
ccrypt on Windows XP
Thanks for reporting this. The error message likely means that the Windows XP kernel is too old to support this version of ccrypt. You have several options: (1) use an older precompiled version of ccrypt. You can find the older files here: http://ccrypt.sourceforge.net/download/ For example, release 1.7 from 2004 will most likely run on Windows XP. There have been no major bugfixes since 1.7, so this version will work just fine. (2) Compile it yourself from sources. This requires installing Cygwin...
ccrypt on Windows XP
Thanks for reporting this. I will fix this bug in the next release. It may be caused by an incompatibility between the GNU getopt library and the one included in cygwin. Meanwhile, please configure with ./configure --with-included-getopt This should make the problem go away. Thanks, -- Peter
Thanks for reporting this. I will fix this bug in the next release. It may be caused by an incompatibility between the GNU getopt library and the one included in cygwin. Meanwhile, please configure with configure --with-included-getopt This should make the problem go away. Thanks, -- Peter
ccrypt-check.sh wrong test
ps-ccrypt broken on Emacs 26.1
This was fixed in ccrypt 1.11.
ccrypt 1.11 released
Thanks, tested on 26.1. Works a treat! :)
Thanks for the prompt reply Peter! Much appreciated. I actually hadn't even realised I'd upgraded Emacs along with a bunch of other packages, and spent some time in mild confusion :) "How did this work yesterday? What's changed????"
Thanks for reporting this. I have not yet upgraded to Emacs 26, so I didn't experience this bug myself. I have put an updated version of ps-ccrypt.el here: http://ccrypt.sourceforge.net/#news I will release an updated version of ccrypt soon. -- Peter
ps-ccrypt broken on Emacs 26.1
Okay - I'll give that a try and thanks so much for your fast reply. have a GREAT day, mikeB code-it.com On 09/05/2017 04:42 PM, Peter Selinger wrote: Ccrypt itself does not do this, because it is a command line tool. However, you can easily write a script that prompts the user for the password via a GUI and then invokes ccrypt. For example, the attached is a simple Tcl/TK script (adapted from http://wiki.tcl.tk/3131) that prompts for a password and then echos the password to its standard output....
Popup input?
Ccrypt itself does not do this, because it is a command line tool. However, you can easily write a script that prompts the user for the password via a GUI and then invokes ccrypt. For example, the attached is a simple Tcl/TK script (adapted from http://wiki.tcl.tk/3131) that prompts for a password and then echos the password to its standard output. You could pipe the password directly into ccrypt like this: wish getpass.tk | ccrypt -k- myfile This would encrypt the file "myfile" with the password...
Ccrypt itself does not do this, because it is a command line tool. However, you can easily write a script that prompts the user for the password via a GUI and then invokes ccrypt. For example, the attached is a simple Tcl/TK script (adapted from http://wiki.tcl.tk/3131) that prompts for a password and then echos the password to its standard output. You could pipe the password directly into ccrypt like this: wish getpass.tk | ccrypt -k- myfile This would encrypt the file "myfile" with the password...
Popup input?
Hi all, Is there a CCrypt for Linux SuSE 11 SP4 (s390x architecture) 64bits ? Be it RPM or compile version... Thanks.
ps-ccrypt.el not working with Emacs 24.5.1