Re: [cryptography] HKDF salt
On Thu, Aug 01, 2013 at 10:16:51AM +0100, Michael Rogers wrote: My understanding of the above is that the salt doesn't increase the entropy of HKDF's output from the adversary's point of view, since the adversary knows the salt value. However, the salt prevents accidental collisions if identical initial keying material is used in multiple application domains. Is that right? Can anyone shed light on the meaning of source-independent extraction? The reasoning for this is in the paper On Extract-then-Expand Key Derivation Functions and an HMAC-based KDF, where HKDF was originally defined. http://webee.technion.ac.il/~hugo/kdf/kdf.pdf The basic motivation is that having this random salt allows one to show (given various assumptions) that HKDF will produce a uniform random string given an input string with sufficient min-entropy, regardless of the source distribution. Jack ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] New small circuits for predicates on four bits and AES sbox
An interesting result, and the link also has circuit representations of the AES Sbox which they claim are smaller than any so far found - one of them 32 AND gates, 83 XOR/NXOR, and depth 28. - Forwarded message from Peralta, Rene rene.pera...@nist.gov - Date: Thu, 18 Jul 2013 08:22:21 -0400 From: Peralta, Rene rene.pera...@nist.gov To: Multiple recipients of list hash-fo...@nist.gov Subject: predicates on four bits, 4-bit S-boxes I am posting this to the hash forum because the algebraic properties of functions on few bits should be of interest to this community. There are more than 64,000 predicates on 4 bits, and no known algorithm for building optimal circuits for these predicates under the various metrics of interest for industrial applications or cryptanalysis. The multiplicative complexity of a function is the number of AND gates needed to implement it over the basis AND,XOR,1 (the 1 is for negation). One cannot build a hash function without incurring a linear multiplicative cost (sort of) uniformly across every circuit that implements it. The algebraic normal form of a function does not say much about this metric For example, it is not easy to build a circuit with minimum number of AND gates for a function such as g(a,b,c,d) = abcd + abc + abd + acb + acd + ab + ac + ad + bc + bd + cd. The following unexpected facts have been verified: 1) Every predicate on four bits can be implemented with at most 3 AND gates; 2) Every predicate on four bits, but of degree 3, can be implemented with 2 AND gates. The circuits can be downloaded from http://cs-www.cs.yale.edu/homes/peralta/CircuitStuff/CMT.html (see item 6: All predicates on 4 bits). The circuits were verified by Chris Wood. Thanks to Meltem Turan, Cagdas Calik, and the rest of the Circuit Minimization Team. Rene Peralta. - End forwarded message - ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] New mailing list for crypto politics/non-tech (Was: Cypherpunks mailing list)
I just created a new mailman list https://lists.randombit.net/mailman/listinfo/cryptopolitics as a venue for discussions that would normally go to cypherpunks but hasn't because of the name or spam or whatever reason, and which are off topic for this list so haven't happened here. As with this list, postings allowed only by subscribers, strong attempt at automated spam control but no human moderation. Enjoy. Jack On Mon, Mar 25, 2013 at 07:03:04PM +0100, Adam Back wrote: Cyberpunk, cypherpunk, coderpunks... is all fine, I think people have understood the etymology of those terms after a few decades, negative connotations to some of 'punk' notwithstanding, a cypherpunk is a term for an area of interest or philosophy with a dictionary definition at this point. But my point actually was b...@al-qaeda.net??? Come on that is watch list bait and an invitation NOT to join list blah, whatever it is about. Adam On Mon, Mar 25, 2013 at 06:18:14PM +0100, Eugen Leitl wrote: On Mon, Mar 25, 2013 at 05:50:18PM +0100, Adam Back wrote: Isn't exactly that a nice property of a cypherpunks list? No it is not, it is a way to persuade people to leave, or not join the listserv. We have to agree to disagree on that one. A 'punk' of any kind will tend to thumb his nose at authorities. If they consider the name annoying, so much the better. ___ 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
[cryptography] List test
___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Admin: list downtime later this week
Morning all, I'll be moving mailman and postfix to a new host later this week, likely on Thursday, or Saturday otherwise. Expected downtime is no more than a handful of hours so mails shouldn't even bounce, but figured I would send a note so people know what is going on just in case expectations and reality diverge overmuch and the list ends up being down for a couple of days. Jack ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Keccak and the one algorithm to rule them all
On Wed, Jan 23, 2013 at 10:20:23AM +0300, ianG wrote: If one skims this presentation by Joan Daemen, co-inventer of Keccak, it seems that the algorithm can also be used for the other modes -- encryption, (h)mac, authenticated encryption as well as message digest. In addition to HMAC, Keccak is safe to use in simple constructions like H(K||M) because of the sponge design (no message extension attack). Te core of Keccak is a (somewhat slow) unkeyed permutation which probably could be converted to a block cipher somehow, allowing it to be used in a generic AE construction like EAX or SIP. However I don't recall any of the Keccak documentation proposing how it would be used as a keyed permutation. Keccak could also be used as a stream cipher, with for instance each H(Key||IV||Ctr) producing 4K bytes of output. Though the SHA-3 specification only supports specific output lengths, Keccak can produce arbitrary length keyed outputs and this seems easy to convert to an AE mode by composing it (carefully) with Keccak-MAC. -Jack ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On Mon, Jun 18, 2012 at 10:20:35AM -0700, Jon Callas wrote: On Jun 18, 2012, at 5:26 AM, Matthew Green wrote: The fact that something occurs routinely doesn't actually make it a good idea. I've seen stuff in FIPS 140 evaluations that makes my skin crawl. This is CRI, so I'm fairly confident nobody is cutting corners. But that doesn't mean the practice is a good one. I don't understand. A company makes a cryptographic widget that is inherently hard to test or validate. They hire a respected outside firm to do a review. What's wrong with that? I recommend that everyone do that. When the vendor of the product is paying for the review, _especially_ when the main point of the review is that it be publicly released, the incentives are all pointed away from looking too hard at the product. The vendor wants a good review to tout, and the reviewer wants to get paid (and wants repeat business). I have seen cases where a FIPS 140 review found serious issues, and when informed the vendor kicked and screamed and threatened to take their business elsewhere if the problem did not 'go away'. In the cases I am aware of, the vendor was told to suck it and fix their product, but I would not be so certain that there haven't been at least a few cases where the reviewer decided to let something slide. I would also imagine in some of these cases the reviewer lost business when the vendor moved to a more compliant (or simply less careful) FIPS evaluator for future reviews. I am not in any way suggesting that CRI would hide weaknesses or perform a lame review. However the incentives of the relationship do not favor a strong review, and thus the only reason I would place credence with it is my impression of the professionalism of the CRI staff. In contrast, consider a review by, say, a team of good grad students, where the incentive is very strongly to produce a publishable result and only mildly on making the vendor happy. Those incentives again are not perfect (what is), especially given how academic publishing works, but they are somewhat more aligned with the end users desire to have a product that is secure. Un-reviewed crypto is a bane. Bad crypto with a rubber stamp review is perhaps worse because someone might believe the stamp means something. -Jack ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On Mon, Jun 18, 2012 at 01:21:20PM -0700, Jon Callas wrote: I am not in any way suggesting that CRI would hide weaknesses or perform a lame review. But that is *precisely* what you are saying. Jon Stewart could parody that argument far better than I can. You're not saying that CRI would hide things, you're just saying that accepting payment sets the incentives all the wrong way and that all companies would put out shoddy work so long as they got paid, especially if giving a bad review would make the customer mad. Come on. If you believe that this report is not worth the bits its written on because it was done for-pay, at least say so. If you think that they guys who put their names on the paper have prostituted their reputations, have the courage to say so. Of course maintaining reputation (and self-respect, for the people there) are large incentives for a company like CRI and that is why I explicitly stated is that the only reason I would place credence with it is my impression of the professionalism of the CRI staff, echoing Matt's comment that This is CRI, so I'm fairly confident nobody is cutting corners. In other words, only grad students are qualified to make an independent review No, merely that the incentives are somewhat better aligned between the reviewers and the end user. and universities are not tainted by money. Not sure where I said that. I think sharp grad students are among the best reviewers possible. I think they do fantastic work. But there isn't a single paper from them that I've ever seen that didn't essentially stop abruptly because the funding ran out, or time ran out, or they decided to do something else like graduate. I am not familiar with any security review process that has unlimited time and money. *All* reviews are limited by scope that is controlled by resources. *All* reviews have a set of perverse incentives around them. The perverse incentives of professional review are indeed out of phase with the perverse incentives of academics. Yes. I agree entirely. Un-reviewed crypto is a bane. Bad crypto with a rubber stamp review is perhaps worse because someone might believe the stamp means something. So we shouldn't bother to get reviews, because they're just rubber stamps? Of course not, if the review is a good one done by someone who knows what they are doing it has enourmous value. Very likely the reviews CRI does are of this form. Thus my phrase 'rubber stamp review', meaning to imply a distinct thing from a review of depth conducted with care by people skilled in the relevant areas. To suggest that professionals are inherently corrupt is insulting to everyone in this business The incentives in a pay-for-review model are misaligned in terms of producing a non-optimal result for end users. Pointing out this fact is not a personal attack on anybody. To suggest that academia is somehow free of bias shows a blind spot. To go further and suggest that only academia has pure motives shows how big academia's blind spots are. Let me repeat: Those incentives again are not perfect (what is), especially given how academic publishing works -Jack ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On Mon, Jun 18, 2012 at 11:58:56AM -0700, Kyle Hamilton wrote: So what can we do to solve it? Create our own reputable review service? Who would pay for it? Who could pay for it? Who *should* pay for it? At first it seems like irony that buyer-pays is likely the process best aligned with the buyers interests and yet most people are willing to pay very little if anything for additional security, and organizations typically will only pay for as much as (and exactly in the form that) their regulator requires. Likely this suggests something about the true nature of the interests of the market. :) Maybe there is room for a Consumer Reports/Cooks Illustrated-style review model, which does have the advantage of spreading the review costs over many buyers. I don't know of any attempts like this though. Given that the penalty for an individual who works at a US Federal contractor on a US Federal contract who is found to have skimped on quality control is pretty much a 20-year guaranteed felony imprisonment, I have more faith in the CMVP than you appear to. I've never heard about someone trying to talk past, say, an AES implementation that didn't actually work, or a bad RSA, that's a pretty bright line. In that sense, FIPS is very good for setting a minimum bar, ensuring that the system is not completely screwed up. However because most attacks can either be ignored or specificationed around in the security policy or by shooting for a lower level of validation, FIPS 140 is not very good at producing a product which can protect against a determined attacker [1]. The tests are mostly affirmatives 'does it work', not 'how can I cause this to break'. Also, CMVP-validated and NIST-certified modules which implement Suite B (ECC and AES) are permitted to protect US national secrets up to Secret level. I don't think NSA is going to let that happen with modules it lets the military and its contractors use. I agree this is the case, but I would also guess that NSA has its own review process for this. For instance, FIPS 140 says nothing about cache or timing attack countermeasures [2], which are pretty relevant for AES and ECC and which I would hope (!) the NSA would bake into its own procurement processes and in what it recommends or requires DoD contractors to use. (I would be interested if anyone knows the details of this, though). -Jack [1] Note that I am not saying that FIPS certified products intrinsically cannot protect against determined attackers, just that it is likely that any product which could do so likely did it without much help from the FIPS review process. [2] OK I just checked, the FIPS 140-3 draft does finally require countermeasures against DPA and timing attacks for level 3+ hardware evals. No such requirements for software though. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Moderation (Was: US Appeals Court upholds right not to decrypt a drive)
On Mon, Feb 27, 2012 at 09:01:31AM +0100, Harald Hanche-Olsen wrote: [Kevin W. Wall kevin.w.w...@gmail.com (2012-02-27 01:50:40 UTC)] Well, we're already considerably OT, but since the moderator seems to be letting this thread play itself out, [...] Moderator? The list has a moderator? No. As it says on the tin at http://lists.randombit.net/mailman/listinfo/cryptography The list is entirely unmoderated... My assumption is that anyone who is interested and capable of moderating a crypto mailing list will inevitably find that they have more interesting things to do than moderating a crypto mailing list (the failure mode of cryptogra...@metzdowd.com). But seriously, we can all be moderators in the sense of asking nicely to take certain discussions elsewhere. That's the intent, and your efforts are appreciated. There was a long discussion about this approach and the possible failure modes early on. Obviously this strategy working well assumes a lot things about the nature of the list participants which may or may not be true. -Jack ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Applications should be the ones [GishPuppy]
On Thu, Feb 16, 2012 at 09:41:04PM -0600, Nico Williams wrote: developers agree). I can understand *portable* applications (and libraries) having entropy gathering code on the argument that they may need to run on operating systems that don't have a decent entropy provider. Another good reason to do this is resiliance - an application that takes some bits from /dev/(u)random if it's there, but also tries other approaches to gather entropy, and mixes them into a (secure) PRNG, will continue to be safe even if a bug in the /dev/random implementation (or side channel in the kernel that leaks pool bits, etc) causes the conditional entropy of what it is producing to be lower than perfect. I'm sure at some point we'll see a fiasco on the order of the Debian OpenSSL problem with /dev/random in a major distribution. Contemplate, if you will, this /dev/random implementation: http://syllable.cvs.sourceforge.net/viewvc/syllable/syllable/system/sys/kernel/drivers/misc/random/random.c?revision=1.4view=markup http://syllable.cvs.sourceforge.net/viewvc/syllable/syllable/system/sys/kernel/kernel/random.c?revision=1.5view=markup -Jack ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Applications should be the ones [GishPuppy]
On Fri, Feb 17, 2012 at 11:33:15AM -0800, Jon Callas wrote: Really? Let's suppose I've completely compromised your /dev/random and I know the bits coming out. If you pull bits out of it and put them into any PRNG, how is that not just Bits' = F(Bits) ? Unless F is a secret function, I just compute Bits' myself. If F is a secret function than the security is exactly the secrecy of F. Jon Sorry, perhaps I wasn't clear that my reference was to having additional entropy gathering code is also useful on platforms with a /dev/random, because your PRNG output is F(Bits from /dev/random || Bits from somewhere else). So I suppose in some sense this coincides with your second case, as one could view the above as F(Bits from /dev/random) where F is keyed with an input chosen from a non-uniform distribution, and certainly I concur that if you know or can easily guess both the entire output of /dev/random and the complete results of whatever ad-hoc system specific entropy gathering is available then you could in fact also guess the PRNG output. And I concur that if you know the /dev/random output then the security of the PRNG would rest entirely on the conditional entropy of the ad-hoc polling -- which is precisely my point as to why it is a useful approach, because it requires two things to fail instead of just one. Additionally there is a more plausible case than you know exactly what bits my /dev/random will produce, which is that you know something about the probability distribution of the output that distinguishes it from uniform random. In that case, even F(Bits) could be useful if you are compressing down in size (eg transforming 2*N bits of input into N bits of key material). -Jack ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] CAPTCHA as a Security System?
On Mon, Jan 02, 2012 at 08:03:07PM +0100, Marcus Brinkmann wrote: Computer programs today are limited by attention of experts (programmers, researchers). What does hard for computer programs actually mean then? Is there a theoretical boundary that limits the abilities of computer programs to recognize captures, or is Ahn just exploiting a temporary lack of economic incentive to realize the full capabilities of computer systems for these kind of problems? That was a pretty explicit aspect to the whole proposal. It adds incentives to solve supposedly difficult AI problems. (Or incentives to build very efficient mechanical turk systems, which is of course what mostly happened because that's cheaper and more reliable than funding AI research). Quoting from the paper Much like research in cryptography has had a positive impact on algorithms for factoring and discrete log, we hope that the use of hard AI problems for security purposes allows us to advance the field of Artificial Intelligence. We introduce two families of AI problems that can be used to construct captchas and we show that solutions to such problems can be used for steganographic communication. captchas based on these AI problem families, then, imply a win-win situation: either the problems remain unsolved and there is a way to differentiate humans from computers, or the problems are solved and there is a way to communicate covertly on some channels. and A primary goal of the captcha project is to serve as a challenge to the Artificial Intelligence community. -Jack ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Reply-To header (Was: Non-governmental exploitation of crypto flaws?)
On Mon, Nov 28, 2011 at 08:40:45PM -0500, Steven Bellovin wrote: On Nov 28, 2011, at 8:03 PM, Nico Williams wrote: The list is configured to set Reply-To. This is bad, and in some cases has had humorous results. I recommend the list owners change this ASAP. Agree, strongly. The mailman documentation agrees with us. I'm on the verge of unsubscribing on the grounds that the list is a privacy violation in action. I've flipped that switch in mailman. I was not aware this was a contentious issue. Mutt asks if I want to reply to sender or list regardless, with the default being one or the other depending on the list's setting. I didn't consider other mailers might not behave this way. For future reference, complaints about list management (such as it is) are best sent to me directly (or at least CC'ed) as I really don't read every post. -Jack ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ECDSA - patent free?
On Wed, Nov 09, 2011 at 07:22:08PM +0100, Adam Back wrote: Any suggestions on EC capable crypto library that implements things without tripping over any certicom claimed optimizations? They can claim whatever they want. Since they have more money for lawyers than most open source projects, they win by default. Likely most of the commercial implementations pay their tithe, regardless of what they actually implement, for CYA purposes. (Someone pointed out to me recently that the redhat shipped openSSL is devoid of ECC which is kind of a nuisance!) They also strip IDEA, even though the patents are expired. For some reason RH legal seems especially frightened of crypto patents; it's not like dozens of features of gcc, the kernel, etc aren't covered by patents. This may partially be due the the lack of ambigiuity; for instance they probably wouldn't strip a cipher that happened to be covered by the claims of the IDEA patent that wasn't actually IDEA, but at the same time nobody would use it because it was an unstudied design. Whereas if the kernel is or is not violating a patent on RCU or linked lists or whatever is a touch more subtle and ambigious. I told them about RFC 6090 and they're 'looking into it' but I don't expect much. It's too easy to have a hard rule of 'algos X, Y, Z' are banned. Suite B pushed use of EC you would think would increase the interest in having clarity on the EC patent situation.. Cui bono? -Jack ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] HMAC over messages digest vs messages
On Wed, Nov 02, 2011 at 04:25:30PM -0300, Leandro Meiners wrote: Hi List! I was wondering if anybody could give me some pointers as to papers or books that discuss the advantages/disadvantages of computing an HMAC of a message versus previously computing a hash of the message and then calculating the HMAC of the hash. My initial thoughts are that there isn't any additional security provided by either method. It seems like it would be harder (or at least not easier) to find a collision or preimage for HMAC with an unknown key than a collision or preimage for an unkeyed hash, so using HMAC(H(m)) allows for an avenue of attack that HMAC(m) would not, namely finding an inner collision (or preimage) on H. Consider, for instance attacking HMAC-MD5(m) vs HMAC-MD5(MD5(m)). -Jack ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Duong-Rizzo TLS attack (was 'Re: SSL is not broken by design')
On Mon, Sep 19, 2011 at 02:57:21PM -0400, Kevin W. Wall wrote: So does anyone know anymore details on this? Specifically is it an implementation flaw or a design flaw? Duong Rizzo's previous work relied on padding oracle attacks whereas this one is categorized as a chosen-plaintext attack, so it looks like it's not building on their previous work. Lastly, would anyone care to speculate whether (for instance) using RC4 intead of AES/CBC protect you from this chosen-plaintext attack? The article cited by the URL that Marsh mentioned only mentions AES so perhaps other cipher choices are immune. Just not a lot of details available yet. Guess will have to wait until Friday. According to this article [1] in The Register (caveat lector), it only affects TLS 1.0, not 1.1/1.2, and exploits a vulnerability in TLS that has long been regarded as mainly a theoretical weakness, so I'm guessing it has to do with the CBC block carryover used in SSLv3 and TLS 1.0. If that is the case, then using RC4 would not be vulnerable. On this basis, I'm wondering if the workaround Opera deployed is to simply not negotate !RC4 when using TLS 1.0. This could be done by either disabling DES/AES entirely, or try a 1.1/1.2 handshake and then if the server hello comes back with 1.0 and a non-RC4 ciphersuite to drop the handshake and retry with only RC4 ciphersuites and carry on from there. -Jack [1] http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Single-key key recovery for full AES
http://research.microsoft.com/en-us/projects/cryptanalysis/aesbc.pdf I'm wondering how easily the new preimage attack they describe (on AES in Davies-Meyer) can be applied to any of the AES-based SHA-3 candidates. Abstract follows Since Rijndael was chosen as the Advanced Encryption Standard, improving upon 7-round attacks on the 128-bit key variant or upon 8-round attacks on the 192/256-bit key variants has been one of the most difficult challenges in the cryptanalysis of block ciphers for more than a decade. In this paper we present a novel technique of block cipher cryptanalysis with bicliques, which leads to the following results: - The first key recovery attack on the full AES-128 with computational complexity 2^126.1 - The first key recovery attack on the full AES-192 with computational complexity 2^189.7 - The first key recovery attack on the full AES-256 with computational complexity 2^254.4 - Attacks with lower complexity on the reduced-round versions of AES not considered before, including an attack on 8-round AES-128 with complexity 2^124.9 - Preimage attacks on compression functions based on the full AES versions. In contrast to most shortcut attacks on AES variants, we do not need to assume related-keys. Most of our attacks only need a very small part of the codebook and have small memory require- ments, and are practically verified to a large extent. As our attacks are of high computational complexity, they do not threaten the practical use of AES in any way. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] RDRAND and Is it possible to protect against malicious hw accelerators?
On Sun, Jun 19, 2011 at 04:56:34PM +1200, Peter Gutmann wrote: I know how to check the carry flag from inline asm, I just don't know what the rdrand encoding is. Here's the code I sent to the OP, I hadn't posted it yet because I need to get someone with access to the appropriate hardware to verify it: I don't know if anyone outside of Intel has hardware, but it looks like the latest release of Intel's SDE supports it. http://software.intel.com/en-us/articles/intel-software-development-emulator/ It's obviously quite slow, but still a very useful tool for testing CPU specific code before the silicon is commercially available. -Jack ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] not unsubscribing (Re: Unsubscribing)
On Thu, Jun 16, 2011 at 09:17:56PM +0200, Adam Back wrote: Trust me the noise level on here is zero compared to usenet news flame fests, spam, DoS etc. The maintainer is removing spam for one (I think). I am definitely trying to prevent any spam from going to the list. The anti-spam measures are entirely automated though, so some may get through eventually. If any shows up, please mail me about it offlist (as I might not see it, if it gets caught by spamassassin the second time around.) But besides the spam countermeasures, there is no approval system, mails just go out and I see them the same time as anyone else. -Jack ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] If this isn't a honey-pot, it should be
Need something to be encrypted? Just upload it to us and we'll encrypt it for you. Don't worry, we delete everything. Promise. https://encryptur.com/ In fairness, this is no worse that downloading some random program off the internet and using it for the same purpose. At least here the worst case is basically that someone gets your plaintext (and later extorts you when you want the plaintext back), vs rootkiting your machine when you run that proggie as Admin. -J ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Oddity in common bcrypt implementation
On Tue, Jun 14, 2011 at 04:52:30PM -0500, Marsh Ray wrote: The first 7 chars $2a$05$ are a configuration string. The subsequent 53 characters (in theory) contains a 128 bit salt and a 192 bit hash value. But 53 is an odd length (literally!) for a base64 string, as base64 uses four characters to encode three bytes. I don't see an official reference for the format of bcrypt hashes. There's the Usenix 99 paper, which is a great read in many ways, but it's not a rigorous implementation spec. I discovered this a while back when I wrote a bcrypt implementation. Unfortunately the only real specification seems to be 'what the OpenBSD implementation does'. And the OpenBSD implementation also does this trunction, which you can see in ftp://ftp.fr.openbsd.org/pub/OpenBSD/src/lib/libc/crypt/bcrypt.c with encode_base64((u_int8_t *) encrypted + strlen(encrypted), ciphertext, 4 * BCRYPT_BLOCKS - 1); Niels Provos is probably the only reliable source as to why this truncation was done though I assume it was some attempt to minimize padding bits or reduce the hash size. -Jack ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] ECC patent FUD
On Mon, Nov 15, 2010 at 09:36:58PM -0600, Marsh Ray wrote: For one thing, open source projects wouldn't go along with it. http://fedoraproject.org/wiki/User:Peter/Disabled_applications This is due to excessive paranoia on the part of RH's legal department (they are assuming even ECDH over GF(p) is still patented, for instance). I pointed them to draft-mcgrew-fundamental-ecc [1], hopefully once that hits RFC they will take it into consideration. elliptic curves using keys a bit shorter than RSA, but that those who do so sometimes end up paying ++$M. From my perspective, this is effectively equivalent to the algorithm having a rather severe form of security vulnerability. Thus ECC just does not seem technically relevant to me at this time. I think you (as with RH) are making too many simplifying assumptions. A particular implementation of, say, ECDSA, probably is covered by a number of implementation patents, but then again so is the modexp algorithm your RSA implementation uses, because to a first order approximation everything is patented. Using an algorithm invented in 1978 won't necessarily be any safer for you than using one from 1985, especially in the current patent landscape. If someone wants to sue you, not using ECC isn't exactly going to save you. It's also worth noting that the Certicom patent that they actually sued Sony over does not seem to be specific to ECC but would cover the same usage in a standard mod-p group. -Jack [1] http://tools.ietf.org/html/draft-mcgrew-fundamental-ecc-03 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
