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 taking a crypto course, and we're going over substitution ciphers and their Key space.
per the instructor, the key space is 26! (approx 2^88) for the English alphabet. there is no reference to key length, probably because a subst cipher's length would be a function of the length of the alphabet, just as the number of options would.
per wikipedia the keyspace is the set of all possible keys of a certian length, and is calculated in the same way brute force try counts would be options^length or in this case 26^26.
so what am I not getting here?
That's a bit misleading, both your instructor and Wikipedia are correct.
Generally, key of 26 english letters defines a key space sized 2626.
For substitution ciphers over english alphabet 26! is the correct number representing the key space. That's because for substitution cipher the key is defined as a unique replacement of each letter with another one, e.g. A -> D, B -> M, C -> Y, etc. 26 letters --> key can be any permutation of 26-letter set --> 26!. Due to the uniqueness required for substitution, the key space is effectively smaller than the maximal 2626, because some (most) of the keys aren't possible - e.g., you can't map both A and B to D.
If your key is a set of digits, options^length is correct. Every digit may occur several times.
If your key is an alphabet, Factorial N is correct. Say, you want to place the A first. You have 26 options. After that, you have only 25 options for the B because A already occupies one. 24 For the C and so on.
26*25*24*...*1 = 26!
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
i need to find factors of very big number say (10^1000) . i.e if input is 100 then output should be 10 10 because (10*10=100) .this is very simple if N<=size of (long) but i want to know how it will be possible to find factors of very big number say (10^1000). also i cant use Big Integer .
.
1) As has been pointed out, factoring large numbers is hard. It is in fact sufficiently hard that it's the basis for RSA public key cryptography, or in other words every time you buy something online, you are counting on the fact that it's hard to factor numbers of the order 2^2048 (given 2^10 = 1024 which is about 10^3, 2^2048 is about 10^600). While RSA specifically uses two large prime numbers and your random N may have lots of small numbers which will help somewhat, I wouldn't count on being able to factor 10^1000 +/- some random value anytime soon.
2) You can definitely reimplement big number library using strings [source: I had a classmate who did it before we learned about how to do big number math] but it's going to be painfully slow, and you basically have to cast your strings back to ints each time; a slightly less painful approach if you wanted to reimplmeent big numbers is arrays of integers. You still need to do some extra steps, but for doing at least basic math, it's not super difficult. (But it still won't be as efficient as specialized big number libraries, which can do clever algorithms. For example, multiplying 2 big numbers the straight forward way would be let A = P * 2^32 + Q (i.e. A is a 64 bit number represented as an array of 2 32 bit numbers) and B = R * 2^32 + S... the straightforward way takes 4 multiplactions plus some additions plus some dealing with carries). As the size of the big number increases, there are ways (see e.g. http://en.wikipedia.org/wiki/Karatsuba_algorithm) to reduce the number of multipication required)
3) (There are algorithms to more efficiently factor numbers compared to trial factorization, but the current ones are still not going to help compute the numbers you're asking about before the heat death of the universe)
10^1000 has exactly 1,002,001 integer divisors, and they should be very easy to find with a bit of thinking. The prime factorisation is
2 * 2 * 2 * ... * 5 * 5 * 5
with exactly 1,000 twos and exactly 1,000 fives.
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 8 years ago.
Improve this question
I need to create a column in SQL Server database. Entries for that column will contain messages from chat. Previously such messages has been stored as comments.
My main quetion is:
What is typical text length for chat message and comment?
By the way:
What would happen if I used varchar(max)? How would it impact database size and performance? Is better to use powers of 2 or powers of 10 (e.g. 128 instead of 100) while considering text lengths?
Using VARCHAR(MAX) has a disadvantage: you can not define an index over this column.
Generally, your application should impose a maximum length for a chat message. How big that limit is depends very much on what the application is used for. But anything more than 1000 byte is probably less a legitimate message but an attempt to disrupt your service.
If your maximum value is a power of 2, or a power of ten or any other value has no influence on the performance as long as the row fits in one (8KB) page.
Short answer - it doesn't matter.
From MSDN:
The storage size is the actual length of the data entered + 2 bytes.
So VARCHAR(10) and VARCHAR(10000) will consume the same amount of data if the values don't exceed 10 characters.
Definitely use N/VARCHAR(MAX), it can grow to be 2GB (if I remember correctly). It will grow as required though, so it is very efficient with regards to space unless you are only storing very small amounts of data.
I'm struggling to get my head around the Vigenere Cipher when you know the length of the key but not what it is. I can decipher text if I know the key but I'm confused as to how to work out what the key actually is.
For one example I'm given cipher text and a key length of 6. That's all I'm given, I'm told the key is an arbitrary set of letters that don't necessarily have to make up a word in the english language, in other words, a random set of letters.
With this knowledge I've only so far broken up the cipher text into 6 subtexts, each containing the letters encrypted by the key letters so the first subtext contains every 6th letter starting with the first. The second every 6th letter starting with the second letter and so on.
What do I do now?
You calculate a letter frequency table for each letter of the key. If, as in your example, the key length is 6, you get 6 frequency tables. You should get similar frequencies, although not for the same letters. If you do not, the you have the wrong key length.
Now you check letter frequency tables for English (for example, see http://en.wikipedia.org/wiki/Letter_frequency). If the pattern does not match, the clear text was not in English. If it does, assign the most frequent letters in each subtext to the most frequent letters in the frequency table etc. and see what you get. You should note that your text may have slightly different frequencies, the reference tables are statistics based on a large amount of data. Now you need to use you head.
Using common digrams (such as th and sh in English) can help.
One approach is frequency analysis. Take each of the six groups and build a frequency table for each character. Then compare that table to a table of known frequencies for the plaintext (if it's standard text, this would just be the English language).
A second, possibly simpler, approach is to just brute-force each character. The number of possible keys is 26^6 ~= 300,000,000, which is about 29 bits of key space. This is brute-forceable but would probably take a bit of time on a personal computer. But if you brute-force one character at a time would only take 26*6 = 156 tries. To do so, write a function that "scores" an attempted decrypted plaintext with how "plaintext-like" it looks. You might do frequency analysis like above, but there can be simpler tests. Then brute-force each of the six sets of characters and pick the key letter that scores the best for decrypting each one of them.
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
Since breaking password hashes has become a new passtime for scriptkiddies, I thought of the problem and came up with a novel(?) idea.
store the pass as offset+number instead of hash
the number is a product of two large primes
the password is converted into a number , offset is added and that prime is used to divide the number. If it divides AND the divisor is the larger of the two primes the password is correct.
by definition , each hash is unique and each password can be hashed in many different ways depending on the offset. Breaking one hash means you have to factor the number(which is hard), then find a word which corresponds to a number that is largerprime-offset (which is trivial).
To generate use function f() to turn password into a password-number (not important) , generate two random primes larger than 2^4096 or however much is enough. Take the larger prime and calculate prime-passwordnumber=offset. Multiply the primes to get "number". store number and offset.
To check. use function f() to turn password into a password-number, add offset to find prime. divide number with prime to get the other prime. Check that the first prime was the bigger of the two. If so, password was correct.
f() might be for example utf-8 encoding of the password understood as a large binary integer.
Your procedure doesn't really gain you anything over using a hash function. Reversing your function is difficult, yes, since it requires factoring large numbers, but reversing regular hash functions is also difficult. An attacker can still employ the same procedure they would against a regular hash algorithm: employ a brute force attack by testing every possible password.
This, of course, is inevitable with any scheme that stores sufficient data to validate the password. The only solution is to make it computationally expensive for the attacker to do so, by making the hash function expensive to compute, and by adding a salt to make sure they can't precompute.
In general, trying to invent your own crypto system is very hard to do correctly. There are many little things that you have to consider, and it's easy to miss something that an attack can exploit. You'd still be much better off and safer if you used an established cryptography or hashing library. Bcrypt for hashing will probably be much more secure than the solution you posted.
To formalize your scheme:
To create the hash:
User enters password pw
Convert pw to a byte array ba with an encoding function e
Convert ba to a large integer bn
Find prime numbers p and q, p > q > max(bn, 2^2048)
Store n = pq and o = p - bn
To verify the hash:
User enters password pw
Convert pw to a byte array ba with an encoding function e
Convert ba to a large integer bn
Verify that bn + o divides n
This being a secure hash requires that given n and o, it's not feasible to deduce pw, i.e. there is no algorithm that gives an advantage over guessing and checking. I believe it.
As I see it, the main benefit of your scheme is the randomness injected into the hashing process by selecting the random numbers. That they are primes and factoring should be hard is more of an implementation detail (it's your one-way function). Presumably it should also slow down checks, though I really don't know how slow division is on numbers that large.
It is interesting that the hash creation and password verification processes are so different. As you point out, this makes the technique of rainbow table hash chaining inapplicable. This may be something of an advantage, but per-user salting gets you similar protection from rainbow tables.
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 11 years ago.
Improve this question
I'm not a fan of complex passwords as I have a hard time remembering them. Because of that I like the message of this comic.
However typing the sentence "correct horse battery staple" into this calculator yields "12.41 trillion trillion trillion centuries" as opposed to the comic's "550 years".
How can they differ so much, which one is correct if any and how would I know?
How do I create a strong enough password without making it difficult to remember?
The reason for this difference is basically given on the linked side itself:
IMPORTANT!!! What this calculator is NOT . . .
It is NOT a “Password Strength Meter.”
Since it could be easily confused for one, it is very important for you to understand what it is, and what it isn't:
The #1 most commonly used password is “123456”, and the 4th most common is “Password.” So any password attacker and cracker would try those two passwords immediately. Yet the Search Space Calculator above shows the time to search for those two passwords online (assuming a very fast online rate of 1,000 guesses per second) as 18.52 minutes and 17.33 centuries respectively! If “123456” is the first password that's guessed, that wouldn't take 18.52 minutes. And no password cracker would wait 17.33 centuries before checking to see whether “Password” is the magic phrase.
The caclulator basically only considers brute force attempts, while an actual attack would probably be a dictionary arrack. Since most combinations of letters are not actual words a dictionary attack will try a lot less combinations, thous getting a result much faster
IMPORTANT!!! What this calculator is NOT . . .
It is NOT a “Password Strength Meter.”
The calculator assumes that cracker uses exhaustive search. xkcd assumes that cracker may know (or guess) your method of generating password and needs to check only the passwords which you can choose. xkcd method is far safer.
Not any strong password is 100% safe, few websites can really protect user's password. You'd better not to use only one password everywhere. What you do is to keep the straw on fire away from others.
What I do is:
a unforgettable password: A;
the website asking for a password, "www.example.com", as B;
get C = md5(A) + md5(B), and use the leading 8 characters of C as the password;
write a simple script for this, and of course, you may adjust the algorithm, and do keep the script on cloud.
the browser will save password for us, if it asks you for re-enter the password, you can get it back at once.
The operator '+' is not as strcat. It means:
I get the md5 in low letters, and saying that the '0' values 0, ..., 'a' values 10, ..., 'A' is 36, ..., and as so on.Then calculate the result at every character with their values, discarding the carry, and do "mod(62)".