This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
I have the following encrypted strings with plain-text equivalents:
01b6e203 = to
8d777f38 = data
b068931c = name
c34487c9 = subject
0c83f57c = email
865c0c0b = i
any idea what kind of alogorithm/encryption/obfuscation can produce them? I don't have any idea, checked an hour on google, thought about crc32 but is not...the only find on google about encrypted string "8d777f38" is Grid Account Username: **data**. Grid Account Identifier: **8d777f38**-5d3d-3ec8-815d-20f7496026dc
Thank you!
As the codes are all the same length, and the length seem too short to hold the data in the longer strings, it seems to be a hash code rather than encryption.
It could for example be the first for bytes of an MD5 hash, or it could be a CRC32 hash. You would simply have to get the hash code for the texts using the most common hashing algorithms, and see if you can find the codes in the result.
Note, that there is not just one CRC-32 code but a lot of usable generator polynomials exist, where one with very few coefficients is widely used for performance reasons.
It could also be a MAC (message authentication code, a sort of cipher block chaining encryption suppressing intermediate result blocks), where a four byte variant was sometimes used in environments, where every byte mattered, as in smart cards. Since a MAC involves a secret key:
only authorized parties knowing the key are able to verify it
brute force is still some hoework
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have researched on each element or system that I am willing to implement into a generic software licensing system for my soon-to-be apps (irrelevant, as this should work, or be usable on all of my applications).
I have created a DLL with my licensing class in it.
It is as follows:
(1)
I have applied the InternalsVisibleTo() attribute main class (with child classes), which makes all of the internal classes, and their methods, which are declared Friend, visible to external assemblies with the sepcified PublicKey.
I have made the reference to the app name, and it's PublicKey. (Both the licensing, and the external assembly, are signed with the same key (.snk file)
(2)
All (where possible) members, properties etc. are delcared Friend or Private or just Dim...ed .
(3)
My licensing class has a String variable; declared:
Private Shared _Key As String = "H58N2-00V93"
This variable is the special password, if you will, of my DLL, and is required to access the methods in my DLL.
There is also a Public String variable (let's call it "AccessKey"), which should be initialized with the main class, like so:
Dim licDLL As New LicensingAssemblyName.LicensingMainClass With {.AccessKey="H58N2-00V93"}
(4)
Then, I have a Function (let's call it "CheckKey"), which checks whether the Public, initialized variable ("AccessKey" is equal to the pre-defined, Friend key ("_Key"), whereupon an exception will be thrown, if they are not equal - preventing method from continued/used.
(5)
At each first line of every Sub, Function etc., I have inserted a call to this function.
These are just the 'security' measures I've taken to prevent external assemblies from using my DLL in another app, to perhaps exploit the system or generate keys.
Now for the licensing measures.
(1)
I have a key generator (very basic), which generates codes upon a given format (Like: "#-$" for a number, a dash, followed by a letter.)
I have included an encryption class in this program, which uses Rijndaenal, and applies salt.
I have set the key generator to encrypt each separate key upon generation, then append it to a new line of a file, which we'll call "my_licenses.txt".
I use the same password for each one (obviously). It is quite long, and includes many different characters (if that makes ANY difference). I considered this to be a secure way since I didn't think ANYONE could decrypt a string without the password, until I was told by another programmer, who advised against using plain text encryption as a method to secure these keys. Please help me with this.
(2)
In my licensing DLL, I have a declaration:
Friend Shared Function IsKeyValid(ByVal KeyDB As String, ByVal Key As String) As Boolean
This function decrypts each key in the file (the specified database, using the same pass code used when encrypting them in the key generation program).
Then I do a For Each, Next loop to, determining whether the specified "Key" value equals any in the key 'database', "my_licenses.txt". But here's the catch.
I have an Function which returns a unique code for the computer it's running on (using hardware IDs etc.). This Function helps me protect against the use of the same key on multiple computers (unless I implement a system for allowing this, limited times) and is required as the last 5 characters of the "Key".
After checking, this Function returns a value of the result (True or False).
Finally (phew), each assembly (the licensing one, and any external ones which utilize it) are obfuscated -and likewise signed (all assemblies, with the same key (.snk) file)- by CodePlex's Confuser (A free, and highly recommended obfuscator for .NET).
I hope this hasn't been too long/not detailed enough/difficult to understand. (If so, tell me what you don't understand).
This is my first post/question of any kind, so be nice. Also thank you for reading.
I hope you can help.
And just to confirm, my question is this: Would this system be secure enough to protect against the average hacker?
P.S. I am only a beginner, so answers for a beginner would be especially appreciated ;)
*UPDATE: I have actually reduced the length of this question, and improved its understandability (believe it or not). So this is the best I can do.
That's an insane wall of text so you kind of lost me. And, to be honest I stopped reading seriously when I saw you had a hardcoded key inside the binary that you plan to distribute... But there are two questions you ought to ask yourself:
Is your application likely to be so successful that there is sufficient demand for it so that people with the appropriate skillset will be inclined to reverse it and release a keygen and/or pirated version?
And wouldn't your time be better spent adding cool features to the application instead of licensing code which does nothing to improve the application itself?
Don't get me wrong. I'm all for people getting paid for their work and I don't object to people licensing their software; as a matter of fact, one of the projects I worked on was a custom licensing engine which was tracking a little over 100,000 licenses last I checked. But make sure that if you decide to implement licensing that the effort you put into it doesn't exceed the effort you put into the actual software you're licensing.
With all that said, here's what I would do:
Generate a lot of licensing keys (using whatever format you want)
Hash those keys using something like SHA-256 or SHA-512.
Create an array (using whatever syntax is appropriate to your language of choice) that contains the key hashes.
Include the array inside your application.
With that setup, to verify a license, all you need to do is:
Hash the input using the same algorithm as before.
Iterate the array, comparing it with the result of the hash. If they match, the key is licensed. If they don't, continue.
If you get to the end of the table the key is not licensed.
Do not immediately exit the application if the key isn't licensed. Instead set a flag that prevents the use of important commands (e.g. "Save") or set a timer for 60 seconds plus a random number of to exit the application.
Compile and then digitally sign your application with Authenticode. Have the application itself validate the signature to try and discourage casual tampering.
If you are so inclined, you could even encrypt the hashes, although that is unlikely to help against the sort of attack that someone would mount against this scheme.
To be clear: this is not bulletproof (then again, no licensing mechanism is) and it's possible for someone sufficiently skilled to break it in a number of ways. But it's almost certainly going to be more than good enough for your project.
Security doesn't have an absolute value, it has to be measured against the payoff. If your app is holding some nuclear codes I'd say go pay a specialized consultant for this. If you're storing grandma's secret recipes - you're good to go.
I read the whole post and it's still not clear what's the purpose of the hard-coded key or how do you manage the individual encryption keys for each license: encryption is not just about how strong an algorithm you use or how long your password is; it's also about how do you hide your passwords, how do you transmit them, what do you do in edge cases (interrupted connection, failed decryption etc) and many other things.
From the looks of it I'd say you're in the "good to go" category only because your app doesn't sound like a high-profile target to crack and you mostly want to deter the casual cracking attempt from a frustrated developer who doesn't like your licensing scheme (: and the obfuscation alone would deter most when it comes to reverse-engineering your code. I'm not familiar with your code to tell if there's any other, easier ways to bypass licensing, such as the popular method of copying the licensing file itself if it's not tied to the machine or user profile...
There are many workarounds online, but only hashing system described here or something based on public key cryptography can be secure enough to serve licensing.
I personally prefer and use commercial product: http://www.treekslicensinglibrary.com - Treek's Licensing Library. It's cheap, easy to setup and really secure as it uses previously meant public key cryptography to work with license.
Edit: To compare with hashes of serial numbers - this solution does not require to predefine accepted serial numbers. 1000 hashes in apps = 1000 licenses, for more you need to update your app. Public key cryptography based license systems do not have this disadvantage.
You can use a .NET Obfuscate application to secure it. All .NET application may decompile with .NET Reflector, so search in your browser the application to obfuscate .net application. This will work as i know, everyone that want to decompile your application will prevent by the obfuscate
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm trying to get an understanding of the world of cryptography as its practically used day to day. I'm finding it very hard to get a start footing, And I was wondering if anyone has some good resources that explain things assuming that I know nothing.
For example, I have (I believe, due to limited understanding) a file with X509 certificate and a "SignatureValue" attribute. I think these are encoded with SHA256. I would like to understand exactly what I'm looking at however, because I need to provide a "Timestamp Response File", which contains the DER representation of one Timestamp Authority Message.
Things I somewhat grasp so far:
SHA256 is a hashing algorithm. One way?
X509 is a document that defines how a certificate (whatever that is) should look
ASN.1 is a group of ways to transmit data between systems?
DER is a way of representing data in binary/octal bits.
I'd like a birds eye view of this ecosystem just so I have some concept of how this puzzle fits together, then I can delve better into the nitty gritty of How-Things-Work.
Reading whole bunch of books will take a lot of time.
Imho, the faster way would be to browse Wikipedia and read what is:
hash algorithm (in short, it transform long text/data to fixed-size value, hash, which (almost) unique represents this long text. And, yes, it is one-way.
signature algorithm - calculates something from hash value, which is called 'signature'. The main idea is that correct signature can be calculated only when you have secret key. And, this signature can be verified with public key. Public key is shared amongst people so they can verify your signatures.
So, valid signature proves that text/data was not changed by somebody else.
certificate: this is block of data, which binds user's public key to information about this key: name of the owner, email, address, whatever else. Certificate usually signed by authority (root certificate) - so, if you trust to authority, you should believe that this certificate correctly represents person.
timestamp: this is signature, made by some authority people trust to, which binds time mark to signature, made over other document. So, this will prove that this signature (and, this document) was correct at that time. This is needed since sometimes certificates can become revoked or outdated, and without timestamp you will not know if this is correct signature since you will not know when it was created.
ASN.1 - Abstract Syntax Notation, it defines text rules which describe format of some data structures. It is used in most of cryptography standards.
DER encoding (Distinguished Encoding Rules): set of rules how to encode ASN.1 objects/records to binary data. There is also BER (Basic Encoding Rules), which does almost the same, BUT it allows different encoding for the same value (like BOOL can be encoded by any non-zero value), which can not be used in cryptography since the same message can be encoded in different ways, producing different hashes.
X.509 : standard about format (ASN.1) of public-key certificates.
Hope this helps a bit to understand what's going on :)
Actually, there is a number of cryptography libraries on market, which implement all those timestamping/x.509/signing/verification,etc.
I'm sad everytime a developer has to do some "deeper" crypto stuff. I know that they are thinking that "he can write code, crypto is just a code that makes something secure, he can do it" and boy it's just wrong. Without solid or almost solid security backgroud crypto-hacking (writing own code) will fail.
I would suggest you to study it, pretty hard because if you do it right it will be ok, but if this fails and some vulnerability is introduced you will have not so nice chats. So I will suggest for starters:
Beginning-Cryptography-Java - even if you are not java person some first chapters
Handbook of applied cryptography
Applied cryptography
Security engineering
After those you would get pretty firm grass that crypto is something to be avoided, and only used with extreme caution and only when it does not introduces more problems that it solves.
And About your questions:
SHA25 - is a cryptographically secure one way hash function that produces 256bit output
X509 - describes format of digital certificates
DER and PEM are forms of certificate encodings
And my last request would be that you should not just stop on some high level "I think i got this" point of view and dig deeper and try to really understand what is and what isn't secure.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
I'm writing a quiz type app and I've seen some on itunes where you need to type out what the logo is, and it seems to check each letter the user types and gives a tick or a cross depending on whether you typed the name correctly.
For example, I've seen quiz app where you need to guess logos of famous brands, but instead of multiple choice you get its brand name blanked out by crosses and as you type it changes the cross to a tick (assuming you got it right).
My question is, how do you do letter-by-letter validation? I'm thinking that regular expressions might help but I've only ever used it to enforce string input t be text.
Other than that the only thing I can think of is to explode the string of the answer into an array and checking your input against it, but I think this sounds way too slow.
I guess you could cycle through each letter typed, but if there is an easier solution to do letter-by-letter validation for an iphone quiz app that'd be great.
Thanks
char inputLetter = ...
if([answer characterAtIndex:i] == inputLetter)
{
//Yay!
}
What is slow about that?
For a homework assignment, I am asked to determine the algorithm used to generate a given cipher text. The key is also given. Currently, I am working down a list of simple encryption algorithms and semi-blindly testing different decryption arrangements in an attempt at retrieving the given plain text.
Is there a better way to go about this process? I've read pages of Google results on the topic and haven't come across anything that explained a better process than what I'm already doing. Thus far I've run multiple levels of linguistical analysis upon the cipher text and am trying to plug in logical values into the encrypted message to decrypt it.
This is built around basic cryptographic systems, nothing at the level of public key encryption or DES.
Even if I can get the original message, how will that show the encryption scheme that was used?
My answer would be there is nothing wrong with trying various different algorithms out and seeing what works.
Cryptanalysis is like solving a puzzle, not a step by step process. You try things, you see what works, what you think gets you closer. It is absolutely trial and error based on knowledge of the potential algorithms, patterns and techniques and the reasons for them. Differential cryptanalysis, a modern technique, basically amounts to trying various combinations of keys and plaintexts within an algorithm and looking at the differences to see if you can find patterns.
From your comments, I think you're facing a vigenere cipher or some similar variant thereof. In this case, the key is important because essentially a vigenere cipher is a set of caesar ciphers and the length of the key determines the number of these ciphers. Now, the rules of the scheme in question will tell you exactly what cipher it is, but that's the basis of it.
This is a question about an authentication scheme.
Say I have a shared secret string S, and two computers, C1 and C2
Computer one (C1) sends a random string (R) to computer two (C2)
C2 hashes (say SHA256) the concatenation of S and R (SR)
C2 sends the hash of SR to C1, along with some instructions
C1 compares the received hash of SR with it's own hash of SR and executes the instructions if they match
Wash, rinse, repeat with different values of R
Now, what I want to know is if someone intercepts a whole bunch of R values, and a whole bunch of SR hashes, can they use that as a "crib" to work out what S is, thus allowing them to forge instructions?
I'm already aware of the potential for a MITM attack here (attacker intercepts response, changes the instructions and forwards it on).
I honestly don't know what I'm dealing with here, I only have a bit of historical knowledge about encryption but that included the use of cribs to break them. I'm not a theorist, so anything you can definitively tell me about specific strong hashes would be great.
Alternate authentication schemes are also welcome, assuming the constraints of an existing shared secret string like in this example. Would I be better off just using S as a key for AES? If I do that, can I still use this in the encrypted message to prevent replay attacks?
Any and all advice welcome, I sort of deviated from my question at the end, so feel free to deviate in your answers!
What you're talking about is called a message authentication code - a MAC. If the secret is sufficiently large (such that it cannot be brute forced in reasonable time) and the MAC is properly implemented, then no, knowing the plaintext doesn't help the attacker.
The key, however, is that it has to be properly implemented. The problem is that crypto is hard. Really hard. Unless you're an expert or have an expert to review your work in context, it's extremely easy to make a mistake. Even worse, it's very easy for people to write crypto that they don't know how to break, but which can be broken quite easily by someone in the know.
The advice you got in the comments is the correct advice: use a proven scheme like SSL or TLS instead of creating your own.
Answering your question:
No, the only way to break a hash is brute force, as small diferences in the origin mean big differences in the output of the hashing algorithm (given that the algorithm has been proben to be unbroken). You must to know S to perform a MITM here.
But, Byron Withlock is correct:
Using a homemade encryption scheme when there are sooo many better schemes available is crazy. Leave encryption to the experts. – Byron Whitlock 4 mins ago
I'm with Byron. Just use something off-the-shelf and tested by people with a clue. How about SSL? – Steven Sudit 57 secs ago
Many cryptographic hash functions are vulnerable to a lengt extension attack. That means if an attacker knows hash(S) but not S, then he may still be able to compute hash(S || M) for some messages M. For example, the attacker might try to get hash(S), by sending the challenge string "" to one of the parties. Your scheme does not have a detailed description. So it is not clear if such a length extension attack is possible. To avoid these kind of attacks you might consider to use for example HMAC instead of the more simple hashing scheme that you propose.
This scheme is weak because the instructions themselves aren't authenticated. You want to send the MAC of R + instructions - and ensure that R is fixed length so that an attacker can't shuffle about between R and instructions.
I take it the purpose of the random value is to ensure the "freshness" of the instructions sent?
You could also look into using gpg, if SSL doesn't meet your needs. That's likely to be a lot better than homegrown crypto.