2,506 reputation
323
bio website crypto.stackexchange.com/…
location United States
age
visits member for 2 years, 4 months
seen Oct 23 at 21:47


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
revised How do I cryptanalyze a password field?
Rewrote the question to make it acceptable.
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
7
answered Is encrypting credit card numbers one by one with rsautl secure?
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
answered Is it true, that non-military cryptography appeared in 50's and 60's only thanks to leaks from the NSA?
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
Nov
4
comment Appropriate AES key length for short term protection
Here, try thinking of it this way: separate the key exchange from message encryption. If A and B need to talk, they exchange a temporary AES session key called AB, and persist it. When they have a second message, they reuse AB. Similarly, B and C exchange a key called BC, and A and C create AC. If A, B, & C all need to talk, they all exchange an AES key called ABC. Now, when future messages in your voting protocol happen, you only trot out AB, BC, AC, or ABC as needed. When the session is done, you delete AB, BC, AC, and ABC. Reuse keys in session, regenerate them for the next session.
Nov
4
comment Appropriate AES key length for short term protection
I'm afraid I don't understand the problem with AES being symmetric as you've already stated a willingness to use it. Unfortunately the scenario sheds no light on the discussion. It might help to wrap it in notation indicating messages, encryptions, and keys.
Nov
4
comment Appropriate AES key length for short term protection
That RSA encryption is very large in comparison to AES - on the order of thousands to millions of times less efficient. By comparison, it's extremely slow and expensive. (If you're going that route, why not forgo AES entirely and encrypt your messages directly with RSA?) With respect to your second comment, any peer can simply use the AES key exchanged at the start of a session to decrypt the message - no extra RSA required.
Nov
4
answered Appropriate AES key length for short term protection
Nov
1
answered Password as it relates to various encryption schemes
Oct
28
answered What is the limit of plaintext required to break the Vigenère encryption?
Oct
27
revised What's the difference between the long term key and the session keys?
deleted 109 characters in body
Oct
27
answered What's the difference between the long term key and the session keys?
Oct
27
answered Are there attacks that break collision resistance but not preimage resistance?