Re: [cryptography] best practices for hostname validation when using JSSE
I added a comment on your Stack Overflow post (incorrectly closed, IMHO, but the SO crowd can be prickly). The right thing to do depends on knowing a couple more details: 1. Where are you getting your certificates? 2. What's the best way to name the servers you trust? Since you have a proprietary protocol, the easiest thing to do is make sure the cert chains up to a root you trust (ideally not system-installed roots, because nobody knows how deep the sewage flows there—the only exception would be if you want to delegate trust issues to a user of your software who might be expected to manage their own trustpoints using system configuration tools, but that gives me the willies). Then make sure the name on the cert matches the name of who you think you're communicating with (could be DNS name, or some other identification of the entity); if you may want to use SSL libraries which check certs and which are designed for HTTPS, you probably want to use the DNS name. I don't know enough about JSSE-specific implementation to be able to give you a precise answer. - Tim On Fri, Aug 9, 2013 at 3:03 PM, Patrick Pelletier c...@funwithsoftware.orgwrote: One thing mentioned in the Most Dangerous Code in the World paper (and I've verified experimentally) is that JSSE doesn't validate the hostname against the X.509 certificate, so if one uses JSSE naively, one is open to man-in-the-middle attacks. The best solution I've been able to figure out is to borrow the hostname validation code from Apache HttpComponents. But I'm curious what other people who use JSSE are doing, and if there's a best practice for doing this. Apologies if this isn't on-topic for this list; I know you guys mostly discuss higher-level issues, rather than APIs. I already tried asking on Stack Overflow, and they said it was off-topic for Stack Overflow: http://stackoverflow.com/questions/18139448/how-should-i-do-hostname-validation-when-using-jsse So, a meta-question would be: where is the right place to ask this question? I haven't been able to find a JSSE-specific mailing list. Thanks, --Patrick ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Can there be a cryptographic dead man switch?
On Sep 19, 2012, at 4:48 PM, mhey...@gmail.com mhey...@gmail.com wrote: Every three months I, the Grantor, encrypt my secret in a new secret-encrypting-key and place that secret in my box. (I keep my box away from others - maybe put it in a safe). I also encrypt that secret-encrypting key in a public key but not too strong a public key, one that can be broken in three months time. I then throw away the private key to that public key (I don't need it, I know my secret). I give the public-key encrypted secret-encrypting key to the trustee, heck I can publish it on the web if I want. If I should die, I will stop re-encrypting the secret and the trustee (that I never really trusted) can break the public key and get to the secret. This doesn't work or doesn't help. If the trustee doesn't have access to the safe until after you're dead, then the encryption is unimportant: just keep your secrets in the safe unencrypted. If they can access the encrypted message before your dead, they can decrypt it in a few months, even if you stay on the right side of the grass. Separately, I think it's impracticable to know the available computation time for key breaking, so it's difficult to estimate how long it will take the trustee to recover the message after gaining access to the encrypted message. I don't know of any way to solve the original problem other than changing the framing to allow somewhat trusted third parties (distribute secret shares to a dozen people, requiring 10 of them to agree to recover the decryption key, hope that they don't conspire to recover it until after you're dead), having access to a secure agent (software running somewhere that releases the secret if you don't check in for 30 days), or the ability to invalidate an old secret store (e.g., physically hide the secret somewhere, move it every 30 days, and encrypt the location with a 60-day weak key, but see the above challenge of predicting how long it will take to crack--a key long enough to be safe for 60 days against all attackers may take your trustee a couple of years to crack once you're dead). - Tim ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Why do scammers say they're from Nigeria?
This is an interesting paper that presumably has implications for other social engineering schemes beside financial scammers: http://research.microsoft.com/pubs/167719/WhyFromNigeria.pdf ABSTRACT False positives cause many promising detection technologies to be unworkable in practice. Attackers, we show, face this problem too. In deciding who to attack true positives are targets successfully attacked, while false positives are those that are attacked but yield nothing. This allows us to view the attacker’s problem as a binary classification. The most profitable strategy requires accurately distinguishing viable from non-viable users, and balancing the relative costs of true and false positives. We show that as victim density decreases the fraction of viable users than can be profitably attacked drops dramatically. For example, a 10× reduction in density can produce a 1000× reduction in the number of victims found. At very low victim densities the attacker faces a seemingly intractable Catch-22: unless he can distinguish viable from non-viable users with great accuracy the attacker cannot find enough victims to be profitable. However, only by finding large numbers of victims can he learn how to accurately distinguish the two. Finally, this approach suggests an answer to the question in the title. Far-fetched tales of West African riches strike most as comical. Our analysis suggests that is an advantage to the attacker, not a disadvantage. Since his attack has a low density of victims the Nigerian scammer has an over-riding need to reduce false positives. By sending an email that repels all but the most gullible the scammer gets the most promising marks to self-select, and tilts the true to false positive ratio in his favor. - Tim ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On Mon, Jun 18, 2012 at 2:51 PM, Matthew Green matthewdgr...@gmail.comwrote: I think that Jack said most of what I would. The incentives all point in the wrong direction. While this is all true, it's also why manufacturers who want persuasive analysis of their products hire consulting vendors with a brand and track record strong enough that the end consumer can plausibly believe that their reputational risk outweighs the manufacturer's desire for a good report. Cryptography Research is such a vendor. It's reasonable to take a manufacturer-funded report with a grain of salt, but when consuming any information, you also have to worry about issues like incompetence and less-visible incentives that tilt the comprehension or presentation of facts. I think taking this report as presumed correct is good enough for most users to rely upon, but if I was a high-value user with a comparable budget, I'd consider further investigation. - Tim ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Voynich Manuscript now online
An interesting item in the historical record, even if it's not actually a code (this is my understanding of the current best hypothesis): http://beinecke.library.yale.edu/digitallibrary/voynich.html - Tim ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] obfuscating symbols without increasing their size
On Wed, Jan 19, 2011 at 9:31 PM, travis+ml-rbcryptogra...@subspacefield.orgtravis%2bml-rbcryptogra...@subspacefield.org wrote: On Thu, Jan 20, 2011 at 12:49:26PM +1100, Noon Silk wrote: Sounds to me like the simplist solution is just a one-time pad[1]. It won't increase the size, and from the sounds of your environment, you can just keep the keys locally, and use them only when you do the debugging. But perhaps I'm misunderstanding your question. Yeah, I knew people would tend not to answer my question and simply provide solutions which won't work due to the context. But possibly someone will give me something I haven't thought of, so let me explain further. OTP won't work - simply XORing a printable character with a non-printable won't guarantee a printable, for example, and symbols have to be printable. It'd be much simpler to just map symbols to ordinal values, but that has the following problem: The releases may have different sets of symbols, in different orders. Furthermore, the symbols have to map to the same thing on subsequent releases so crashes can be correlated across releases. Finally, it's a burden for data to have to be propogated from the obfuscation run on one release to the next. They might be done by different groups who don't normally communicate, for example, or there could be release of different branches so no strict ordering in place (apart from temporal, and that's kinda hard to enforce; one person fails to update the obfuscated symbol mapping, or whatever shared state is supposed to be passed along, and everything's hosed). Do the following: 1. You will need to make a choice of either leaking identifier length, or having a maximum identifier length. This is because an encryption algorithm is a reversible mapping, and needs to operate over a finite set of elements. You can either have a distinct set for each identifier length or have a single set which has a finite number of possible elements thanks to the raw token length being constrained. If there are resource constraints (e.g. tokens can be a significant fraction library size), be prepared for the likelihood that if you take the second path (not leaking token size), that all of your encrypted tokens will be near the maximum size (so, if you pick 100-character max size, so you won't constrain your programmers, expect that encrypted tokens will all be close to 100 characters long). 2. Develop a one-to-one mapping between symbols expressible in your grammar and numeric values with a finite scope. For example, let's say symbols are C++-legal tokens, which can begin with a letter or _ (case-sensitive, 53 alternatives) and then each following character can be a letter, a digit, or an underscore (63 alternatives). In that case, you could derive a value by mapping each character to a value 0-63 (where the digit characters are mapped to values 54-63) and construct a numeric value for the token as follows: * c_i is the numeric value for character i of the token (where c_0 is the first character) * the value of the token = c_0 + c_1 * 53 + c_2 * (53 * 63) + c_3 * (53 * 63^2) + ... + c_n * (53 * 63^(n-1)) * (This is the same as constructing a number which is base 63, except for being base 53 in the least-significant digit). For more complex grammars, it can be more challenging to construct the mapping, but it should be possible. 3. You now have a bidirectional mapping between legal tokens and values 0..MAX, where MAX is the token with the highest possible value (c_0..c_n are each selected to be 53 or 63, as appropriate, in our example). 4. You can now construct an encryption algorithm which encrypts within this set. Alternatives include: a. Express the value as a bitstring of n bits long (where 2^(n-1) = MAX 2^n), and construct an n-bit block cipher using a balanced or unbalanced Feistel construction, where you can use a strong block cipher (e.g. AES) as the f() function and require only a few rounds (I don't recall the minimum for strong security, 3 or 4). If the encrypted value is greater than MAX, encrypt again until it is not; this will require, on average, less than 2 applications of the block cipher before you get a value = MAX. Then, reverse the token encoding to get a random-looking token that can be decrypted by reversing the procedure. b. Express the value as a bitstring and use a stream cipher. Similarly, if the encrypted value ends up overflowing MAX, reencrypt until it doesn't. You'll need to rekey the cipher for each token, so create a salt from the original token, perhaps by hashing it with SHA-1 or similar, and take a certain number of the bits (suitable to minimize the possibility of salt collision across the number of tokens to be encrypted with a single key). Map the salt to token-legal grammar and emit encoded tokens by prepending the salt to your (token-encoded) encrypted result (you may need something somewhat more complex for certain token grammars). I hope
Re: [cryptography] obfuscating symbols without increasing their size
On Wed, Jan 19, 2011 at 10:37 PM, travis+ml-rbcryptogra...@subspacefield.orgtravis%2bml-rbcryptogra...@subspacefield.org wrote: 4. You can now construct an encryption algorithm which encrypts within this set. Alternatives include: Ah, I hadn't considered the re-hashing until it fell within range. But why do I not see cryptographically-strong permutations for sets with cardinality other than 2^n? It seems like a very natural primitive for certain things, albeit not for passing octet streams. Seems like academics would be all over that like wet on water. Maybe I'm just not googling the right things, or looking in the right places. I wrote an essay on this once, but I can't find it now. I had diagrams everything. You can avoid the rehashing by building a feistel-constructed block cipher that works modulo N, with addition as the mixing operator rather than XOR. For example, if you wanted to encrypt 8-character C++ identifiers (cardinality of the set = 53*63^7 = 208765973875851), then you can, in each round, split into two unbalanced halves (left = v / 63^4 (truncating division); right = v % 63^4); then, the left has values 0..13252490, and the right has values 0..15752960. In each round, you calculate f(right), where f is a cryptographically mostly-secure keyed mapping (not necessarily reversible) from the values 0..15752960 to 0..13252490. For our purposes, AES-encrypting the right side and then reducing the result modulo 13252491 is probably fine; it's not a perfectly balanced value, but I'm guessing it's enough for your purposes; even if it weren't, it's nothing that a few more rounds wouldn't fix. The output of the round is right * 13252491 + (f(right) + left) % 13252491. I found http://www.cs.ucdavis.edu/~rogaway/papers/thorp.pdf linked-to from the Wikipedia Feistel cipher article. It has some citations that will get you further in the literature. - Tim ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
