I have a .bmp image. I wanted to encrypt the image file using openssl command. The following is the command I have used to encrypt the image.
openssl enc -aes-128-cbc -e -in pic_original.bmp -out aes128cbc.bmp -K 00112233445566778889aabbccddeeff -iv 0102030405060708
As per ECB mode is concerned I should be able to view partial image when I encrypt the file using ECB mode however I cannot see the image at all. The image viewing software says there is bogus header data
Is there any thing wrong in the command I used for encrypting the file. Can someone help me with this please
Thanks
You can easily copy the header back on top of the image:
dd if=/path/oldfile.bmp of=newfile.bmp bs=54 count=1 conv=notrunc
To learn about dd:
man dd
You can search for examples of this on the web .E. Hugo's blog
That's because you encrypted everything, including header. You should extract bitmap data into a raw stream, encrypt that and attach header back to it.
You need to extract the header from the original image and use it to replace the header of the encrypted file. Generally for a bmp file, the first 54 bytes contain the header info.
to do this:
head -c 54 pic_og.bmp > header
tail -c +55 pic_cbc.bmp > body_cbc
cat header body_cbc > new_enc_cbc.bmp
Related
There is numbers of tools that converts certdata.txt from here into .pem format again. However I would need to do it the opposing way: create certadata.txt from a given .pem or .der file.
Does anyone knows a tool that converts *.pem certs into the certdata.txt?
After getting a closer look of nss-tools I have found what I really needed:
nss-addbuiltin:
Read a der-encoded cert from certfile or stdin, and output
it to stdout in a format suitable for the builtin root module.
Example: nss-addbuiltin -n MyCA -t "C,C,C" -i myca.der >> certdata.txt
The file you referenced is a definition file. You generally never feed it directly to an application, instead you convert the certdata.txt into a list of certificates in .pem format.
This is what most of consumers fo:
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/J7mY_cpOyX4
http://curl.haxx.se/cvssource/lib/mk-ca-bundle.pl
https://security.stackexchange.com/questions/42946/where-can-i-find-all-ssl-ca-certificates
If you use the PEM list, then it's just as simple as adding your certificate to the end of that list.
How can I safely store sensitive data online?
I want to store some extremely sensitive information online in a public folder, and I'm not sure how to go about it.
Specifically, I want to store bitcoin private keys in a .json file named "walletData.json" in a public folder. The file contains the wallet address and public key in plain text, along with an encrypted version of the private key.
Assuming anyone can access the file and attempt to crack the encryption password with their "super computers", what's the best way to safely encrypt that private key?
I know a longer password would be a good start, but ideally I don't want to need a password longer than 10 characters.
I was thinking of maybe hashing the password 1000 times, then using that hash+password as an AES encryption key. But, as everyone can see the key generation method, i'm not sure that will help? I was also thinking of padding out the encrypted private key with some other random data, but again, I don't know if it'll really help??
Is there a safe way to do this?
EDIT - after Reid's answer:
I'm trying to do this 100% in Javascript/jQuery.
When I export a CoinPrism.com wallet, I get this:
{"keys":[{"addr":"1PNLiLgW2fBokCB2wmfhZTtbmioitkqtMm","priv":"172655af193edeb54467a52fc6eb94c67eeeff8cd03555767e5cf12df694bb88f9c8b25c4019147d9e4993405274c96a","encryptionMode":"PKBDF2-SHA256","iterations":2000}],"salt":"2222b67fc7255aaf0b4027bfcabffb5e62f39e9e0aa13e8ad70f2dc75a484f26"}
The "priv" value is an encrypted private key. I don't know exactly how it's encrypted, but i'm sure that there's a way to decrypt it using just my 10 character password.
Does anyone know how they're doing this?
Is it safe to store this information online?
Well, I will just say outright that you don't need to be the one who writes the code to do this — it is far too easy to mess up, and your post makes suggestions that are concerning. (For instance, you describe something of an ad-hoc key derivation scheme, but one that is insufficient in protection.)
So, you need a library of some kind to handle this business for you.
My suggestion: Use GPG with the ASCII armor option. For example:
gpg --symmetric --armor --cipher-algo AES file.txt
This will symmetrically encrypt (--symmetric) a file (file.txt here) using the AES cipher (--cipher-algo AES) and store the resulting encrypted file in an ASCII armored format (--armor). Note: the resulting encrypted file will be stored in the filename plus the extension .asc; e.g., here, it puts the result in file.txt.asc. You can change this with the --output option.
Now, the above command will prompt you for a passphrase — this passphrase needs to be very strong, far more than 10 characters I'm afraid. This is the burden of passphrase-based encryption: you need passphrases that are strong. Ideally, you want a passphrase that is long and complicated, hard-to-guess and hard-to-bruteforce.
Since we are on StackOverflow, you may be looking to automate the passphrase entry (using scripting). To do that, there are several --passphrase related options for GPG. For example,
gpg --batch --passphrase "test" --symmetric --armor --cipher-algo AES file.txt
will use the passphrase test instead of prompting the user. Command line arguments are not safe, however, on a system, so it would be better to use the --passphrase-from-file option, which takes a single file as an argument. The first line of that file is the passphrase to be used.
Hi I understand that Concat is possible with Gzip function on OS File system,
i.e.
gzip -c a.txt > a.gzip
gzip -c b.txt > b.gzip
now below is also correct,
cat a.txt b.txt | gzip -c > ab.gzip # is same as
cat a.gzip b.gzip > ab.gzip
At file system this seems correct to me, but when I try to implement the same concept with node.js to concat, header (pre-gzipped content), main-content (pre-gzip), side-bar and other widgets which are pre-gzip binary data files on filesystem than it doesn't seem working for me, I can only see text content of first chunk (header) and other appended content displayed as random binary symbols.
First want to understand is it possible and if yes then how can I implement fragmented caching.
I just want to see if it is possible with compressed fragmented caching, otherwise plan B is to use plain fragmented caching and gzip content runtime.
var rs1 = fs.createReadStream('./node_fs/index/index.txt.gz');
var rs2 = fs.createReadStream('./node_fs/index/content.txt.gz');
res.write(rs1);
res.write(rs2);
Additionally, both files are compressed using gzip.exe command line and if I write only one of them than it works fine, but append doesn't work.
Your original gzip example "works" because the gunzip tool is written to handle multiple entries in a single file. It doesn't work with some browsers because they expect a single gzip entry.
See: Concatenate multiple zlib compressed data streams into a single stream efficiently
when generating a password file using htpasswd -m -c file admin with the password admin the result looks like this:
cat file
admin:$apr1$V.aqW878$JCj8ivmSnFp3BnTCtLAuN.
When I try to authenticate against that using node.js the results are rather different:
Digest Hex: 21232f297a57a5a743894a0e4a801fc3
I've tried following this existing StackOverflow solution:
new Buffer('21232f297a57a5a743894a0e4a801fc3').toString('base64');
MjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzM=
So the result was still wrong.
When I change the digest to base64 the result would be:
ISMvKXpXpadDiUoOSoAfww==
Bottom line of my problem is that I don't get the same hashes and need help. Any advice would be greatly appreciated.
Thank you
Roman
Alright, I found the answer. htpasswd uses a "salt" which is stored in the middle bit of the password string:
$apr1$V.aqW878$JCj8ivmSnFp3BnTCtLAuN.
Salt: V.aqW878
The node-pass module gave me the right clues. See validate_md5. It uses the native openssl command to generate a salted MD5 hash.
In retrospect this makes sense since MD5 isn't safe anymore. That's the reason I didn't use it for years now and got a bit off track here. In essence, anything marked with $apr1$ is to be treated like this.
I tried to examine the content of a .torrent file using a
$ od -c xyz.torrent
Some of the content of the file is in plain text like the information regarding the trackers, creation date, the encoding used,the length and the number of pieces but the rest is encoded. Can somebody please tell me how i can examine the torrent file so that i can decode everything.
.torrent files are bencoded dictionaries
More information
Use lstor from the pyroscope package: https://code.google.com/p/pyroscope/wiki/CommandLineTools#lstor
It pretty-prints the contents of .torrent files.