I am using OpenSSL to encrypt my data. Assuming I have 3 rows of data(for simplicty)
0123456789
987654321
121212121
After encrypting, I get
Salted__èøm¬è!^¬ü
?‘¡ñ1•yÈ}, .◊¬ó≤|Úx$mø©
However, when I copy using my Mac's CMD+ C, then I paste in another file to be decrpyted, i get this error
bad decrypt
0076160502000000:error:1C80006B:Provider routines:ossl_cipher_generic_block_final:wrong final block length:providers/implementations/ciphers/ciphercommon.c:429:
However if I did not copy and paste the encrpyted data, it can be decrypted properly. I believe is due to the spacings changed.. Is it that we cannot copy the data to another file to be decrpyted and MUST use the exact file that was encrpyted?
Related
I tried PGP encrypting a file in ChoPGP library. At the end of the process it shows embedded file name along with the whole original file name path.
But I thought it will show only the filename without the whole path. Which I intend to work on and figure out a way to do so?
Doing the following:
using (ChoPGPEncryptDecrypt pgp = new ChoPGPEncryptDecrypt())
{
pgp.EncryptFile(#"\\appdevtest\c$\appstest\Transporter\test\Test.txt",
#"\\appdevtest\c$\appstest\Transporter\test\OSCTestFile_ChoPGP.gpg",
#"\\appdevtest\c$\appstest\Transporter\pgpKey\PublicKey\atorres\atorres_publicKey.asc",
true,
true);
}
which will result in:
But I would like to only extract the Test.txt in the end something
like this:
Looking at this line from the ChoPGP sources: https://github.com/Cinchoo/ChoPGP/blob/7152c7385022823013324408e84cb7e25d33c3e7/ChoPGP/ChoPGPEncryptDecrypt.cs#L221
You may find out that it uses internal function GetFileName, which ends up with this for the FileStream: return ((FileStream)stream).Name;.
And this one, according to documentation, Gets the absolute path of the file opened in the FileStream..
So you should either make fork of ChoPGP and modify this line to extract just filename, or submit a pull request to the ChoPGP. Btw, it's just a wrapper around the BouncyCastle so you may use that instead.
Implement the Caesar Cipher algorithm to encrypt and decrypt a file contents using C language. The cipher basic all use algorithm . Your program should have two C files named encrypt.c and decrypt.c that contains encrypt() and decrypt() functions correspondently for the purpose. In the encryption.c file, use the main() function to take input from a “input.txt” file and store the encrypted message to “enc_msg.txt” file. In the decryption.c file, use the main() function to take input from a “enc_msg.txt” file and store the decrypted message to “dec_msg.txt” file and print the decrypted message in console output as well. The key is 3.
Thanks
Create two .c files encrypt.c and decrypt.c
Create sample data input.txt file
Run your encrypt program to create output file enc_msg.txt from input.txt file
Run your decrypt program to create output file dec_msg.txt from input enc_msg.txt file
So you need to create 3 files encrypt.c decrypt.c and input.txt
And running your programs will generate two more files enc_msg.txt and dec_msg.txt
For my job, I have to use an .my.cnf file to pass a password key into my R code, since I cannot (for security reasons) keep my password key in the R code itself. So I have R code that looks like this:
library(configr)
my_configs = read.config(file = "~/.my.cnf")
my_googleservicekey = my_configs$api_authentication$googleServiceKeyJsonString
Separately, I have a .my.cnf file saved on my computer, and that file looks like this:
[api authentication]
googleServiceKeyJsonString = {\r\n \"type"\: \"service_account\",\r\n \"project_id\": ... ... \r\n}
where the ... ... signifies that the actual googleServiceKey is much longer. This key was provided by a coworker of mine, and needs to be set exactly as such in the R variable my_googleservicekey. However, when I save the key like this in the .my.cnf file, and read it into R in the manner that I did, I get the following:
> my_googleservicekey
[1] "{\\r\\n \\\"type\\\": \\\"service_account\\\",\\r\\n \\\"project_id\\\": ... ... \\r\\n}"
So what happens is, sometime when read.config(file = "~/.my.cnf") is run, the
object/string I passed/saved into the .my.cnf file looks like it had all of the quotes and backslashes escaped, and as a result I don't have the correct variable in R.
My question then is this:
Is it possible to save the key in the .my.cnf and have read.config in R read the key EXACTLY as it is saved in the .my.cnf file, so that it doesn't add the additional escapes?
Thanks in advance for any help with this!!
EDIT: In particular, are there any parameters to R's read.config function, or any other functions in R that could help out with this?
I wrote a script that executes commands in parallel. I let them all write an entry to the same log file. It does not matter if the order is wrong or entries are interleaved, but i noticed that some entries are missing. I should probably lock the file before writing, however, is it true that if multiple processes try to write to a file simultaneously, it will result in missing entries?
Yes, if different processes independently open and write to the same file, it may result in overlapping writes and missing data. This happens because each process will get its own file pointer, that advances only by local writes.
Instead of locking, a better option might be to open the log file once in an ancestor of all worker processes, have it inherited across fork(), and used by them for logging. This means that there will be a single shared file pointer, that advances when any of the processes writes a new entry.
In a script you should use ">> file" (double greater than) to append output to that file. The interpreter will open the destination in "append" mode. If your program also wants to append, follow the directives below:
Open a text file in "append" mode ("a+") and give preference to printing only full lines (don't do multiple 'print' followed by a final 'println', but print the entire line with a single 'println').
The fopen documentation states this:
DESCRIPTION
The fopen() function opens the file whose pathname is the
string pointed to by filename, and associates a stream with
it.
The argument mode points to a string beginning with one of
the following sequences:
r or rb Open file for reading.
w or wb Truncate to zero length or create file
for writing.
a or ab Append; open or create file for writing
at end-of-file.
r+ or rb+ or r+b Open file for update (reading and writ-
ing).
w+ or wb+ or w+b Truncate to zero length or create file
for update.
a+ or ab+ or a+b Append; open or create file for update,
writing at end-of-file.
The character b has no effect, but is allowed for ISO C
standard conformance (see standards(5)). Opening a file with
read mode (r as the first character in the mode argument)
fails if the file does not exist or cannot be read.
Opening a file with append mode (a as the first character in
the mode argument) causes all subsequent writes to the file
to be forced to the then current end-of-file, regardless of
intervening calls to fseek(3C). If two separate processes
open the same file for append, each process may write freely
to the file without fear of destroying output being written
by the other. The output from the two processes will be
intermixed in the file in the order in which it is written.
It is because of this intermixing that you want to give preference to
using only 'println' (or its equivalent).
We've recently moved a website to a new server, and are running into an odd issue where some uploaded images with unicode characters in the filename are giving us a 404 error.
Via ssh/FTP, we can see that the files are definitely there.
For example:
http://sjofasting.no/project/adnoy
none of the images are working:
Code:
<img class='image-display' title='' src='http://sjofasting.no/wp/wp-content/uploads/2012/03/ådnøy_1_2.jpg' width='685' height='484'/>
SSH:
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 836813 Aug 3 16:12 ådnøy_1_2.jpg
What is also strange is that if you navigate to the directory you can even click on the image and it works:
http://sjofasting.no/wp/wp-content/uploads/2012/03/
click on 'ådnøy_1_2.jpg' and it works.
Somehow wordpress is generating
http://sjofasting.no/wp/wp-content/uploads/2012/03/ådnøy_1_2.jpg
and copying from the direct folder browse is generating
http://sjofasting.no/wp/wp-content/uploads/2012/03/a%CC%8Adn%C3%B8y_1_2.jpg
What is going on??
edit:
If I copy the image url from the wordpress source I get:
http://sjofasting.no/wp/wp-content/uploads/2011/11/Bore-Strand-Hotellg%C3%A5rd-12.jpg
When copied from the apache browser I get:
http://sjofasting.no/wp/wp-content/uploads/2011/11/Bore-Strand-Hotellga%cc%8ard-12.jpg
What could account for this discrepancy between:
%C3%A5 and %cc%8
??
Unicode normalisation.
0xC3 0xA5 is the UTF-8 encoding for U+00E5 a-with-ring.
0xCC 0x8A is the UTF-8 encoding for U+030A combining ring.
U+0035 is the composed (Normal Form C) way of writing an a-ring; an a letter followed by U+030A is the decomposed (Normal Form D) way of writing it. å vs å - they should look the same, though they may differ slightly depending on font rendering.
Now normally it doesn't really matter which one you've got because sensible filesystems leave them untouched. If you save a file called [char U+00E5].txt (å.txt), it stays called that under Windows and Linux.
Macs, on the other hand, are insane. The filesystem prefers Normal Form D, to the extent that any composed characters you pass into it get converted into decomposed ones. If you put a file in called [char U+00E5].txt and immediately list the directory, you'll find you've actually got a file called a[char U+030A].txt. You can still access the file as [char U+00E5].txt on a Mac because it'll convert that input into Normal Form D too before looking it up, but you cannot recover the same filename in character sequence terms as you put in: it's a lossy conversion.
So if you save your files on a Mac and then transfer to a filesystem where [char U+00E5].txt and a[char U+030A].txt refer to different files, you will get broken links.
Update the pages to point to the Normal Form D versions of the URLs, or re-upload the files from a filesystem that doesn't egregiously mangle Unicode characters.
Think Different, Cause Bizarre Interoperability Problems.