2,496 reputation
323
bio website crypto.stackexchange.com/…
location United States
age
visits member for 2 years, 2 months
seen 2 days ago


Oct
19
comment I need to know number of encryption/decryption operations?
2^224 is the brute force answer, but as @Nova posted, certain attacks are possible in certain situations. Those attacks reduce the amount of work needed to recover the key. Meet in the middle attacks take advantage of the small key size used by the primitives. But they require massive amounts of space. An attack requiring 2^112x64 bits of space will need 4.1E22 1TB hard drives to execute. As that's not exactly practical today, attackers still need to trade space for rounds of execution.
Oct
17
comment How do you test randomness?
See @e-sushi 's answer in the duplicate question for several good tests.
Jul
24
comment Vigenère cipher: Security when key length and plaintext length are the same
@owlstead, no, it has to be cryptographically unpredictable. If it's "random to the attacker", just because the attacker can't predict the sequence today doesn't mean he can't discover how to predict it tomorrow.
May
14
comment Special random distribution algorithm
At a brief glance, your problem looks similar to shared secrets. Have you looked at Shamir's Secret Sharing algorithm?
Feb
28
comment Frequency of letters change by the length of the texts?
You can generate your own frequency tables based on samples of related text. If you're decrypting data that came from Alex Corporation, build your sample from their public documents. If you're decoding a Shakespearean code, build your sample from the Bard's plays.
Feb
23
comment Timing Attack on RSA
You can try an attack, but it's certainly not guaranteed to be successful. There are many possible types of attacks. You also don't have to let him repeatedly attack you, you can simply record which servers your system attempts to send the key requests to. Note that this is not a comment on the legality of attacking someone's server - even a criminal's server.
Feb
22
comment Calculating amount of time for brute forcing ciphertext depending on the size of the key
For a fairly handy reference that yields data close to what you need, see keylength.com . It attempts to quantify security in terms of comparisons of key lengths and algorithms.
Dec
13
comment Testing a steganalysis technique on realistic data
This isn't a cryptography question. Perhaps security.stackexchange.com?
Dec
12
comment Certificateless cryptography
@Ravi, if you are simply talking about a two user system, it's possible for the two users to meet and simply exchange public keys; or they could even exchange a secret key and skip all the public key work. In this case, the two parties establish and validate their identities independent of the cryptography; from there, continued possession of the other's key serves as your authentication. In general, public key cryptography looks for ways to avoid establishing individual trust connections, in order to minimize cost or maximize flexibility. But that means all parties must trust a third party.
Dec
12
comment Do test vectors ensure a cipher is free of backdoors?
@TruthSerum, GOST doesn't specify the contents of the S-Boxes, so each implementation can choose their own set. I don't know if it's true that the Soviets deliberately assigned weak S-boxes as pg1989 claimed, but it is known that certain choices for S-boxes can result in a very weak cipher. See en.wikipedia.org/wiki/GOST
Nov
17
comment Can you break a multi language code using Frequency analysis?
Averaging the letter frequencies of each combination of three languages should also yield a series of unique profiles. But to actually make use of them will require a large amount of ciphertext written in the same manner as sources from which the frequency tables were generated. It's not impossible, it will just take 364 times more ciphertext than a single language (number of combinations of 3 of 14 languages).
Nov
12
comment Is there a cryptographic hash function that can be performed with pencil and paper?
You could trust yourself to keep your algorithm secret, so it could safely serve as your "key". But defending it against a couple of colluding web site admins would be harder. Do you consider that a realistic threat model? You could also modify it so you use a different algorithm for high value web site passwords, like banks.
Nov
12
comment How do I cryptanalyze a password field?
I took the liberty of rewriting the question into a more acceptable form, and voted to reopen. @mikeazo would you agree?
Nov
12
comment How do I cryptanalyze a password field?
As mike suggested, try decoding with various schemes. The appearance of the characters makes me think it might be base64, so glue an == to the end and try decoding it with a tool. Is there anything in the resulting bytes that lead you to a conclusion? Is it the same number of bytes as the password itself? Does it XOR with other passwords to yield a common stream you can factor out?
Nov
12
comment Is encrypting credit card numbers one by one with rsautl secure?
You're welcome. PCI DSS is a confusing, giant burden, and I know that finding out how to navigate it can take a lot of effort. Good luck!
Nov
11
comment Is encrypting credit card numbers one by one with rsautl secure?
The phrase "We intend to change the key" implies imprecision. You really should be creating a full key management lifecycle policy to comply with PCI 3.5 and 3.6, something that specifies how you will generate, distribute, store, use, retire, and destroy the keys, how long each of those states last, plans if they're compromised, etc. See pcisecuritystandards.org/documents/pci_dss_v2.pdf for the requirement, and csrc.nist.gov for advice. nvlpubs.nist.gov/nistpubs/SpecialPublications/… deals directly with creating a key management strategy.
Nov
9
comment What does this Authentication protocol achieve and what information is shared?
In step 3, how does S know Kab?
Nov
6
comment Splitting a password for dual roles
disk eater, try separating the concept of "password" from "key". The password is what the human remembers, the key is what the algorithm needs. Algorithms like PBKDF2 translate a password into a pile of key material. So instead of splitting the password, you divide the key material. Knowing half the pile reveals nothing about the other half. Of course, guessing the password now has two independent systems that can test your guesses, and if you guess right, you can generate both keys, but that's a risk inherent to your requirements - not to the technology.
Nov
5
comment Appropriate AES key length for short term protection
Nice! Glad to be of assistance.
Nov
5
comment Appropriate AES key length for short term protection
let us continue this discussion in chat