2,331 reputation
220
bio website crypto.stackexchange.com/…
location United States
age
visits member for 1 year, 8 months
seen Apr 11 at 21:24


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?
Oct
23
comment Logics for Cryptographic Information Games
Are you looking for an existing model, or are you trying/planning to create your own? Either way, I would be interested in whatever you find.
Oct
17
answered Encryption of small messages
Oct
17
comment PGP encryption options
My comment was simply that you need to trust everyone you permit to access your service, or they can grant the access that might allow someone else to enter. Even so, many services still have unknown vulnerabilities that might permit attack.
Oct
16
comment PGP encryption options
Regarding email services, you could always host your own communication channel, whether it be an email server, IRC server, or whatever. But that turns into a trust issue with everyone you allow to connect to it or through it - plus, you may or may not know if you can trust the software. What exactly are you looking to protect against?