ipfs or storj
hash of image and store file on s3
convert the image to a Base64 string and store string in composer model
You can use String and base64 encode it - as a field in an Asset for example.
The question has been discussed here:
How can I convert MP3 file to a Base64 encoded string?
and here:
How to deal with forms,images,videos of an asset in hyperledger composer .
Storing images, scans, audio files is not a 'best practice' - rather, a cryptographic hash of it (referenced off-chain) is verifiable proof that the source is the exact image/media file that was 'hashed' at the time the 'transaction' was recorded on the blockchain and link out of the chain, to a URL containing the verifiable source (and comparable hash). Examples may be: doctor/patient audio discussions (not least the privacy elements!) & consultation recordings, PDFs, mp3s, image files. Another issue is that an encoded base64 image string (if you chose to encode the media/image file that is) will also need to be transmitted to the other peers participating in consensus and written to their copy of the master ledger. It is therefore more efficient, to only share the hash (not the base64 encoded contents with each peer).
Sahil, you need not store an encrypted file in blockchain. One solution is (for keeping privacy of your data) to store the hash of your file in an asset field. The encryption of the same data will sit outside the blockchain, so your have to create one asset field containing the link to that encrypted file.
Related
Given the following situation:
document source of type PDF freshly received via a file transfer
document target which is saved as an attachment blob using active_storage and versionned
I want to check whether any existing version of target is binary-equal to source. Without active_storage, I'd have done a SHA256 sum of any blob that enters the DB. In order to compare, I'd have compared the fresh SHA256 sum of source to each checksum stored for any version of target.
However the method .checksum of active_storage attachments and blobs appears to be neither a MD5 or SHA265 sum. For instance I get Cr4IxYNF7v7cJao1EiiBEw== for some file.
A solution would be to use something like Digest::SHA256.hexdigest(Person.find(46).photo.download) however the performance would be terrible.
How can I efficiently search my active_storage "database" ?
According to the ActiveStorage source, the checksum is in fact MD5. But it has been base64 encoded.
From the source at: https://github.com/rails/rails/blob/8da6ba9cae21beae1ee3c379db7b7113d2731c9b/activestorage/app/models/active_storage/blob.rb#L313
def compute_checksum_in_chunks(io)
Digest::MD5.new.tap do |checksum|
while chunk = io.read(5.megabytes)
checksum << chunk
end
io.rewind
end.base64digest
end
So hopefully you should be able to just base64 encode your own MD5 hashes for a comparison in the database.
I am using 'RijndaelManaged' and 'CryptoStream' classes in C# to encrypt files. Before encrypting the files, i want to check whether the file is already encrypted or not.
I tried using File.GetAttributes() method to check for Encryption but it is not working.
I need some tips on ways i can check whether the file is already Encrypted or not.
Without any sort of custom headers, the only way to be absolutely sure the file is encrypted is to attempt to decrypt it.
If you attempt to compress the file and it gets smaller, then it is extremely unlikely to be encrypted. If there is a non-uniform distribution of byte values (including plain text!), then it is unlikely to be encrypted.
Those heuristics depend on proper execution of the encryption. If AES is applied to a file one block at time, then patters can emerge in the result, but since you are using CryptoStream this shouldn't be a problem.
If your own code will always be used to encrypt and decrypt the files, then you should consider adding a custom header that indicates it is an encrypted file.
Suppose I have a file F containing ciphertext X, which is the enciphering of plaintext Y with key Z.
I wish to ensure that the plaintext Y can only be determined by someone who possesses both key Z and key Q. (I can think of a number of reasons why I might wish to do this.)
I therefore wish to encrypt the already-encrypted file with key Q.
You're telling me that your system wishes to detect that F is already encrypted, and then refuse to encrypt it with key Q?
That seems like a bad idea. I might want to encrypt the file with key Q irrespective of whether it is already encrypted with key Z or not.
You have to inspect the file and look for structures, or byte strings that would not be there if the file is encrypted. You would need a separate test for every type of file you are dealing with.
If the file is encrypted it will appear as a stream of random bytes. You can:
Attempt to open the file and/or confirm that it is of the expected format (JPG, ZIP, whatever). If the file matches a known format then you know it is decrypted.
Attempt to decrypt the file if you have the key, then repeat the previous step. If it now matches a known format then you know it is (was?) encrypted.
I would suggest rename the encrypted file at encryption process with something with you can check it when you want to decrypt it.
Set your encrypt method bool type, if the file can decrypt, then the method return true which indicates the file is encrypted, otherwise the method throw exception and return false which indicates the file cannot be decrypted, or say the file is not encrypt.
This is what I want to accomplish:
On an extranet with a feed wall, users just type non-formatted text (non style, just \n and links recognition).
But quite often, users want to add a link to a document which is stored in the same extranet (using dragonfly). Obviously, the link is quite awful to display (ex: https://extranet.com/media/l0ngUiD/original_filename.pdf?sha=31310881DAEF1).
This document refers to a Document instance which has a nice title, ex: "Original Filename (PDF)"
I would like those links to be (automatically) replaced by
Original Filename (PDF)
Problem is: how to find which model and which document this document refers to, using the UID and sha.
I guess this is possible as Dragonfly decodes the url, but I can't find how to (not much comments in the code).
The variant's UID is Base64 encoded, so when decoding the UID you will get a JSON encoded array of Dragonfly processor steps.
Here an actual example from a live database:
uid = 'W1siZiIsIjIwMTUvMDcvMDkvMDkvMTMvMDIvOTE3LzE5NDg3ODk0MDc1XzE4NGYzMjc0MWVfay5qcGciXV0'
Base64.decode64 uid
# => "[[\"f\",\"2015/07/09/09/13/02/917/19487894075_184f32741e_k.jpg\"]]"
Each step is an array with the step's operation in the first element and the step's arguments in the remaining.
The flow is:
The user selects an image on the client.
Only filename, content-type and size are sent to the server. (E.g. "file.png", "image/png", "123123")
The response are fields and policies for upload directly to S3. (E.g. "key: xxx, "alc": ...)
The case is that if I change the extension of "file.pdf" to "file.png" and then uploads it, the data sent to the server before uploads to S3 are:
"file.png"
"image/png"
The servers says "ok" and return the S3 fields for upload .
But the content type sent is not a real content type. But how I can validate this on the server?
Thanks!
Example:
Testing Redactorjs server side code (https://github.com/dybskiy/redactor-js/blob/master/demo/scripts/image_upload.php) it checks the file content type. But trying upload fake image (test here: http://imperavi.com/redactor/), it not allows the fake image. Like I want!
But how it's possible? Look at the request params: (It sends as image/jpeg, that should be valid)
When I was dealing with this question at work I found a solution using Mechanize.
Say you have an image url, url = "http://my.image.com"
Then you can use img = Mechanize.new.get(url)[:body]
The way to test whether img is really an image is by issuing the following test:
img.is_a?(Mechanize::Image)
If the image is not legitimate, this will return false.
There may be a way to load the image from file instead of URL, I am not sure, but I recommend looking at the mechanize docs to check.
With older browsers there's nothing you can do, since there is no way for you to access the file contents or any metadata beyond its name.
With the HTML5 file api you can do better. For example,
document.getElementById("uploadInput").files[0].type
Returns the mime type of the first file. I don't believe that the method used to perform this identification is mandated by the standard.
If this is insufficient then you could read the file locally with the FileReader apis and do whatever tests you require. This could be as simple as checking for the magic bytes present at the start of various file formats to fully validating that the file conforms to the relevant specification. MDN has a great article that shows how to use various bits of these apis.
Ultimately none of this would stop a malicious attempt.
So I have an attachment on my incoming Pop3 message,
Msg.MessageParts.Items[msgpart] as TidAttachmentFile
but, is it possible to get the content of this attached file in the format specified by Msg.MessageParts.Items[msgpart].ContentTransfer (so base64 ascii) instead of creating a temp file, calling SaveToFile, and then re-reading the file and re-connverting back to base64?
If TIdMessage.NoDecode is set to False, then no, it is not possible. When NoDecode is False, TIdMessageClient decodes the email as it is being read off the socket and places decoded binary data into attachment objects. The only way to get the original base64 data is to set TIdMessage.NoDecode to True and parse the raw email data manually (it is stored as-is in the TIdMessage.Body) as you would effectively be disabling TIdMessageClient's entire decoding system.
On the other hand, if you just want to avoid the temp file, you can use the TIdMessage.OnCreateAttachment event to have Indy create TIdAttachmentMemory objects instead of the default TIdAttachmentFile objects. The base64 will still be auto-decoded and stored as binary in the attachment, but at least the attachment would be solely in memory so your re-encode would be faster.