I am working on my project which is minutiae based fingerprint matching in database. We all know that every fingerprint in this world is unique and has unique set of features(Minutiae Points). SO is there any way that i could generate a hashkey for a fingerprint image, beacuse searching through hashkey is efficient and i dont have to match in whole database, just match similar hashkeys for fingerprint matching. I am able to extract features from fingerprint image. Please let me know if there is any technique.
The only method to match fingerprint is to compare fingerprint minutiae:
https://en.wikipedia.org/wiki/Fingerprint_recognition
If you need fast match on server against a lot of fingerprints, there's software solutions: AFIS.
Here some providers of AFIS solution:
http://www.neurotechnology.com/megamatcher.html
http://au.nec.com/en_AU/solutions/security-and-public-safety/biometrics/afis-fingerprint-identification-features.html
http://www.innovatrics.com/products
http://www.dermalog.com/en/products_solutions/afis/
http://www.m2sys.com/automated-fingerprint-identification-system-afis/
Related
I am building something like image hosting. Image is identified by user ID/image ID pair. Both are 20 chars long.
I would like to use this pair as a shareable image URL but I do not want it to be too obvious such as two images from a same user to have a same suffix or prefix.
Basically, I am doing something similar to JWT but the encrypted string length is a real concern.
Is there some good algorithm for this?
I want to generate a hash value-from fingerprint. I have seen a paper that used the freeman chain code algorithm to generate the hash value. I have searched so many research papers. But I don't find any proper solution. I want to use the hash value from the fingerprint in my research
I'm trying to blast an 8-mer (string of length 8) against the NCBI database. However, whenever I use qblast, it comes up empty with respect to matches. This is my code:
from Bio.Blast.NCBIWWW import qblast
import Bio.Blast.NCBIXML as parser
a = qblast('blastp','nr','GGMPSGCS')
b = parser.read(a)
print b.alignments`
Whenever I do this, it just prints the empty list []. Why is this happening? Can anyone shine a light on it?
I can get a match using the NCBI online BLAST tool, and I can even get a match if I use a longer kmer like "SSRVQDGMGLYTARRVR". It just happens that all the 8-mers I search come up empty.
From the FAQ at http://biopython.org/DIST/docs/tutorial/Tutorial.html
Why doesn’t Bio.Blast.NCBIWWW.qblast() give the same results as the NCBI BLAST website?
You need to specify the same options – the NCBI often adjust the default settings on the >website, and they do not match the QBLAST defaults anymore. Check things like the gap >penalties and expectation threshold.
Check that qblast is using the same defaults, if not sure, make them explicit. I wouldn't be surprised if it's doing some sort of "read to short" filtering step.
As in this answer, you have to fine-tuning the qblast to override the defaults. The WWW frontend of NCBI-BLAST automatically adjusts your parameters to match the short (8 bp) sequences, but if you do it through Biopython API you have to do it manually.
I'm looking for a RAIL way to create a very secure UID that will act as a authentication token.
I had been using UUID but was told they are not secure. I'd like to learn, what is the method of choice these days in ruby/rails 3?
This question is in no way Rails specific.
UUID is not secure for the simple fact that it is a unique identifier and it contains 'constant' parts of a given machine (e.g. it might use the MAC address for a machine), which makes it easier to guess.
If you want 100k+ strings without someone guessing one, you need to be able to distribute your keys across a large key-space. Let me explain:
If you only need 1 key (let's), you might pick 'A'. In a key-space of A-Z you have 1:26 chance of guessing it. Now, if you'd extend your key-space to A-Za-z you have a 1:52 chance of guessing.
Need more security still? Use a longer key: 'AA' 1:2704 chance.
Now, if you'd want to have 2000 keys and use a key length of 2 (e.g. 'AA'), there's a 2000:2704 => 1:1.352 chance someone might guess it. Pretty bad.
So, the key here is to pick a very long key size. With Digest::SHA1 you get 40-character keys (using Hex, with 16 different values per character). That's 1.46150164e48 unique values. Your 100k values should be random enough.
Edit:
With 40-digit HEX SHA1 values you have a 1:461501640000000000000000000000000000000000000000000 chance of guessing one. That takes ages.
I have a user model on my app, and my password field uses sha1. What i want is to, when i get the sha1 from the DB, to make it a string again. How do i do that?
You can't - SHA1 is a one-way hash. Given the output of SHA1(X), is not possible to retrieve X (at least, not without a brute force search or dictionary/rainbow table scan)
A very simple way of thinking about this is to imagine I give you a set of three-digit numbers to add up, and you tell me the final two digits of that sum. It's not possible from those two digits for me to work out exactly which numbers you started out with.
See also
Is it possible to reverse a sha1?
Decode sha1 string to normal string
Thought relating MD5, these other questions may also enlighten you:
Reversing an MD5 Hash
How can it be impossible to “decrypt” an MD5 hash?
You can't -- that's the point of SHA1, MDB5, etc. Most of those are one-way hashes for security. If it could be reversed, then anyone who gained access to your database could get all of the passwords. That would be bad.
Instead of dehashing your database, instead hash the password attempt and compare that to the hashed value in the database.
If you're talking about this from a practical viewpoint, just give up now and consider it impossible. Finding the original string is impossible (except by accident). Most of the point of a cryptographically secure hash is to ensure you can't find any other string that produces the same hash either.
If you're interested in research into secure hash algorithms: finding a string that will produce a given hash is called a "preimage". If you can manage to do so (with reasonable computational complexity) for SHA-1 you'll probably become reasonably famous among cryptanalysis researchers. The best "break" against SHA-1 that's currently known is a way to find two input strings that produce the same hash, but 1) it's computationally quite expensive (think in terms of a number of machines running 24/7 for months at a time to find one such pair), and does not work for an arbitrary hash value -- it finds one of a special class of input strings for which a matching pair is (relatively) easy to find.
SHA is a hashing algorithm. You can compare the hash of a user-supplied input with the stored hash, but you can't easily reverse the process (rebuild the original string from the stored hash).
Unless you choose to brute-force or use rainbow tables (both extremely slow when provided with a sufficiently long input).
You can't do that with SHA-1. But, given what you need to do, you can try using AES instead. AES allows encryption and decryption.