Re: Disk encryption advice...
On Fri, Oct 08, 2010 at 04:27:57PM -0400, Perry E. Metzger wrote: I have a client with the following problem. They would like to encrypt all of their Windows workstation drives, but if they do that, the machines require manual intervention to enter a key on every reboot. Why is this a problem? Because installations and upgrades of many kinds of Windows software require multiple reboots, and they don't want to have to manually intervene on every machine in their buildings in order to push out software and patches. (The general threat model in question is reasonably sane -- they would like drives to be harmless when machines are disposed of or if they're stolen by ordinary thieves, but on the network and available for administration the rest of the time.) Does anyone have a reasonable solution for this? Commercial products have a mode in which you can drop the requirement for a key for one reboot. Presumbly the key is then erased. This may a reasonable compromise. The devil is in the details. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Formal notice given of rearrangement of deck chairs on RMS PKItanic
On Wed, Oct 06, 2010 at 04:52:46PM +1300, Peter Gutmann wrote: From https://wiki.mozilla.org/CA:MD5and1024: December 31, 2010 - CAs should stop issuing intermediate and end-entity certificates from roots with RSA key sizes smaller than 2048 bits [0]. All CAs should stop issuing intermediate and end-entity certificates with RSA key size smaller than 2048 bits under any root. [...] Right, because the problem with commercial PKI is all those attackers who are factoring 1024-bit moduli, and apart from that every other bit of it works perfectly. Peter. [0] This is ambiguously worded, but it's talking about key sizes in EE certs. What are EE certs, did you mean EV? -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Randomness, Quantum Mechanics - and Cryptography
On Tue, Sep 07, 2010 at 10:22:57PM -0400, Jerry Leichter wrote: But there isn't actually such a thing as classical thermodynamical randomness! Classical physics is fully deterministic. Thermodynamics uses a probabilistic model as a way to deal with situations where the necessary information is just too difficult to gather. Classically, you could in principle measure the positions and momenta of all the atoms in a cubic liter of air, and then produce completely detailed analyses of the future behavior of the system. There would be no random component at all. In practice, even classically, you can't hope to get even a fraction of the necessary information - so you instead look at aggregate properties and, voila, thermodynamics. There's no randomness assumption - much less an unpredictability assumption - for the micro-level quantities. What you need is some uniformity assumptions. If I had access to the full micro details of that liter of air, your calculations of the macro quantities would be completely undisturbed. This glosses over the *fundamental* complexity of non-linear classical dynamics. It is a leap to claim that the underlying determinism of a classical dynamical system leads one to conclude that it is even in principle predictable, in the presence of chaos. We should not short-change classical chaos which is an emergent property of complex deterministic systems. http://www-chaos.umd.edu/research.html ... Riddled Basins The notion of determinism in classical dynamics has eroded since Poincar??'s work led to recognition that dynamical systems can exhibit chaos: small perturbations grow exponentially fast. Hence, physically ubiquitous measurement errors, noise, and computer roundoff strongly limit the time over which, given an initial condition, one can predict the detailed state of a chaotic system. Practically speaking, such systems are nondeterministic. Notwithstanding the quantitative uncertainty caused by perturbations, the system state is confined in phase space (on an attractor) so at least its qualitative behavior is predictable. Another challenge to determinism arises when systems have competing attractors. With a boundary (possibly geometrically convoluted ) between sets of initial conditions tending to distinct attractors (basins of attraction), perturbations make it difficult to determine the fate of initial conditions near the boundary. Recently, mathematical mappings were found that are still worse: an attractor's entire basin is riddled with holes on arbitrarily fine scales. Here, perturbations globally render even qualitative outcomes uncertain; experiments lose reproducibility. J.C. Sommerer and E. Ott, A Qualitatively Nondeterministic Physical System, Nature, 365, 135 (1993). -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: What's the state of the art in factorization?
On Tue, Apr 20, 2010 at 08:58:25PM -0400, Thierry Moreau wrote: The DNS root may be qualified as a high valued zone, but I made the effort to put in writing some elements of a risk analysis (I have an aversion for this notion as I build *IT*controls* and the consultants are hired to cost-justify avoiding their deployments, basically -- but I needed a risk analysis as much as a chief financial officer needs an economic forecast in which he has no faith.) The overall conclusion is that the DNS root need not be signed with key sizes that would resist serious brute force attacks. See http://www.intaglionic.org/doc_indep_root_sign_proj.html#TOC:C. (document annex C. Risk Analysis Elements for DNSSEC Support at the Root). This conclusion is arrived at in a rather ad-hoc fashion. One can equally easily reach opposite conclusions, since the majority of administrators will not configure trust in static keys below the root, and in many cases domains below the root will have longer keys, especially if the root keys are not conservative. Sure, cracking the root will not be the easiest attack for most, but it really does need to be infeasible, as opposed to just difficult. Otherwise, the root is very much an attractive target for a well funded adversary. Even if in most cases it is easier to social-engineer the domain registrar or deliver malware to the desktop of the domain's system administrator. By the way, state-of-the-art in factorization is just a portion of the story. What about formal proofs of equivalence between a public key primitive and the underlying hard problem. Don't forget that the USG had to swallow RSA (only because otherwise its very *definition* of public key cryptography would have remained out-of-sync with the rest) and is still interested in having us adopt ECDSA. EC definitely has practical merit. Unfortunately the patent issues around protocols using EC public keys are murky. Neither RSA nor EC come with complexity proofs. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Tue, Nov 17, 2009 at 01:35:12AM -, John Levine wrote: So should or should not an embedded system have a remote management interface? In this case, heck, no. The whole point of this thing is that it is NOT remotely programmable to keep malware out. Which is perhaps why it is not a good idea to embed an SSL engine in such a device. Its external interface should be as simple as possible, which suggests a message-signing device, rather than a device that participates in complex, evolving, interactive protocols with remote network services. The integration of the message signing device with a complete system (computer with browser + device) should include most of the complex and likely to change software. The device itself, is just a display + encrypt then sign black-box for suitably simple (to unambiguously display) messages, and the transmission of the signed message to the appropriate destination can be left to the untrusted PC. Such a device does however need to be able to suppor multiple mutually distrusting verifiers, thus the destination public key is managed by the untrusted PC + browser, only the device signing key is inside the trust boundary. A user should be able to enroll the same device with another bank, ... The proliferation multiple of SecurId tokens per user in B2B financial services has led to a search for greater than drawer-full of SecurId cards (with PIN glued to the back of each) usability. The alternatives are not always very strong, but a would be more-secure solution needs to keep usability in mind for the case when the user needs to conduct secure transactions with multiple parties. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS break
On Wed, Nov 11, 2009 at 10:57:04AM -0500, Jonathan Katz wrote: Anyone care to give a layman's explanation of the attack? The explanations I have seen assume a detailed knowledge of the way TLS/SSL handle re-negotiation, The re-negotiation handshake does not *commit* both parties in the new handshake to the previous cryptographic state of the TLS connection. If the man in the middle is willing to encrypt/decrypt handshake packets between a client new to the connection, and a server with which the MITM completed an earlier handshake, the MITM can transfer an existing session from himself to the client (victim), after injecting some initial data into the connection. The integrity and confidentiality properties of the origimal MITM-server connection only protect both parties if neither party is willing to compromise those properties by proxying a 3rd party into the session. The new ingredient here, is that the 3rd party can be a victim, who is unaware of the proxying. The victim's handshake with the intended server is proxied into an already established TLS session by the MITM who is privy to the session state. The solution is to *commit* the two parties to a re-negotiation handshake to the previous handshake. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS break
On Sun, Nov 08, 2009 at 01:08:54PM -0500, Perry E. Metzger wrote: I'll point out that in the midst of several current discussions, the news of the TLS protocol bug has gone almost unnoticed, even though it is by far the most interesting news of recent months. Not entirely unnoticed: http://www.porcupine.org/postfix-mirror/wip.html#tls-renegotiation For HTTPS, it has been observed that this is not entirely different from existing CSRF attacks, but it should be noted that with the new attack, checking Referrer headers is no longer effective, so anti-CSRF defenses have to be more sophisticated (they *should* of course be more sophisticated, but they rarely are, if they are present at all). I am looking forward to analyses for other protocols. There is almost certainly a problem for FTP (over TLS), where just banning re-negotiation on the server is perhaps reasonable. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Possibly questionable security decisions in DNS root management
On Sat, Oct 17, 2009 at 02:23:25AM -0700, John Gilmore wrote: Given that they are attempted to optimize for minimal packet size, the choice of RSA for signatures actually seems quite bizarre. Each of these records is cached on the client side, with a very long timeout (e.g. at least a day). So the total extra data transfer for RSA (versus other) keys won't be either huge or frequent. DNS traffic is still a tiny fraction of overall Internet traffic. Yes, normal DNS traffic is not the issue. The optimization is for DDoS conditions, especially amplification via forged source IP DNS requests for . IN NS?. The request is tiny, and the response is multiple KB with DNSSEC. We now have many dozens of root servers, scattered all over the world, and if the traffic rises, we can easily make more by linear replication. DNS *scales*, which is why we're still using it, relatively unchanged, after more than 30 years. Some (e.g. DJB, and I am inclined to take him seriously), are quite concerned about amplification issues with DNSSEC. Packet size does matter. RSA was the obvious choice because it was (and is) believed that if you can break it, you can factor large numbers (which mathematicians have been trying to do for hundreds of years). No other algorithm available at the time came with such a high pedigree. As far as I know, none still does. Well, most of the hundreds of years don't really matter, modern number theory starts with Gauss in ~1800, and the study of elliptic curves begins in the same century (also Group theory, complex analysis, ...). It is not clear that the pedigree of RSA is much stronger than that for ECC. The DNSSEC RSA RFC says: For interoperability, the RSA key size is limited to 4096 bits. For particularly critical applications, implementors are encouraged to consider the range of available algorithms and key sizes. Perhaps believed sufficiently secure, but insanely large for DNS over UDP. Packet size does matter. If this crypto community was serious about resistance to RSA key factoring, the most popular key generation software would be picking key sizes *at random* within a wide range beyond the number of bits demanded for application security. There is no incentive to use keys smaller than the top of the range. An algorithm that cracks k-bit RSA keys, will crack all keys with nk bits. That way, there'd be no sweet spots at 1024 or 2048. There is no sweet spot. These sizes are believed to approximately match 80-bit, 112-bit, 128-bit ... sizes for symmetric keys (for RSA 1024, 2048, and 3072). Why should one bother with a random size between 1024 and 2048, if everyone supports 2048, and 2048-bit signatures are practical in the context of the given protocol? -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Question about Shamir secret sharing scheme
On Sat, Oct 03, 2009 at 02:42:14AM -0400, Kevin W. Wall wrote: The secret S can then be computed by finding f(0) more or less by using Lagrangian interpolation on the t shares, the points (i, Si). The question that a colleague and I have is there any cryptographic purpose of computing the independent coefficients over the finite field, Zp ? The only reason that we can see to doing this is to keep the sizes of the shares Si bounded within some reasonable range and it seems as though one could just do something like allowing T choose random coefficients from a sufficient # of bytes and just do all the calculations without the 'mod p' stuff. Lagrange interpolation works for polynomials over a field. The most convenient *finite* fields in this context are the Z_p for prime p. In this context it is also easy to make a uniform choice of a random coefficient and to quantify the work-factor for a brute-force attack. With rationals, everything is much messier. There is no good reason to work over Q. We thought perhaps Shamir did the calculations of Zp because things like Java's BigInteger or BigDecimal weren't widely available when came up with this scheme back in 1979. An algorithm is not the same an implementation. There was no Java back then either, and people still somehow wrote working code in '79. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Merry Certmas! CN=*\x00thoughtcrime.noisebridge.net
On Tue, Sep 29, 2009 at 10:51:33PM -0700, Jacob Appelbaum wrote: It's been long enough that everyone should be patched for this awesome class of bugs. This certificate and corresponding private key should help people test fairly obscure software or software they've written themselves. I hope this release will help with confirmation of the bug and with regression testing. Feel free to use this certificate for anything relating to free software too. Consider it released into the public domain of interesting integers. If anyone is curious about the impact of this on the Postfix TLS engine (March 2006, version 2.3.0 and later releases): 1. Postfix checks subject domains obtained from either subjectAltName or CN to ensure that the ASN.1 string object length is equal to the C string length. Certificates that fail this test are considered anonymous. These checks were added in the Spring of 2005 when the contributed TLS patch adopted in the 2.2 release was significantly extended and revised. 2. Postfix only matches *.example.com certificates against single-label sub-domains of example.com. Thus for example, the Postini wild-card certificate for: *.psmtp.com does not match (say Verisign's), MX records of the form: verisign.com. IN MX 100 verisign.com.s6a1.psmtp.com. verisign.com. IN MX 200 verisign.com.s6a2.psmtp.com. verisign.com. IN MX 300 verisign.com.s6b1.psmtp.com. verisign.com. IN MX 400 verisign.com.s6b2.psmtp.com. (Postfix also does not, for secure-channel destinations, trust DNS enough to let MX records influence the name expected in a peer certificate. So Postini's wildcard certificate is perhaps only useful with other sending systems). So a * certificate will never match any peer domain. Bottom line, this issue does not impact the Postfix secure-channel TLS use case. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: password safes for mac
On Wed, Jul 01, 2009 at 11:03:13AM -0400, Adam Shostack wrote: On Tue, Jun 30, 2009 at 11:26:06AM -0500, Nicolas Williams wrote: | On Mon, Jun 29, 2009 at 11:29:48PM -0700, Jacob Appelbaum wrote: | This would be great if LoginWindow.app didn't store your unencrypted | login and password in memory for your entire session (including screen | lock, suspend to ram and hibernate). | | I keep hearing that Apple will close my bug about this and they keep | delaying. I guess they use the credentials in memory for some things | where they don't want to bother the user (!) but they still want to be | able to elevate privileges. | | Suppose a user's Kerberos credentials are about to expire. What to do? What fraction of mac users are using Kerberos? Spefically, Kerberos to *login* to the system. I use Kerberos on the Mac all the time, but never to login, have not figured out how to make it not get in the way of using the laptop when the KDC is not reachable. Also, I roam between two Realms, office and non-office (used for IMAP and SMTP submission) and neither makes sense as the primary platform login. If I had a stationary desktop Mac at the office, that *would* use Kerberos for login. Still would be in a tiny minority though... -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Factoring attack against RSA based on Pollard's Rho
On Fri, Jun 05, 2009 at 08:07:21PM -0700, Greg Perry wrote:
I have published a unique factoring method related to Pollard's Rho that
is published here:
http://blog.liveammo.com/2009/06/factoring-fun/
Several aspects of the RSA encryption algorithm can be attacked:
attacks against the quality of the entropy pool used by the random
number generator (RNG) that creates the p and q primes; ``side
channel'' cryptanalysis attacks where key materials are divined from
power rails, shared bus architectures, shared memory segments etc;
exponential ``increase by two'' factoring attacks and
more esoteric subexponential factoring attacks
--
such as the General Number Field Sieve; and, even the tried and true
(and highly effective) Rubber Hose Cryptanalysis method.
What you call more esoteric is properly called more sophisticated
or more effective. Your attack is not sub-exponential, and is of no
practical interest for RSA moduli of cryptographic strength.
I have not yet compared the performance of this Reduction Sieve
method to GNFS or any other subexponential factoring methods.
Future testing of this factoring method will include deployment into
an 80+ node VMware cluster at our datacenter and experimentation
with on-demand cloud computing infrastructures such as Amazon?s EC2
Elastic Compute Cloud.
Such performance comparisons are unnecessary, and would be a waste of
CPU time and money. GNFS is substantially faster than Pollard's rho for
RSA moduli of interest in cryptography.
Any feedback would be appreciated.
There is nothing new here. First of all, if N mod 9 is a multiple of 3,
then N is divisible by 3, so those cases are of no interest, you would
factor N/3 instead.
For the other cases,
* Either N mod 9 is a quadratic residue mod 9, in which case
p*q == N mod 9 has 4 pairs of solutions,
(a,a), (b,b), (c,d), (e,f)
where a and b are the two square roots of N mod 9, and c,d,e,f
are the remaining units.
* Or N mod 9 is not a quadratic residue mod 9, in which case
p*q == N mod 9 has 3 pairs of solutions:
(a,b), (c,d), (e,f)
Now indeed if N = p*q for some pair of primes, and N is not a multiple
of 3, then p mod 9 is one of six possible values and q is the reciprocal
(mod 9) of that value.
Now, the Pollard rho algoritm is based on the birthday paradox for
differences between pairs of random values (x,y) mod N, being *divisible*
by a factor p of N, i.e. gcd(|x-y|,N) 1, allowing the attack to run
in n^(1/4) time instead of n^(1/2) time for naive division trials.
It should be noted that knowing p mod 9 does not tell us much about (x-y)
mod 9. We need (x-y) to be random mod p and thus be zero mod p with
the expected birthday paradox probability. So there is no reason for
(x-y) to be any particular value mod 9, even multiples of 3 are fine,
nothing wrong with (x-y) being divisible by 3p.
For the birthday paradox we can't control the difference (x-y) mod 9 for
all pairs of a large set, because if (x_1 - x_2) = a mod 9 and (x_2 -
x_3) = b mod 9, then (x_1 - x_3) is a + b, mod 9, and the additively
closed subsets of z_9 are:
{0}
{0,3,6}
{0,1,2,3,4,5,6,7,8}
so you can't practically limit (x-y) mod 9 to a given unit and still use
the birthday paradox to make rho fast.
Speaking of birthday paradoxes and making rho fast: your code appears
to completely omit any use of the birthday paradox, and so would run in
n^(1/2) time instead of n^(1/4) time. If so it is far worse than the real
Pollard algorithm that you seem to not have studied with sufficient care.
--
Viktor.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Factoring attack against RSA based on Pollard's Rho
On Sun, Jun 07, 2009 at 05:10:30PM +0100, Ben Laurie wrote: Paul Hoffman wrote: At 8:07 PM -0700 6/5/09, Greg Perry wrote: Greetings list members, I have published a unique factoring method related to Pollard's Rho that is published here: http://blog.liveammo.com/2009/06/factoring-fun/ Any feedback would be appreciated. Is there any practical value to this work? That's a serious question. The main statement about the value is This is a factoring attack against RSA with an up to 80% reduction in the search candidates required for a conventional brute force key attack. Does that mean that it reduces the search space for a 1024-bit RSA key to, at best 205 bits (0.2 * 1024) of brute force? No, no. You don't multiply by .2, you add log_2(.2), which is around -3. So, 1021 bits. Well, if this were a correct implementation of Pollard's rho, with a polynomial (not some unspecified PRNG) iterator coupled with a cycle finder (not just the computation of the gcd of each term with N), then the run time would be a non-interesting O(2^256). Now the claimed improvements of 80% are for a misconceived Pollard rho, which uses random trials gcd(PRNG, N), with a non-polynomial PRNG and no cycle finder. This should have a run-time of O(2^512), and the author claims an 80% cost reduction to ~O(2^509), but even this claim is dubious. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Factoring attack against RSA based on Pollard's Rho
On Sun, Jun 07, 2009 at 05:41:00PM -0700, Greg Perry wrote: The significance of this method is the ability to determine any properties of p and q from a simple operation to n. To be blunt, I see no significance of any kind... You have observed that unless N is divisible by 3, p and q are both also not divisible by 3. This is not new, and does not speed up factorization in any significant way (yes, you can skip candidate factors that are divisible by 3, but this is not new, and only speeds up the really slow naive algorithms like trial division). You have also observed that: N = p*q = for all moduli m, N = p * q (mod m) this too is not new, and does not speed up factorization. One does not search for both p and q simultaneously, finding the smaller of the two is sufficient, and with q not in the picture the p candidates are not constrained in any way by this relation: any prime N has an inverse mod m, provided p does not divide m. So for every prime candidate ( that is not a factor of m) the equation N = p * q (mod m) has a solution. n is a black box with p and q irretrievably discarded after key materials are created, are you aware of any process other than this method that can determine with any level of accuracy properties of p and q from n? Certainly C.F. Gauss was aware of interesting properties of this type. In Section VI, Articles 329-334 of Disquisitiones Arithmeticae, he showed a sieve for prime factors of composite numbers based on quadratic reciprocity. This sieve was useful (no computers in ~1800) for numbers difficult to factor by hand without effective short-cuts, 7-10 digit numbers with 3-5 digit prime factors. Gauss had tables of residues that made it possible to quickly read off primes that simultaneously satisfied all the residue constraints. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Warning! New cryptographic modes!
On Mon, May 11, 2009 at 02:16:45PM -0400, Roland Dowdeswell wrote: In any case, there are obvious, well-understood solutions here: Use counter mode, which propagates changes by a single block of the cryptosystem. Or use any other stream cipher mode. (An interesting question is whether there's a mode that will recover from insertions or deletions. Perhaps something like: Use counter mode. If two consecutive ciphertext bytes are 0, fill the rest of the ciphertext block with 0's, jump the counter by 65536, and insert a special block containing the new counter value.) I'm not convinced that a stream cipher is appropriate here because if you change the data then you'll reveal the plaintext. Indeed. If the remote copy is a backup, and the local file-system supports snaphots, then it is far better to arrange for the remote backup to always be a copy of a local snapshot, and to compute the rsync delta between the local copy of the remote snapshot and a newer snapshot locally, and then rsync the delta. Sure, snapshot file-systems are not yet universal, but given disk size and file-system trends, I would base encrypted remote backups on a foundation that assumed the existence of local before/after images. A cipher that produces largely identical cipher-text for largely identical plaintext in the face of updates, inserts and deletes, is unlikely to be particularly strong. The CBC IV reset should not be too disasterous if the IV is an encrypted block counter under a derived key. Drive encryption basically does the same thing with 512 byte blocks. This fails to handle inserts/deletes that are not multiples of the chunk size. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: SHA-1 collisions now at 2^{52}?
On Thu, Apr 30, 2009 at 11:07:31PM -0400, Perry E. Metzger wrote: Greg Rose g...@qualcomm.com writes: This is a very important result. The need to transition from SHA-1 is no longer theoretical. It already wasn't theoretical... if you know what I mean. The writing has been on the wall since Wang's attacks four years ago. Sure, but this should light a fire under people for things like TLS 1.2. Perhaps, though the MAC in TLS cipher-suites needs just 2nd pre-image resistance, not collision resistance. The collision resistance is more relevant to X.509 authentication, and even there only when CA practices are sub-optimal. Yes, by all means, new hash functions, but lets not over-emphasize the magnitude of the problem. This is not a SHA-1 pandemic... -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
On Fri, Jan 23, 2009 at 04:01:50PM +1100, Ben Laurie wrote: I really hope to see real OpenSSL patch releases some day with development of new features *strictly* in the development snapshots. Ideally this will start with 0.9.9a, with no new features, just bug-fixes, in [b-z]. ] I think that is not likely to happen, because that's not the way it works. The promise we try to keep is ABI compatibility between releases that have the same numbers. Letters signify new versions within that series. We do not have a bugfix-only branch. There doesn't seem to be much demand for one. Don't want to start a long debate here, but I do want to respond to this. You seem to be out of touch I am afraid. Just look at what many O/S distributions do. They adopt a new OpenSSL 0.9.Xy release from time to time (for some initial y) and back-port security fixes never changing the letter. One can't actually tell from openssl version what version one is running and which fixes have been applied. Why am I back-porting patch-sets to 0.9.8i? Is that because there is no demand for bugfix releases? There is indeed demand for real bugfix releases, just that people have gotten used to doing it themselves, but this is not very effective and is difficult to audit. OpenSSL has not infrequent security advisories, and these are always fixed in new feature releases not bugfix releases (which are misleadingly called patch releases). #define HEADER_OPENSSLV_H /* Numeric release version identifier: * MNNFFPPS: major minor fix patch status * The status nibble has one of the values 0 for development, 1 to e for betas * 1 to 14, and f for release. The patch level is exactly that. * For example: * 0.9.3-dev 0x00903000 * 0.9.3-beta10x00903001 * 0.9.3-beta2-dev 0x00903002 * 0.9.3-beta20x00903002 (same as ...beta2-dev) * 0.9.3 0x0090300f * 0.9.3a 0x0090301f * 0.9.4 0x0090400f * 1.2.3z 0x102031af * * For continuity reasons (because 0.9.5 is already out, and is coded * 0x00905100), between 0.9.5 and 0.9.6 the coding of the patch level * part is slightly different, by setting the highest bit. This means * that 0.9.5a looks like this: 0x0090581f. At 0.9.6, we can start * with 0x0090600S... * * (Prior to 0.9.3-dev a different scheme was used: 0.9.2b is 0x0922.) * (Prior to 0.9.5a beta1, a different scheme was used: MMNNFFRBB for * major minor fix final patch/beta) */ #define OPENSSL_VERSION_NUMBER 0x0090809fL -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
On Mon, Jan 19, 2009 at 10:45:55AM +0100, Bodo Moeller wrote: The RFC does exit (TLS 1.2 in RFC 5246 from August 2008 makes SHA-256 mandatory), so you can send a SHA-256 certificate to clients that indicate they support TLS 1.2 or later. You'd still need some other certificate for interoperability with clients that don't support SHA-256, of course, and you'd be sending that one to clients that do support SHA-256 but not TLS 1.2. (So you'd fall back to SHA-1, which is not really a problem when CAs make sure to use the hash algorithm in a way that doesn't rely on hash collisions being hard to find, which probably is a good idea for *any* hash algorithm.) It would be helpful if as a first step, SSL_library_init() (a.k.a. OpenSSL_add_ssl_algorithms()) enabled the SHA-2 family of digests, I would make this change in the 0.9.9 development snapshots. [ Off topic: I find OpenSSL release-engineering a rather puzzling process. The patch releases are in fact feature releases, and there are no real patch releases even for critical security issues. I chose to backport the 0.9.8j security fixes to 0.9.8i and sit out all the new FIPS code, ... This should not be necessary. I really hope to see real OpenSSL patch releases some day with development of new features *strictly* in the development snapshots. Ideally this will start with 0.9.9a, with no new features, just bugfixes, in [b-z]. ] -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
On Sat, Jan 10, 2009 at 11:32:44PM +0100, Weger, B.M.M. de wrote: Hi Victor, Bottom line, anyone fielding a SHA-2 cert today is not going to be happy with their costly pile of bits. Will this situation have changed by the end of 2010 (that's next year, by the way), when everybody who takes NIST seriously will have to switch to SHA-2? Extremely unlikely in the case of SSL/TLS and X.509 certs. There is a huge install-base of systems on which SHA-2 certs will failed SSL handshakes. When Windows XP systems are 1% of the install-base, when OpenSSL 0.9.8 is 1% of the install-base and 0.9.9 too (if the support is not added before it goes official), and all the browsers, Java libraries, ... support SHA-2, then you can deploy SHA-2 certs. I would estimate 5-8 years, if developers of all relevant mainstream implementations start to address the issue now. SHA-1 will be with us well after 2010. New applications written in 2010 will ideally support SHA-2, but SHA-1 will probably still be the default digest in many applications through 2013 or 2015. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
On Thu, Jan 08, 2009 at 06:23:47PM -0600, Dustin D. Trammell wrote: Nearly everything I've seen regarding the proposed solutions to this attack have involved migration to SHA-1. SHA-1 is scheduled to be decertified by NIST in 2010, and NIST has already recommended[1] moving away from SHA-1 to SHA-2 (256, 512, etc.). Collision attacks have already been demonstrated[2] against SHA-1 back in 2005, and if history tells us anything then things will only get worse for SHA-1 from here. By not moving directly to at least SHA-2 (until the winner of the NIST hash competition is known), these vendors are likely setting themselves up for similar attacks in the (relatively) near future. All fine and good, but no existing OpenSSL release (including 0.9.9-dev) will by default inter-operate with the resulting (SHA2) certificates. The SSL_library_init() call only initializes ssl ciphers and digests, which do not include SHA-2. So most SSL applications won't be able to verify the certificate signatures. One needs to call OpenSSL_add_all_algorithms() before SHA-2 signed certificates work. Bottom line, anyone fielding a SHA-2 cert today is not going to be happy with their costly pile of bits. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: AES HDD encryption was XOR
On Mon, Dec 08, 2008 at 08:53:18PM -0800, Jon Callas wrote: In the NBC TV episode of /Chuck/ a couple of weeks ago, the NSA cracked a 512-bit AES cipher on a flash drive trying every possible key. Could be hours, could be days. (Only minutes in TV land.) http://www.nbc.com/Chuck/video/episodes/#vid=838461 (Chuck Versus The Fat Lady, 4th segment, at 26:19) It's no wonder that folks are deluded, pop culture reinforces this. No, this is simple to do. What you is to start with a basic cracking engine. And then you add another one an hour later, and then an hour later add two, then add four the next hour and so on. If you assume that the first cracker can do 2^40 keys per second, then you're guaranteed to complete in 472 hours, which is only 20 days. And of course there's always the chance you'd do it in the first hour. For those who doubt being able to double the cracking power, Moore's law proves this is possible. In the well-known Indian fable, the King was bankrupted by doubling grains of rice on a 64-square chess-board. Back in the USSR, every school-child learned this fable. Oh, and chess was pretty popular too... The fact that the fable refutes the *sustainability* of Moore's law seems to be under-appreciated on this side of the Iron-curtain. It is not a question of whether, but rather when the departure from Moore's law will take place. The computing power of the microprocessor is still under 32 powers of 2 from its inception, naive extrapolation to the next 32 powers of 2 is unwise. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
TLS Server Name Indication and IDNA?
I am considering adding TLS Server Name Indication support in the Postfix SMTP server and client. I am puzzled by the exceedingly terse description of the semantics of the HostName sent in the SNI extension: http://tools.ietf.org/html/rfc4366#section-3.1 If the hostname labels contain only US-ASCII characters, then the client MUST ensure that labels are separated only by the byte 0x2E, representing the dot character U+002E (requirement 1 in Section 3.1 of [IDNA] notwithstanding). If the server needs to match the HostName against names that contain non-US-ASCII characters, it MUST perform the conversion operation described in Section 4 of [IDNA], treating the HostName as a query string (i.e., the AllowUnassigned flag MUST be set). Note that IDNA allows labels to be separated by any of the Unicode characters U+002E, U+3002, U+FF0E, and U+FF61; therefore, servers MUST accept any of these characters as a label separator. If the server only needs to match the HostName against names containing exclusively ASCII characters, it MUST compare ASCII names case-insensitively. At least the Postfix SMTP client does not normally work with IDNA domains directly. In queued email messages the recipient domain is already ACE encoded, e.g. [EMAIL PROTECTED]. Suppose Postfix is configured to establish a TLS secure-channel with a mail server for this domain, and now wants to signal the required certificate name to the receiving SMTP server. What should the SMTP client put in the RFC 4366 section 3.1 HostName: - The ACE domain it is working with (xn--exmple-cua.com)? - The underlying UTF8 domain name? (exämple.com)? What should the server do when it receives the client's HostName? - Convert ACE to UTF8? - Convert UTF8 to ACE? When searching for certificates with matching domain names, the receiving server may need to look at: http://tools.ietf.org/html/rfc5280#section-7.1: subject CommonName rDNs, which may contain UTF8 strings http://tools.ietf.org/html/rfc5280#section-7.2: subject Alternative Name v3 extensions which contain IA5 (ASCII) domain names. What type of comparison is the server expected to perform? - Convert UTF8 CommanName to ACE (also leave IA5 alone) and then compare? - Convert ACE names in either subjectAltName or CN to UTF8 and then compare UTF8 strings (with NAMEPREP, STRINGPREP and all that jazz)? This can be (to say the least) rather unpleasant. If IDNA is only between the user and the UI, with everything on the wire in ACE form, then all the pain is avoided: - 4366 client sends ACE - 4366 server uses received string uninterpreted - Certificates contain ACE names in subjectAltName AND also in the CommonName where the name in question is a domain name. - Server just does case insensitive search on ASCII strings. If instead, client and server have to jump through hoops doing (tersely specified, and unlikely IMHO to inter-operate) IDNA conversions, then I may just bag the whole idea and do something more useful. Anyone have any insight on what implementations are supposed to do? -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RSA modulus record
On Tue, Sep 16, 2008 at 09:01:51PM +0200, Weger, B.M.M. de wrote: There's a new biggest known RSA modulus. It is (in hexadecimal notation): FF...(total of 9289166 F's)...FFDFF...(total of 1488985 F's)...FF800...(total of 9289165 0's)...001 It is guaranteed to be the product of two different large primes, Are the primes actually known, or just guaranteed to exist? and it has more than 80 million bits. Impressive security... In what sense is this impressive security? - Impressive 10 MB wide RSA signatures? - Impressively long time on super-computers to verify said signatures - Impressively few potential users, with at most one known key pair? This is likely real progress in computational number theory, but it is not clear how it is an advance in security. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Looking through a modulo operation
On Sun, Jul 20, 2008 at 04:14:33PM -0600, Matt Ball wrote:
From a little bit of off-line discussion, I think I've got a restatement of
the problem that is more suitable to those with a stronger programming
background than mathematical background:
If someone uses the __random32 function as defined in the 2.6.26 Linux
kernel, and leaks to you the result of taking successive outputs modulo
28233 (= 9 * 3137), can you determine the probable 96-bit internal state
with fewer than 1000 outputs and with modest processing power (e.g., a
laptop computer running less than a day)?
Here is a C implementation of __random32:
typedef unsigned long u32;
struct rnd_state { u32 s1, s2, s3; };
static u32 __random32(struct rnd_state *state)
{
#define TAUSWORTHE(s,a,b,c,d) ((sc)d) ^ (((s a) ^ s)b)
state-s1 = TAUSWORTHE(state-s1, 13, 19, 4294967294UL, 12);
state-s2 = TAUSWORTHE(state-s2, 2, 25, 4294967288UL, 4);
state-s3 = TAUSWORTHE(state-s3, 3, 11, 4294967280UL, 17);
return (state-s1 ^ state-s2 ^ state-s3);
}
After any consecutive 96 outputs, the 97th is a fixed linear function of
those just observed. It is not necessary to determine the internal state.
The internal state is s_n = (A**n)(s_0) for a fixed 96x96 matrix A (the
fact that it is a direct product of 3 32-bit matrices is not important).
This matrix has a minimum polynomial of degree at most 96.
A**96 = c_95 * A**95 + c_94 * A**94 ... + c_0 * I
The 32-bit output then also satisfies:
x_96 = c_95 * x_95 + c_94 * x_94 ... + c_0
for the same coefficients.
--
/\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privilege,
and use is prohibited.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Looking through a modulo operation
On Mon, Jul 21, 2008 at 12:03:50PM -0400, Victor Duchovni wrote: On Sun, Jul 20, 2008 at 04:14:33PM -0600, Matt Ball wrote: From a little bit of off-line discussion, I think I've got a restatement of the problem that is more suitable to those with a stronger programming background than mathematical background: If someone uses the __random32 function as defined in the 2.6.26 Linux kernel, and leaks to you the result of taking successive outputs modulo 28233 (= 9 * 3137), can you determine the probable 96-bit internal state with fewer than 1000 outputs and with modest processing power (e.g., a laptop computer running less than a day)? I skipped over this part when reading the original message. Expecting per Florian's original message the outputs to be a linear function of the inputs, but they are not. After any consecutive 96 outputs, the 97th is a fixed linear function of those just observed. It is not necessary to determine the internal state. This of course applies to the 32-bit output of the RNG. The operation of reducing the 32-bit output modulo 28333, is not linear (over the F_2 bit string vector-space). While: x_96 = c_95 * x_95 + ... c_0 * x_0 this is only true bitwise modulo 2. It is not obvious how one might recover the full 32-bit outputs from the truncated outputs. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
On Wed, Jul 09, 2008 at 08:20:33AM -0700, Paul Hoffman wrote: First off, big props to Dan for getting this problem fixed in a responsible manner. If there were widespread real attacks first, it would take forever to get fixes out into the field. However, we in the security circles don't need to spread the Kaminsky finds meme. Take a look at http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/. The first draft of this openly-published document was in January 2007. It is now in WG last call. The take-away here is not that Dan didn't discover the problem, but Dan got it fixed. An alternate take-away is that IETF BCPs don't make nearly as much difference as a diligent security expert with a good name. The discovery is almost certainly a generalization of: http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience-05#section-4.3 specifically the second paragraph the mentions the Birthday Attack. The assumptions of that paragraph can be relaxed in a natural way to broaden the scope of the attack. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Permanent Privacy - Snake Oil or unbreakable encryption?
On Mon, Jul 07, 2008 at 07:54:46AM -0700, Ali, Saqib wrote: PermanentPrivacy announces the world's first practical data encryption system that is absolutely unbreakable. And is offering a $1,000,000 challenge to anyone who can crack it. This reads like snake oil. http://www.foxbusiness.com/story/hackers-hell-privacy-compromised/ This reads like a pump'n'dump stock scam. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Secure voice?
On Fri, Jul 04, 2008 at 04:04:11PM -0700, Allen wrote: Interesting tidbit: http://www.epaynews.com/index.cgi?survey=ref=browsef=viewid=121516308313743148197block= Nick Ogden, a Briton who launched one of the world's first e-commerce processors in 1994, has developed a system for voice-signed financial transactions. The Voice Transact platform was developed by Ogden's Voice Commerce Group in partnership with U.S. speech software firm Nuance Communications. Move along, yet another voice biometric system... -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Protection mail at rest
On Tue, Jun 03, 2008 at 04:37:20PM -0400, Eric Cronin wrote: On Jun 3, 2008, at 11:51 AM, Adam Aviv wrote: Depending on the level of protection you want, you could just add a script to your .forward to encrypt your email before delivery using PGP/GPG. However, this will leave the headers in the clear, so you will likely want to create an entirely new envelope for the message with the original message encrypted as the body or an attachment. Does anybody have a recipe for this first mode handy? plain text e- mails seem simple enough, but there needs to be a bit of MIME unwrapping and rewrapping to correctly handle attachments so that the client sees/decrypts them correctly I think. I've searched from time to time and never found a good HowTo... S/MIME supports enveloped MIME objects, if PGP does not work out for MIME entities, you could try that. S/MIME is natively supported in Thunderbird, Apple Mail, and similar MUAs. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Protection mail at rest
On Fri, May 30, 2008 at 03:04:34PM -0400, Leichter, Jerry wrote: 1. Client only. The client, whenever it sees a new message, (a) downloads it; (b) encrypts it using a secret key; (c) stores the encrypted version back on the server; (d) deletes the unencrypted version. The client can put the encrypted messages in a different folder, or it can mark them with a header line. 2. Server-assisted. The client gives the server its public key. When a message arrives at the server, the server (a) generates a session key; (b) encrypts the message using the session key; (c) encrypts the session key with the client's public key; (d) adds a header containing the encrypted session key to the encrypted message; (e) stores the encrypted message. The necessary work for the client is obvious. 3. The server that stores your mail is not the first one to receive it. It is just the storage layer. A previous non-storing server, encrypts the mail and *then* forwards it to the store. In each case, one would probably chose some headers to encrypt separately - e.g., the subject - so that one could more easily pull them out without decrypting the whole message. S/MIME does not encrypt any headers. It only encrypts the payload. Some S/MIME applications don't leave any useful headers in the outer message, others leave the sender and subject in the clear. Does anyone know of existing work in this area? Take PGP Universal gateway and turn-it inside-out. Clear mail on the Internal encrypted mail on the intranet between the gateway and the mail store. Take a vanity domain, run an encryption gateway, forward everything to to an ESP. The ESP's search engine will not do you much good with encrypted mail, so indexing is up to your IMAP client, if it can cache/index decrypted content. Not much demand for this yet, so I don't expect mature offerings any time soon. We'd have to build a boutique service for cipher-punks. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RIM to give in to GAK in India
On Fri, May 30, 2008 at 02:58:15PM -0400, Arshad Noor wrote: So, what is it on the device that is using the 3DES key to encrypt chunks to send to the RIM messaging gateway? Not to the RIM gateway, via the RIM gateway the payload is destined for a corporate messaging server. Something on the device has to encrypt/decrypt the data sent to/from the messaging server? Doesn't that constitute a session even if the 3DES keys are rotated frequently? (And, if they are, how are the 3DES keys agreed upon? Doesn't that imply public/private key-pairs or a master-key?) Presumably the device has a KEK, and generates a session key for each message, encrypting that under the KEK. The KEK is used for a long time (~90 days) and periodically renegotiated. I don't recall how the KEK is agreed to. Perhaps there is PKI involved in that step, or it could just negotiate the new KEK using the current KEK. There is not in practice any need for a PKI in this context, it looks rather a lot more like Kerberos than PKI. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RIM to give in to GAK in India
On Thu, May 29, 2008 at 10:05:17AM -0400, Derek Atkins wrote: Arshad Noor [EMAIL PROTECTED] writes: Even if RIM does not have the device keys, in order to share encrypted data with applications on the RIM server, the device must share a session key with the server; must it not?. Isn't RIM (their software, actually) now in a position to decrypt content sent between Blackberry users? Or, does the Blackberry encryption protocol work like S/MIME? The enterprise solution does work something like S/MIME. The keys are symmetric 3DES, and encrypt message chunks (IIRC either 256 or 1K bytes) sent asynchronously to the enterprise messaging gateway. RIM does not have a secure session with the device. This is not like S/MIME except that as with S/MIME, this is not hop-by-hop encryption. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RIM to give in to GAK in India
On Tue, May 27, 2008 at 08:08:11PM +0100, Dave Korn wrote: Well spotted. Yes, I guess that's what Jim Youll was asking. And I should have said seemingly-contradictory. This is, of course, what I meant by marketeering: when someone asks if your service is insecure and interceptable, you don't say Yes, our ordinary service will give you up to the filth at the drop of a hat, you spin it as No, our enterprise service is completely secure [...other details elided...]. But this is not news. It is well known (at least among the Enterprise Remote Computing wonks) that only the Enterprise RIM service provides end-to-end security, while the consumer service does not. There is nothing new here. It is not even marketing spin, without your IT shop hosting your content, it is hosted by providers subject to CALEA, ... The good news about RIM is that it has been one of the few devices that actually provides end-to-end security for Enterprises. This has been a selling point that helped get them a large share of the Enterprise market. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The perils of security tools
On Tue, May 13, 2008 at 02:10:45PM +0100, Ben Laurie wrote:
[Moderator's note: A quick reminder: please use ASCII except if you
need Unicode to spell your name right. Microsoft's proprietary quote
marks are not a standard and don't look right on non-Microsoft
displays. I edited them out of this by hand. --Perry]
Debian have a stunning example of how blindly fixing problems pointed
out by security tools can be disastrous.
Upstream authors can take defensive measures against ill-advised
patches of this sort. For a while, distributions were in the habit
of Patching the code that Postfix uses to learn the its own hostname.
Invariably, they botched it. The code now reads:
/* get_hostname - look up my host name */
const char *get_hostname(void)
{
charnamebuf[MAXHOSTNAMELEN + 1];
/*
* The gethostname() call is not (or not yet) in ANSI or POSIX, but it is
* part of the socket interface library. We avoid the more politically-
* correct uname() routine because that has no portable way of dealing
* with long (FQDN) hostnames.
*
* DO NOT CALL GETHOSTBYNAME FROM THIS FUNCTION. IT BREAKS MAILDIR DELIVERY
* AND OTHER THINGS WHEN THE MACHINE NAME IS NOT FOUND IN /ETC/HOSTS OR
* CAUSES PROCESSES TO HANG WHEN THE NETWORK IS DISCONNECTED.
*
* POSTFIX NO LONGER NEEDS A FULLY QUALIFIED HOSTNAME. INSTEAD POSTFIX WILL
* USE A DEFAULT DOMAIN NAME LOCALDOMAIN.
*/
if (my_host_name == 0) {
/* DO NOT CALL GETHOSTBYNAME FROM THIS FUNCTION */
if (gethostname(namebuf, sizeof(namebuf)) 0)
msg_fatal(gethostname: %m);
namebuf[MAXHOSTNAMELEN] = 0;
/* DO NOT CALL GETHOSTBYNAME FROM THIS FUNCTION */
if (valid_hostname(namebuf, DO_GRIPE) == 0)
msg_fatal(unable to use my own hostname);
/* DO NOT CALL GETHOSTBYNAME FROM THIS FUNCTION */
my_host_name = mystrdup(namebuf);
}
return (my_host_name);
}
The addition of /* DO NOT CALL GETHOSTBYNAME FROM THIS FUNCTION */
every couple of lines appears to have solved the problem: it deliberately
breaks all prior patches (context diff overlaps), and strongly signals
that the code must not be messed with.
--
Viktor.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
On Wed, May 07, 2008 at 10:27:48AM +1000, James A. Donald wrote: Dynamic strings tempt people to forget about enforcing length limits and forget about correctly handling the case when the length limits are exceeded. This too is dealt with. Message sizes are bounded, recipient counts are bounded, duplicate elimination cache sizes are bounded, command lengths are bounded, logical header lengths are bounded, body content is processed 2K bytes at a time... The requirement is stronger than just not running a single process out of memory, the entire multi-process Postfix is designed to run in (realistic) bounded memory (no fork: out of memory). -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
On Sun, May 04, 2008 at 10:24:13PM -0400, Thor Lancelot Simon wrote: I believe that those who supply security products have a responsibility to consider the knowledge, experience, and tendencies of their likely users to the greatest extent to which they're able, and supply products which will function properly _as users are likely to apply them_. The TLS support in Postfix tries to behave sensibly with easy setings. - Cipher list selection is indirect, via grades: export, low, medium and high. The actual ciphers for each grade are buried in parameters users are advised to not mess with. - The cipher grade for opportunistic TLS is export, but you single out a destination for mandatory TLS, the grade rises to medium. - The secure peer cert validation level compares the peer's cert to the nexthop domain (allowing a sub-domain match by default). Hostnames derived from MX lookups are of course subject to DNS MITM and are not trusted. If you want to trust your DNS you can use verify instead. http://www.postfix.org/TLS_README.html#client_tls_limits http://www.postfix.org/TLS_README.html#client_tls_may http://www.postfix.org/TLS_README.html#client_tls_encrypt http://www.postfix.org/TLS_README.html#client_tls_verify http://www.postfix.org/TLS_README.html#client_tls_secure - With the upcoming EECDH support, users don't choose curves directly, they again choose a security grade, and the correspnding curves are configurable via parameters they are not expected to ever look at or modify. If you don't botch your CAfile, it is rather easy to provision secure-channel connections to a select set of high-value peers. If you don't trust any CAs: http://www.postfix.org/TLS_README.html#client_tls_fingerprint once you have a system designed in all its features to behave sensibly by default (e.g. with an empty main.cf file), making security behave sensibly by default is not that unnatural. So I think there should be a broad design bias towards *implicit* correct behaviour in all system features, with rope available for advanced users to *explicitly* craft more complex use-cases. Once you have that, practical security is not too difficult. The same is true in the source code, unsafe practices are avoided globally, (e.g. both strcpy() and strncpy() are absent together with fixed size automatic buffers) rather than used with care locally. I won't bore you with all the implementation safety habits, but there are many. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
On Tue, May 06, 2008 at 11:40:53AM -0700, David Wagner wrote: - With the upcoming EECDH support, users don't choose curves directly, they again choose a security grade, and the correspnding curves are configurable via parameters they are not expected to ever look at or modify. This struck me as poor design, not good design. Asking the user to make these kinds of choices seems like the kind of thing that only a cryptographer could consider sensible. They are not *asked* to make any cipher choices. The are able to make: - no explicit choice, and get sensible default behaviour - a high level choice (secure verification + high grade cipher without having to spell out the gory details of what these mean. - an exteremely detailed specification of all the details. In this day and age, software should not be asking users to choose ciphers. The users in question are email administrators, not end users, and you missed my point. They are not asked to choose ciphers, these are chosen for them, and the default choice is even context dependent, so you get sensible combinations of security properties: - Opportunistic TLS allows SSLv2 and export ciphers - Mandatory TLS, enforces SSLv3/TLSv1 and medium or high ciphers. Rather, the software should just pick a sensible high-grade security level (e.g., AES-128, RSA-1024 or RSA-2048) and go with that This is what is done (using OpenSSL's HIGH, MEDIUM, ... selectors). and avoid bothering the user. Why even offer low as an option? (And this export business sounds like a throwback to a decade ago; why is that still there?) You don't know how TLS is used with SMTP. Most TLS is opportunistic and plain text is used if TLS is absent. In such an environment insisting on 128 bits is silly, even 40 bits is better than plain-text. Good crypto is cheap. Asking a user is expensive and risky. Breaking interoperability by limiting cipher selection and causing mail to queue is not cheap. So I think there should be a broad design bias towards *implicit* correct behaviour in all system features, with rope available for advanced users to *explicitly* craft more complex use-cases. Once you have that, practical security is not too difficult. Amen. I know of quite a few software packages that could use more of that philosophy. The same is true in the source code, unsafe practices are avoided globally, (e.g. both strcpy() and strncpy() are absent together with fixed size automatic buffers) rather than used with care locally. I won't bore you with all the implementation safety habits, but there are many. It's too bad that today such elementary practices are something to brag about. Perhaps one day we'll be lucky enough that the answer to these questions becomes more like of course we use safe programming practices; what kind of incompetent amateurs do you take us for?. Practices are culture not technology, and it is difficult to displace existing cultures with new ones :-( -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL and Malicious Hardware/Software
On Mon, Apr 28, 2008 at 03:12:31PM -0700, Ryan Phillips wrote: What are people's opinions on corporations using this tactic? I can't think of a great way of alerting the user, but I would expect a pretty reasonable level of privacy while using an SSL connection at work. Expectations of privacy at work vary by jurisdiction and industry. In the US, and say in the financial services industry, any such expectations are groundless (IANAL). -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cruising the stacks and finding stuff
On Fri, Apr 18, 2008 at 08:02:28PM -0700, Allen wrote: Granted A5/1 is known to be very weak, but how much weaker than AES-128? Ten orders of magnitude? I haven't a clue ... This is usually the point where I stop reading. Of course 10 orders of magnitude is ~33 bits, so unless the A5 attacks crack a cipher with ~95 bits security, the estimate is grossly wrong. If (generously) A5 is 64 bits of work, AES is ~20 orders of magnitude stronger. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how to read information from RFID equipped credit cards
On Tue, Apr 01, 2008 at 12:47:45AM +1300, Peter Gutmann wrote: Actually there are already companies doing something like this Which ones do you think are doing a decent job of this? but they've run into a problem that no-one has ever considered so far: The GTCYM needs a (relatively) high-bandwidth connection to a remote server, and there's no easy way to do this. (Hint: You can't use anything involving USB because many corporates lock down USB ports to prevent data leaking onto other corporates' networks, or conversely to prevent other corporates' data leaking onto their networks. Same for Ethernet, Firewire, ...). Lock USB down completely, or block most devices and allow approved ones? There is a non-empty set folks doing the latter, which opens the possibility of this type of device being permitted, while others are restricted. Since *all* it needs is the ability to call home to its server, and register to send/receive messages, it will not look like mass-storage, and should not look like a network interface. Data leakage should not be a concern if the device is built/marketted correctly. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [p2p-hackers] convergent encryption reconsidered
On Sun, Mar 30, 2008 at 05:13:07PM -0400, Ivan Krsti?? wrote: That's a brute force search. If your convergence key, instead of being a simple file hash, is obtained through a deterministic but computationally expensive function such as PBKDF2 (or the OpenBSD bcrypt, etc), then step 3 makes an exhaustive search prohibitive in most cases while not interfering with normal filesystem operation. What am I missing? PBKDFS2 is excellent for turning interactively typed pass-phrases into keys. It is not entirely clear that it is a good fit for a filesystem. Updating any single file is now a computationally intensive process, the performance impact may be unacceptable. With PBKDF2 and the iteration count set to the for now popular 1000, a 64K byte file will now trigger ~~2 million sha1 compression function computations (if I remember the sha1 block size correctly as 512 bits or 64 bytes). A crude cost estimate on typical hardware (openssl speed): Doing sha1 for 3s on 8192 size blocks: 57316 sha1's in 3.00s Extrapolating from this, on 64K sized files, we get ~1200 HMAC operations per second. If we iterate that 1000 times, 1.2 key derivations per second. The throughput to disk is CPU bound at ~64KB/s, which is rather poor. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
On Thu, Feb 07, 2008 at 08:47:20PM +1300, Peter Gutmann wrote: Victor Duchovni [EMAIL PROTECTED] writes: While Firefox should ideally be developing and testing PSK now, without stable libraries to use in servers and browsers, we can't yet expect anything to be released. Is that the FF devlopers' reason for holding back? Just wondering... why not release it with TLS-PSK/SRP anyway (particularly with 3.0 being in the beta stage, it'd be the perfect time to test new features), tested against existing implementations, then at least it's ready for when server support appears. At the moment we seem to be in a catch-22, servers don't support it because browsers don't, and browsers don't support it because servers don't. I don't have any idea why or why not, but all they can release now is source code with #ifdef openssl = 0.9.9 ... do PSK stuff ... #endif, with binaries (dynamically) linked against the default OpenSSL on the oldest supported release of each platform... For RedHat 4.x systems, for example, that means that binary packages use 0.9.7... Distributions that build their own Firefox from source may at some point have PSK (once they ship OpenSSL 0.9.9). I don't think we will see this available in many user's hands for 2-3 years after the code is written (fielding new systems to the masses takes a long time...). -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
On Sat, Feb 09, 2008 at 05:04:28PM -0800, David Wagner wrote: By the way, it seems like one thing that might help with client certs is if they were treated a bit like cookies. Today, a website can set a cookie in your browser, and that cookie will be returned every time you later visit that website. This all happens automatically. Imagine if a website could instruct your browser to transparently generate a public/private keypair for use with that website only and send the public key to that website. Then, any time that the user returns to that website, the browser would automatically use that private key to authenticate itself. For instance, boa.com might instruct my browser to create one private key for use with *.boa.com; later, citibank.com could instruct my browser to create a private key for use with *.citibank.com. Microsoft broke this in IE7... It is no longer possible to generate and enroll a client cert from a CA not on the trusted root list. So private label CAs can no longer enroll client certs. We have requested a fix, so this may come in the future, but the damage is already done... Also the IE7 browser APIs for this are completely different and rather minimally documented. The interfaces are not portable between browsers, ... It's a mess. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
On Wed, Feb 06, 2008 at 09:21:47AM -0800, Frank Siebenlist wrote: With the big browser war still going strong, wouldn't that provide fantastic marketing opportunities for Firefox? If Firefox would support these secure password protocols, and the banks would openly recommend their customers to use Firefox because its safer and protects them better from phishing, that would be great publicity for Firefox, draw more users, and force M$ to support it too in the long run... It is a bit early. OpenSSL 0.9.9 is not yet released. I wish OpenSSL releases were more frequent, and each added fewer features, allowing features to be released as they mature, this would also reduce pressure to add features to stable releases (which occasionally break binary compatibility, and lead to vendors back-porting fixes rather than deploying the next patch level of the stable release). While Firefox should ideally be developing and testing PSK now, without stable libraries to use in servers and browsers, we can't yet expect anything to be released. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
On Wed, Jan 30, 2008 at 06:08:37PM -, Dave Korn wrote: On 30 January 2008 17:01, Jim Cheesman wrote: James A. Donald: SSL is layered on top of TCP, and then one layers one's actual protocol on top of SSL, with the result that a transaction involves a painfully large number of round trips. Jumping in late, but the idea that *TCP* (and not TLS protocol design) adds round-trips to SSL warrants some evidence (it is very temping to express this skepticism more bluntly). With unextended SMTP for example, the minimum RTT count is: 0. SYN SYN-ACK 1. ACK 220 2. HELO 250 3. MAIL 250 4. RCPT 250 ... n recipients RCPT 250 4+n DATA 354 5+n ... stream of message content segments CRLF.CRLF 250 so it takes at least 6 RTTs to perform a delivery (of a short single-recipient message), but only 1 of the 6 RTTs is TCP overhead. This is improved with PIPELINING: 0. SYN SYN-ACK 1. ACK 220 2. EHLO 250 ... PIPELINING ... 3. MAIL RCPT(n times) DATA 250 250 (n times) 354 4. ... stream of message content segments CRLF.CRLF 250 Here the application protocol is pipelined, and 5+n RTTs becomes 4 RTTs. The solution is not replacing TCP, but reducing the number of lock-step interactions in the application protocol. If someone has a faster than 3-way handshake connection establishment protocol that SSL could leverage instead of TCP, please explain the design. The TCP handshake adds a 1-RTT delay at the start of the connection. What 0-RTT algorithm will allow the server to delay creating expensive connections to clients until the client acks the server response or discover the MSS before sending the first segment? With TCP, at least SYN floods require unspoofed client IPs. Most of the application protocols we wrap in TLS are not DNS. Sure if you can guarantee a single packet response to a single packet request, TCP is not the answer. Otherwise, claiming that SSL is less efficient over TCP smacks of arrogance. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
On Thu, Jan 31, 2008 at 02:28:30PM -0500, Anne Lynn Wheeler wrote: TCP requires minimum of seven message exchange for reliable transport VMTP (rfc 1045) got that down to minimum of five messages, and XTP then got it down to three messages minimum for reliable transport (disclaimer we were on the XTP technical advisory board). SMTP does not need TCP to provide reliability for the tail of the session, the application-level . (end-of-data) and server 250 response complete a transaction, everything after that is optional, so for example Postfix will send (when PIPELINING). DATA CRLF 354 Go ahead Message-Content Lots of acks .CRLFQUITCRLF 250 Ok and will disconnect after reading the 250 response without waiting for the 221 response. The TCP 3-way shutdown (FIN, FIN-ACK, ACK) happens in the kernel in the background, the SMTP server and client are by that point handling different connections. So the reliable shutdown latency is of no consequence for application throughput. A pipelined SMTP delivery can be completed over TCP in 5 RTTs not 7. 0. SYN SYN-ACK 1. ACK 220 2. EHLO 250 3. MAIL RCPT DATA 250 250 354 4. MSG . QUIT 250 221 5. close socket TCP is fine, latency is primarily the result of application protocol details, not TCP overhead. The only TCP overhead above is 1 extra RTT for the connection setup. Everything else is SMTP not TCP, and running SMTP over UDP (with ideal conditions and no lost packets, ...) would save just 1 RTT. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL/TLS and port 587
On Tue, Jan 22, 2008 at 10:38:24AM -0800, Ed Gerck wrote: List, I would like to address and request comments on the use of SSL/TLS and port 587 for email security. The often expressed idea that SSL/TLS and port 587 are somehow able to prevent warrantless wiretapping and so on, or protect any private communications, is IMO simply not supported by facts. Nothing of the sort, TLS on port 587 protects replayable *authentication* mechanisms, suchs as PLAIN and LOGIN. It can also allow the client to authenticate the server (X.509v3 cert) and preclude MITM attacks on mail submission. I've not seen any reputable parties claiming that TLS submission is protection against intercepts. I maintain the TLS code for Postfix, the documentation does not anywhere make such claims. However we do support TLS sensitive SASL mechanism selection: http://www.postfix.org/postconf.5.html#smtpd_tls_auth_only http://www.postfix.org/postconf.5.html#smtp_sasl_tls_security_options which is highly suggestive of using TLS to protect plain-text passwords in flight. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto class design
On Mon, Dec 17, 2007 at 10:38:59AM -0600, [EMAIL PROTECTED] wrote:
So... supposing I was going to design a crypto library for use within
a financial organization, which mostly deals with credit card numbers
and bank accounts, and wanted to create an API for use by developers,
does anyone have any advice on it?
It doesn't have to be terribly complete, but it does have to be
relatively easy to use correctly (i.e. securely).
APIs don't solve security problems, just code re-use problems. Teaching
smart people how to do threat analysis is a better bet. Untrained
developers will choose an API that solves the wrong problem.
class crypto_api
{
...
// developers call these based on what they're trying to do
// these routines simply call crypto_logic layer
Buffer encrypt_credit_card(Buffer credit_card_number, key_t key);
Buffer encrypt_bank_account(Buffer bank_account, key_t key);
Buffer encrypt_other(Buffer buffer, key_t key);
And who does key management? I bet the key will be right there with
the data on the same disk, probably logged in the clear in application
logs too...
The general idea is that crypto_api provides domain-specific APIs that
are easy for anyone to understand, that the logic layer allows for the
selection of different algorithms, and the glue layer is basically a
translation layer to underlying libraries.
Encryption is almost never the problem, design is the problem, with a
good design, the crypto is already available.
Comments?
Why yet another crypto library? Invest your energy in complete designs and
code of realistic show-case solutions to real-world problems, not APIs.
Good designs will get copied whole-sale, and morphed. If well documented,
the developers can learn by reading the sample code, and training can
be based around the approaches taken in the show-case systems.
When I hear developers demanding security APIs I pretend to be deaf...
--
/\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privilege,
and use is prohibited.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
On Wed, Sep 19, 2007 at 02:01:13PM -0700, Nash Foster wrote: http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/ Any actual cryptographers care to comment on this? I don't feel qualified to judge. I am not a cryptographer, but the article appears silly. First the verification algorithm as stated is wrong: * Verify that 2 = K_a = p - 2 * Verify that (K_a)^g = 1 (mod p) The first condition is correct, but the second is not, that g should be a q, where q is a large prime divisor of p-1 and g is chosen so that the order of g mod p is q. The correct second test just verifies that K_a is an element of order q (true for all non-trivial powers of g). Even with the verification algorithm K_a can still be equal to a small power of g, which the passive eavesdropper can quickly brute-force. In fact the entire threat model is broken, because if Alice wants Eve to be able to crack Alice's key exchange with Bob, Alice can just send Eve her secret exponent. Why waste time with weak exponents that Bob may be able to detect if he so choses? So verification of the peer exponent has nothing to do with Allice colluding with passive eavesdroppers. Rather the issue is small-subgroup attacks, which are of interest in some cases (and not applicable in others). http://tools.ietf.org/html/rfc2785 Have not looked at IKE closely enough to comment on whether small subgroups are a concern in that context. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Neal Koblitz critiques modern cryptography.
On Sat, Sep 01, 2007 at 12:35:33PM -0400, Perry E. Metzger wrote: A critique of modern cryptography by Neal Koblitz in Notices of the AMS: http://www.ams.org/notices/200708/tx070800972p.pdf The way I read it, it is a critique of the (somewhat inevitable) poor quality of peer-review for conference proceedings, and the author is indirectly complaining that more traditional journals are not always the norm for crypto research that sets best-practice standards. In a nutshell: important ideas deserve time, rather than Internet-time. This part is not too radical. The more specific scepticism of security proofs (I am reluctant to agree that these are actively harmful), seems to be a combination of the peer review issue above, and (often?) lack of tight bounds that make the proofs applicable to realistic parameter sizes. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
On Mon, Jun 25, 2007 at 08:23:14PM -0400, Greg Troxel wrote: 1) Do you believe the physics? (Most people who know physics seem to.) Yes. 2) Does the equipment in your lab correspond to the idealized models with which the proofs for (1) were done. (Not even close.) Does QKD address a real-world risk at a reasonable cost without unreasonable application constraints? If I am very concerned about PFS for secrets that must stay secure for decades and 521-bit ECDH is broken, yes I lose PFS. So there may be a market for fixed direct circuits used by a small number of agencies, but if I were a budget director I would spend the money elsewhere... I am most curious as to the legal issue that came up regarding QKD. Indeed, what was the legal question that got us here? -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
On Thu, Jun 21, 2007 at 10:59:14AM -0700, Ali, Saqib wrote: - Quantum Cryptography is fiction (strictly claims that it solves an applied problem are fiction, indisputably interesting Physics). Well that is a broad (and maybe unfair) statement. Quantum Key Distribution (QKD) solves an applied problem of secure key distribution. It may not be able to ensure unconditional secrecy during key exchange, but it can detect any eavesdropping. Once eavesdropping is detected, the key can be discarded. Secure in what sense? Did I miss reading about the part of QKD that addresses MITM (just as plausible IMHO with fixed circuits as passive eavesdropping)? Once QKD is augmented with authentication to address MITM, the Q seems entirely irrelevant. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
On Fri, Jun 22, 2007 at 11:33:38AM -0400, Leichter, Jerry wrote: | Secure in what sense? Did I miss reading about the part of QKD that | addresses MITM (just as plausible IMHO with fixed circuits as passive | eavesdropping)? | | Once QKD is augmented with authentication to address MITM, the Q | seems entirely irrelevant. The unique thing the Q provides is the ability to detect eaves- dropping. If I want to encrypt a fixed circuit, I assume that eavesdropping is omni-present, and furthermore don't want to be constrained to transmit only when the eavesdroppers have chosen to take a lunch break. One can argue about what this adds. Warm fuzzies? The current approach of the QKD efforts is to assume that physical constraints are sufficient to block MITM. An interesting assumption. It does move the center of the problem, however - and into a region (physical protection) in which there is much more experience and perhaps some better intuition. I would conjecture that a lot more people grasp undergraduate mathematics than undergraduate quantum mechanics... Valid or not, it certainly is easier to give people the warm fuzzies by talking about physical protection than by talking about math Warm fuzzies is not in conflict with fiction. In the other direction, whether the ability to detect eavesdropping lets you do anything interesting is, I think, an open question. I wouldn't dismiss it out of hand. There's an old paper that posits related primitive, Verify Once Memory: Present it with a set of bits, and it answers either Yes, that's the value stored in me or No, wrong value. Suppose I install a fake subway entrace, and MITM all the interactions between the victim's card and the real turnstile where I have a card that proxies the victims interactions with the fake terminal. Is the system still secure? Likely not, I would bet The threat model was card forgery, not MITM. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
On Fri, Jun 22, 2007 at 10:44:41AM -0700, Ali, Saqib wrote: Paul: Here you are assuming that key exchange has already taken place. But key exchange is the toughest part. That is where Quantum Key Distribution QKD comes in the picture. Once the keys are exchanged using QKD, you have to rely on conventional cryptography to do bulk encryption using symmetric crypto. QKD fails to come into the picture, because its key exchange is unauthenticated. I can do secure unauthenticated key exchange at zero cost using EECDH with no special quantum hardware. If the link is MITM-proof, I am done. Using Quantum Crypto to do bulk encryption doesn't make any sense. It is only useful in key distribution. What bulk-encryption system am I going to use that is usefully stronger than EECDH over secp384r1 (or tinfoil hat secp521r1). It is also not useful for key distribution. It remains (charitably) fiction. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Blackberries insecure?
On Wed, Jun 20, 2007 at 11:41:20PM -0400, Steven M. Bellovin wrote: According to the AP (which is quoting Le Monde), French government defense experts have advised officials in France's corridors of power to stop using BlackBerry, reportedly to avoid snooping by U.S. intelligence agencies. That's a bit puzzling. My understanding is that email is encrypted from the organization's (Exchange?) server to the receiving Blackberry, and that it's not in the clear while in transit or on RIM's servers. In fact, I found this text on Blackberry's site: The key issue is who manages the (not necessarily, but often Exchange) mail store. Enterprise BlackBerry devices should be safe from external attacks, consumer BlackBerry devices use servers provisioned elsewhere. Are the officials using Corporate or Personal BlackBerry devices? -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: wrt Network Endpoint Assessment
On Thu, Jun 21, 2007 at 04:32:50PM +0300, Alexander Klimov wrote: Hi. On Wed, 20 Jun 2007 [EMAIL PROTECTED] wrote: Network Endpoint Assessment (NEA): Overview and Requirements http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-02.txt [...] NEA technology may be used for several purposes. One use is to facilitate endpoint compliance checking against an organization's security policy when an endpoint connects to the network. Organizations often require endpoints to run an IT- specified OS configuration and have certain security applications enabled, e.g. anti-virus software, host intrusion detection/prevention systems, personal firewalls, and patch management software. An endpoint that is not compliant with IT policy may be vulnerable to a number of known threats that might exist on the network. I wonder what stops a trojan to disable an antivirus, but screw the reporting system up so that it pretends that the antivirus is still active? Nothing, the technology is not sufficient, merely necessary... -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
On Tue, Jun 19, 2007 at 09:10:12PM -0700, Aram Perez wrote: On a legal mailing list I'm on there is a bunch of emails on the perceived effects of quantum cryptography. Is there any authoritative literature/links that can help clear the confusion? Quantum Cryptography or Quantum Computing (i.e. cryptanysis)? - Quantum Cryptography is fiction (strictly claims that it solves an applied problem are fiction, indisputably interesting Physics). - Quantum Computing is science fiction. Some science fiction eventually becomes reality. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
On Wed, May 23, 2007 at 06:34:26PM +0200, Florian Weimer wrote: * Victor Duchovni: That's good of you not to expect it, given that zero of the major CAs seem to support ECC certs today, and even if they did, those certs would not work in IE on XP. We are not talking about this year or next of course. My estimate is that Postfix releases designed this year, ship next year, are picked up by some O/S vendors the year after and shipped perhaps a year after that, then customers take a few years to upgrade, ... So for some users Postfix 2.5 will be their MTA upgrade in 2011 or later. So we need to anticipate future demand by a few years to be current at the time that users begin to use the software. But no one is issuing certificates which are suitable for use with SMTP (in the sense that the CA provides a security benefit). As far as I know, there isn't even a way to store mail routing information in X.509 certificates. There is no need to store routing information: http://www.postfix.org/TLS_README.html#client_tls_limits http://www.postfix.org/TLS_README.html#client_tls_levels http://www.postfix.org/TLS_README.html#client_tls_verify http://www.postfix.org/TLS_README.html#client_tls_secure The short summary is that full security is only available when the receiving MX hosts have certs that match the recipient domain, or the sender is willing to manually (in his MTA configuration) bind the recipient domain to the subject names (or in 2.5 fingerprints) of the appropriate MX hosts. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
On Mon, May 21, 2007 at 08:07:24PM -0700, Paul Hoffman wrote: The other issue is that sites will need multiple certs during any transition from RSA to ECC, because the entire Internet won't upgrade overnight. I am not expecting public CAs to cooperate by charging the same price for two certs (RSA and ECC) for the same subject name(s), this also may significantly impede migration. That's good of you not to expect it, given that zero of the major CAs seem to support ECC certs today, and even if they did, those certs would not work in IE on XP. We are not talking about this year or next of course. My estimate is that Postfix releases designed this year, ship next year, are picked up by some O/S vendors the year after and shipped perhaps a year after that, then customers take a few years to upgrade, ... So for some users Postfix 2.5 will be their MTA upgrade in 2011 or later. So we need to anticipate future demand by a few years to be current at the time that users begin to use the software. As 1024 RSA keys are not a major risk *today*, but that may be in sight, it is not unreasonable to explore the (multi-year) road to ECC adoption. There are many obstacles, it may take a long time, but I am removing the one obstacle I can remove... Initially ECC in Postfix will be used by private arrangements between sites that manually exchange keys and have no need of a public CA. Postfix, 2.5 also includes a new fingerprint security level, where the SMTP client verifies the server certificate by its md5, sha1, or SHA256/384/512 fingerprint. (No support for web-of-trust, one step at a time). -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
On Mon, May 21, 2007 at 02:44:28PM -0400, Perry E. Metzger wrote: http://www.physorg.com/news98962171.html My take: clearly, 1024 bits is no longer sufficient for RSA use for high value applications, though this has been on the horizon for some time. Presumably, it would be a good idea to use longer keys for all applications, including low value ones, provided that the slowdown isn't prohibitive. As always, I think the right rule is encrypt until it hurts, then back off until it stops hurting... When do the Certicom patents expire? I really don't see ever longer RSA keys as the answer, and the patents are I think holding back adoption... FWIW, Postfix 2.5 in Q1 08 will have EC support when compiled with (likely officially released by then) OpenSSL 0.9.9, the recommended curve is prime256v1 with secp384r1 for encrypt until it hurts users :-). The other issue is that sites will need multiple certs during any transition from RSA to ECC, because the entire Internet won't upgrade overnight. I am not expecting public CAs to cooperate by charging the same price for two certs (RSA and ECC) for the same subject name(s), this also may significantly impede migration. With EECDH one can use ECDH handshakes signed with RSA keys, but that does not really address any looming demise of 1024 bit RSA. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: More info in my AES128-CBC question
On Thu, Apr 19, 2007 at 10:32:58PM -0700, Aram Perez wrote: Hi Folks, First, thanks for all your answers. The proposal for using AES128-CBC with a fixed IV of all zeros is for a protocol between two entities that will be exchanging messages. This is being done in a standards body (OMA) and many of the attendees have very little security experience. As I mentioned, the response to my question of why would we standardize this was that's how SD cards do it. I'll look at the references and hopefully convince enough people that it's a bad idea. You still have not described the protocol, or how keys are used/managed. The question has no answer outside the context of a specific protocol, other than in general it is best practice to use random IVs or otherwise unlikely to repeat IVs. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AES128-CBC Question
On Wed, Apr 18, 2007 at 11:29:45PM -0700, Aram Perez wrote: Is there any danger in using AES128-CBC with a fixed IV of all zeros? This is being proposed for a standard because that's how SD cards implemented it. Is the same key ever used to encrypt multiple streams? This is a protocol question, not an algorithm question, so you need a security review of the protocol (which you have not described). -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: hoofbeats of zebras, was DNSSEC to be strangled at birth.
On Fri, Apr 06, 2007 at 05:13:00PM -, John Levine wrote: You assume the new .net key (and what's signed with it) would be supplied to all users of the DNS, rather than used for a targeted attack on one user (or a small number of users). Why assume the potential adversary will restrict himself to the dumbest possible way to use the new tools you're about to hand him? I dunno about you, but if some part of the Federal government wanted to mess with a particular target, it's much more likely they would arrange for some large NSPs do some adjusted BGP. Or even more likely some guys in suits would show up at Verisign and say, We're from [redacted] and we would appreciate it if you arranged for requests for [redacted].net from network [redacted]/15 to resolve to [redacted] for the next couple of weeks. Personally, I like Paul's theory about the DHS dork with a press release. He doesn't understand zones or delegation or the root servers or routing or anything else, but the signing key will let them Take Control of this Vital Resource in case of National Emergency. You know, like they did in New Orleans. Exactly, no need to assume a deep conspiracy when mere incompetence explains this quite well. I expect that this story will be long forgotten by the time the root zone is signed, and that the keys will not be given over to DHS or any other agency that is not ICANN/IANA or whoever is actually responsible for the root zone at that point in time. Note also that a small, but non-negligible number of sites obtain the root zone via FTP, and run nameservers authoritative for .. The zone is small enough to make this a good idea, may even a poorly publicized best-practice. Name server operators who serve their own root zone should notice any changes. The attack is most practical against SOHO DHCP users known to get all their DNS from upstream providers. I don't believe this is useful enough to warrant the bad press. Time will tell of course, but my instinct is that this is story is only interesting to the extent that it makes the feared scenario less likely, so though I don't find it a credible threat, the publicity may help to avert any silliness from coming to pass. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cracking the code?
On Sat, Mar 03, 2007 at 04:09:36AM -0800, Allen wrote: On recent consulting gig, I came across what I think is a potential vulnerability and wanted to see how crazy my thinking is. If you are not a security consultant hired to find and close this type of vulnerability, and don't want to follow in the footsteps of Randal L. Schwartz, it is sadly best to stay ignorant of such matters... -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Failure of PKI in messaging
On Thu, Feb 15, 2007 at 10:10:21AM -0500, Leichter, Jerry wrote: Meanwhile, the next generation of users is growing up on the immediacy of IM and text messaging. Mail is ... so 20th century. Well, you certainly don't want to use email when coordinating a place to meet in the next 10-15 minutes, while on the move with a cell phone, or other near-real-time social activity so important to the next generation while they are still the next generation. I challenge the myth that this means that email won't be more important to them as they mature. Meanwhile, in real terms, it would be interesting to know what percentage of Email these days flows *between* organizations, and what percentage remains within individual organization's Exchange servers. I may be able to get you a data-point on that. Qualititatively external email is not shrinking in significance here. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OT: SSL certificate chain problems
On Wed, Jan 31, 2007 at 01:57:04PM +1300, Peter Gutmann wrote: Victor Duchovni [EMAIL PROTECTED] writes: What I don't understand is how the old (finally expired) root helps to validate the new unexpired root, when a verifier has the old root and the server presents the new root in its trust chain. You use the key in the old root to validate the self-signature in the new root. Since they're the same key, you know that the new root supersedes the expired one. Does this actually work with OpenSSL and v3 CA certs that have X509v3 Authority Key Identifier extensions? With these extensions present (default when OpenSSL constructs CA certs, ...), certs whose serial number does not match the serial field in the extension are not considered to be root CA certs (not self-signed), and CA certs sharing the same keys and DN, but carrying different serials, simply don't match. If I roll-back the serial numbers and issue a cert with all the details (including serial number, ...) the same, but just the start/end dates changed to start before the expiration of the verifier's expired CA, and end after today's date, the verifier ends up with a trust chain that starts with the expired cert and fails, regardless of whether the server sends the new root CA cert or not. CA0.pem: serial=C27B874157E381C0 issuer= fixed-ca-dn subject= fixed-ca-dn notBefore=Jan 1 00:00:00 2007 GMT notAfter=Jan 31 00:00:00 2007 GMT ... X509v3 Authority Key Identifier: keyid:CB:C0:45:68:F9:B0:DF:8B:A9:E9:EA:A0:F1:93:A1:C1:6B:7C:96:E4 DirName:fixed-ca-dn serial:C2:7B:87:41:57:E3:81:C0 CA1.pem: serial=C27B874157E381C0 issuer= fixed-ca-dn subject= fixed-ca-dn notBefore=Jan 15 00:00:00 2007 GMT notAfter=Feb 28 00:00:00 2007 GMT ... X509v3 Authority Key Identifier: keyid:CB:C0:45:68:F9:B0:DF:8B:A9:E9:EA:A0:F1:93:A1:C1:6B:7C:96:E4 DirName:fixed-ca-dn serial:C2:7B:87:41:57:E3:81:C0 SRV.pem: - serial=C27B874157E381C1 issuer= fixed-ca-dn subject= server-dn notBefore=Jan 15 00:00:00 2007 GMT notAfter=Feb 28 00:00:00 2007 GMT ... X509v3 Authority Key Identifier: keyid:CB:C0:45:68:F9:B0:DF:8B:A9:E9:EA:A0:F1:93:A1:C1:6B:7C:96:E4 DirName:fixed-ca-dn serial:C2:7B:87:41:57:E3:81:C0 A client with CAfile containing just CA0.pem fails to verify a server configured to send the SRV,CA1 trust chain. My verification callback is called three times and produces: Trace: certificate verification depth=1 verify=0 subject=fixed-ca-dn Error: CA certificate verification failed for peer certificate has expired Trace: certificate verification depth=1 verify=1 subject=fixed-ca-dn Trace: certificate verification depth=0 verify=1 subject=server-dn If the verifier trusts the CA1.pem cert, I see instead: Trace: certificate verification depth=1 verify=1 subject=fixed-ca-dn Trace: certificate verification depth=0 verify=1 subject=fixed-server-dn How does one construct a working (re-issued root CA) example with OpenSSL? Am I setting this up incorrectly, or does OpenSSL not in fact support establishing trust in re-issued root CA via now expired root CAs? I have not tried to do this without the issuer key identifier extension, but don't really expect to find anything different... -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OT: SSL certificate chain problems
On Wed, Jan 31, 2007 at 01:57:04PM +1300, Peter Gutmann wrote: Victor Duchovni [EMAIL PROTECTED] writes: What I don't understand is how the old (finally expired) root helps to validate the new unexpired root, when a verifier has the old root and the server presents the new root in its trust chain. You use the key in the old root to validate the self-signature in the new root. Since they're the same key, you know that the new root supersedes the expired one. So this is a special trick to extend root CA lifetimes. How widely is this logic implemented, and is extending root CA key lifetime in this manner standard practice? I may have to revise the Postfix documentation to advise users to send the root cert. My most recent experience is ironically in the opposite direction: Peer finally upgrades from Windows Server 2000 to Windows Server 2003, and replaces unexpired Verisign CA certs (updated at some point in the past in the working Windows 2000) with now expired CA certs that were good way back, when the Windows 2003 CDs were burned :-) -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OT: SSL certificate chain problems
On Sat, Jan 27, 2007 at 02:12:34PM +1300, Peter Gutmann wrote: Victor Duchovni [EMAIL PROTECTED] writes: Wouldn't the old root also (until it actually expires) verify any certificates signed by the new root? If so, why does a server need to send the new root? Because the client may not have the new root yet, and when they try and verify using the expired root the verification will fail. I am curious how the expired trusted old root helps to verify the as yet untrusted new root... Is there a special-case behaviour when the old and new root share the same DN and public key? Is such special-case behaviour standard for trust chain verification implementations (allowing the lifetime of root CAs to be indefinitely extended by issuing new certs with the same keys)? -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OT: SSL certificate chain problems
On Sun, Jan 28, 2007 at 12:47:18PM -0500, Thor Lancelot Simon wrote: Wouldn't the old root also (until it actually expires) verify any certificates signed by the new root? If so, why does a server need to send the new root? So long as the recipient has either the new or the old root, the chain will be valid. That doesn't make sense to me -- the end-of-chain (server or client) certificate won't be signed by _both_ the old and new root, I wouldn't think (does x.509 even make this possible)? Or do I misunderstand? The key extra information is that old and new roots share the same issuer and subject DNs and public key, only the start/expiration dates differ, so in the overlap when both are valid, they are interchangeable, both verify the same (singly-signed) certs. What I don't understand is how the old (finally expired) root helps to validate the new unexpired root, when a verifier has the old root and the server presents the new root in its trust chain. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OT: SSL certificate chain problems
On Fri, Jan 26, 2007 at 07:06:00PM +1300, Peter Gutmann wrote: Victor Duchovni [EMAIL PROTECTED] writes: Generally it is enough for a TLS server or client to present its own certificate and all *intermediate* CA certificates, sending the root CA cert is optional, because if the verifying system trusts the root CA in question, it has a local copy of that root CA cert. In some cases it may be useful to send the entire chain, one such being when a CA re-issues its root with a new expiry date, as Verisign did when its roots expired in December 1999. The old root can be used to verify the new root. Wouldn't the old root also (until it actually expires) verify any certificates signed by the new root? If so, why does a server need to send the new root? So long as the recipient has either the new or the old root, the chain will be valid. Is the problem case when the verifier has both roots, and the older of the two has expired? -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: analysis and implementation of LRW
On Wed, Jan 24, 2007 at 03:28:50PM -0800, Allen wrote: David Wagner wrote: [snip] Another possible interpretation of (2) is that if you use LRW to encrypt close to 2^64 blocks of plaintext, and if you are using a 128-bit block cipher, then you have a significant chance of a birthday collision, Am I doing the math correctly that 2^64 blocks of 128 bits is 2^32 bytes or about 4 gigs of data? Or am I looking at this the wrong way? This is quite wrong. 2^64 * 2^4 = 2^68 not 2^32, I don't know where you lost the factor 2^36, but it sure makes a big difference. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Sat, Jan 20, 2007 at 10:10:47PM +1300, Peter Gutmann wrote: Victor Duchovni [EMAIL PROTECTED] writes: It took reading the code to determine the following: - ASN.1 Strings extracted from X.509v3 certs are not validated for conformance with the declared character syntax. Strings of type PrintableString or IA5String may hold non-printable or non-ASCII data. Just a word in OpenSSL's defence, see the X.509 Style Guide for the reasoning behind this. I don't think any ASN.1-using security toolkit since TIPEM has done character-set checking, it would fail to verify a large chunk of the certs out there (I once had a TIPEM user complain to me that they had to stop using it specifically because it would reject invalid character strings, which encompassed a nontrivial portion of their user base). I understand the motivation, and agree that this is the right thing to do, indeed in the application (Postfix) I just map the content to UTF8 (using the identity mapping where appropriate) and then decide what characters are acceptable, I don't need the original ASN.1 string type after the string is in canonical form. My point was that not all the fine details are always documented (even in closed source libraries with funded documentation teams), and having the source allows me to move beyond cargo-cult programming and to understand how to use the library correctly. I guess this is RTFS to extract the semantics out of the syntax documentation. In addition, I think that the library should-provide idiot-friendly interfaces for handling ASN.1 string data holding security sensitive information (CommonName, subjectAltName, ...), because the code one finds and copies from other projects is not sufficiently careful. RFC 3820 suggests that it is OK to consider strings of different ASN.1 types as different content for comparison and then, by implication, just compare the raw content when the types match, but what one finds is that applications mostly IGNORE the ASN.1 string type and use the raw octets for comparison, display, ... and they do that at their peril. It is also almost universal practice (in C code anyway) to not check for embedded NUL in the ASN.1 strings, and I wonder how may CAs would issue eve.biz a cert for alice.com\0..eve.biz? (If the CA's code handles NUL in octet strings as just another byte, this could happen. But we digress again, the source is useful in any case, and not just for full code reviews, used with care it is the ultimate documentation. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Thu, Jan 18, 2007 at 03:57:46PM -0800, Saqib Ali wrote: When is the last time you checked the code for the open source app that you use, to make sure that it is written properly? Yesterday, in the case of OpenSSL, though I was only looking at how ASN.1 strings that store the subject CN and subjectAltName deal with the various possible supported encodings, embedded NUL octets, ... It took reading the code to determine the following: - ASN.1 Strings extracted from X.509v3 certs are not validated for conformance with the declared character syntax. Strings of type PrintableString or IA5String may hold non-printable or non-ASCII data. - Rather in OpenSSL all the ASN.1 string types are opaque TLV byte arrays, with a manifest type and arbitrary content that may or not be consisten with the type, and may hold embedded NUL bytes which require some care in C applications, but at least it *is* possible if is careful, to check that: ASN_STRING_length(s) == strlen(ASN1_STRING_DATA(s)) - Conversion to UTF8 is implemented correctly, without prematurely stopping on internal NUL octets. This also checks that BMPString and UniversalStrings have encoded lengths that are even or divisible by 4 respectively, and that UTF8 input is valid and minimal. This means that as a user of the library, I must (and fortunately can): - Convert the raw ASN.1 encoded data if BMPString or UniversalString to UTF8. - Check CommonNames and DNS subjectAltNames for internal NULs, because I can't rely on no CA to ever mess up and sign a cert for alice.com\0.eve.com. This check is not found in most sample applications that (cargo-cult programming rampant in other problem spaces is also common with SSL). - Check CommonNames and DNS subjectAltNames for unexpected non-printable or non-printable characters as appropriate. This is not the same as a full code review, but having access to the source means that I can make sure that my code is a correct use of the interface, that I am not making unfounded assumptions, and there are no obvious bugs in the part of the library that I am reviewing. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A web site that believes in crypto
On Wed, Jan 10, 2007 at 06:31:21PM -0500, Steven M. Bellovin wrote:
I just stumbled on a web site that strongly believes in crypto --
*everything* on the site is protected by https. If you go there via
http, you receive a Redirect. The site? www.cia.gov:
$ telnet www.cia.gov 80
Trying 198.81.129.100...
Connected to www.odci.gov.
Escape character is '^]'.
GET / HTTP/1.0
HTTP/1.0 301 Found
Location: https://www.cia.gov/
Their public email gateways don't believe in crypto nearly as much as
cs.columbia.edu does.
$ for d in cia.gov cs.columbia.edu; do
echo; dig +sho -t mx $d | sort +0n |
tee /dev/tty |
perl -lne 'm{(\S+)\.$} print $1' |
while read h; do echo; smtp-finger -t [$h] $d 21 |
perl -lne 'print unless (/^-{5}BEGIN/ .. /^-{5}END/);'; done; done
5 mail2.ucia.gov.
10 mail1.ucia.gov.
smtp-finger: Connected to mail2.ucia.gov[198.81.129.148]:25
smtp-finger: 220 mail2b.ucia.gov ESMTP
smtp-finger: EHLO amnesiac.ms.com
smtp-finger: 250-mail2b.ucia.gov
smtp-finger: 250-8BITMIME
smtp-finger: 250 SIZE 104857600
smtp-finger: Connected to mail1.ucia.gov[198.81.129.68]:25
smtp-finger: 220 mail1a.ucia.gov ESMTP
smtp-finger: EHLO amnesiac.ms.com
smtp-finger: 250-mail1a.ucia.gov
smtp-finger: 250-8BITMIME
smtp-finger: 250 SIZE 104857600
100 cs.columbia.edu.
200 ober.cs.columbia.edu.
200 opus.cs.columbia.edu.
smtp-finger: Connected to cs.columbia.edu[128.59.16.20]:25
smtp-finger: 220 cs.columbia.edu ESMTP Sendmail (8.12.10/22/jtt/sed/ib42)
is thrilled to serve you at Sat, 13 Jan 2007 13:27:13 -0500 (EST).
smtp-finger: EHLO amnesiac.ms.com
smtp-finger: 250-cs.columbia.edu Hello amnesiac.ms.com [192.0.2.1],
pleased to meet you
smtp-finger: 250-ENHANCEDSTATUSCODES
smtp-finger: 250-PIPELINING
smtp-finger: 250-EXPN
smtp-finger: 250-VERB
smtp-finger: 250-8BITMIME
smtp-finger: 250-SIZE 2500
smtp-finger: 250-DSN
smtp-finger: 250-ETRN
smtp-finger: 250-STARTTLS
smtp-finger: 250-DELIVERBY
smtp-finger: 250 HELP
smtp-finger: STARTTLS
smtp-finger: 220 2.0.0 Ready to start TLS
smtp-finger: certificate verification failed for
cs.columbia.edu[128.59.16.20]:25: untrusted issuer /C=US/O=Equifax Secure
Inc./CN=Equifax Secure Global eBusiness CA-1
smtp-finger: TLSv1 connection to
cs.columbia.edu(cs.columbia.edu[128.59.16.20]:25) with cipher
DHE-RSA-AES256-SHA (256/256 bits)
smtp-finger: EHLO amnesiac.ms.com
smtp-finger: 250-cs.columbia.edu Hello amnesiac.ms.com [192.0.2.1],
pleased to meet you
smtp-finger: 250-ENHANCEDSTATUSCODES
smtp-finger: 250-PIPELINING
smtp-finger: 250-EXPN
smtp-finger: 250-VERB
smtp-finger: 250-8BITMIME
smtp-finger: 250-SIZE 2500
smtp-finger: 250-DSN
smtp-finger: 250-ETRN
smtp-finger: 250-AUTH PLAIN LOGIN
smtp-finger: 250-DELIVERBY
smtp-finger: 250 HELP
smtp-finger: Unverified: subject_CN=cs.columbia.edu, issuer=Equifax Secure
Global eBusiness CA-1
smtp-finger: Server session id:
8EA8B66A9DCCA0903BF75B7FC71316CE201330A0B1B09114FB6BE15E25AA9827
smtp-finger: Common Name: cs.columbia.edu: matched
---
Certificate chain
0
s:/C=US/O=cs.columbia.edu/OU=https://services.choicepoint.net/get.jsp?GT1305/OU=See
www.geotrust.com/quickssl/cps (c)04/OU=Domain Control Validated - This is a
GeoTrust QuickSSL Premium(R) Certificate/CN=cs.columbia.edu
i:/C=US/O=Equifax Secure Inc./CN=Equifax Secure Global eBusiness CA-1
smtp-finger: Connected to ober.cs.columbia.edu[128.59.18.100]:25
smtp-finger: 220 ober.cs.columbia.edu ESMTP Sendmail
(8.12.10/22/jtt/sed/ib42) is thrilled to serve you at Sat, 13 Jan 2007 13:27:14
-0500 (EST).
smtp-finger: EHLO amnesiac.ms.com
smtp-finger: 250-ober.cs.columbia.edu Hello amnesiac.ms.com [192.0.2.1],
pleased to meet you
smtp-finger: 250-ENHANCEDSTATUSCODES
smtp-finger: 250-PIPELINING
smtp-finger: 250-EXPN
smtp-finger: 250-VERB
smtp-finger: 250-8BITMIME
smtp-finger: 250-SIZE 2500
smtp-finger: 250-DSN
smtp-finger: 250-ETRN
smtp-finger: 250-STARTTLS
smtp-finger: 250-DELIVERBY
smtp-finger: 250 HELP
smtp-finger: STARTTLS
smtp-finger: 220 2.0.0 Ready to start TLS
smtp-finger: certificate verification failed for
ober.cs.columbia.edu[128.59.18.100]:25: untrusted issuer /C=US/O=Equifax Secure
Inc./CN=Equifax Secure Global eBusiness CA-1
smtp-finger: TLSv1 connection to
ober.cs.columbia.edu(ober.cs.columbia.edu[128.59.18.100]:25) with cipher
DHE-RSA-AES256-SHA (256/256 bits)
smtp-finger: EHLO amnesiac.ms.com
smtp-finger: 250-ober.cs.columbia.edu Hello amnesiac.ms.com [192.0.2.1],
pleased to meet you
smtp-finger: 250-ENHANCEDSTATUSCODES
smtp-finger: 250-PIPELINING
smtp-finger: 250-EXPN
smtp-finger: 250-VERB
smtp-finger:
Re: SSL (https, really) accelerators for Linux/Apache?
On Tue, Jan 02, 2007 at 01:43:14PM -0500, John Ioannidis wrote: There is too much conflicting information out there. Can someone please recommend an SSL accelerator board that they have personally tested and used, that works with the 2.6.* kernels and the current release of OpenSSL, and is actually an *accelerator* (I've used a board from a certain otherwise famous manufacturer that acted as a decelerator...). I only need this for SSL, not for IPsec. I don't have any experience with any hardware in this space, but you should be clear about one thing: - Are you trying to accelerate symmetric bulk crypto of the SSL payload, or the PKI operations in a cold SSL handshake? Depending on the application and load, and given a suitable SSL session cache, the PKI load may be negligible. For example, traffic between two fixed MTAs with caches on both sides only does one SSL handshake per cache TTL and then just bulk crypto for many deliveries that reuse the cached SSL session. So what is your load like? -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: hashes on restricted domains: random functions or permutations?
On Wed, Oct 18, 2006 at 12:00:41AM -0400, Victor Duchovni wrote: Hash functions are supposed to be pseudo-random. For a 160 bit hash In an input set of 2^80 elements we should expect to find a collision... If we iterate from a random starting point we expect to enter a cycle of length ~2^79 after ~2^79 initial outputs. So the subsets on which an iterated hash acts as a right-shift are expected to be ~2^79 in length. This part is right. An intuitive (but possibly grossly wrong) leap is that there should be ~~2^80 disjoint cycles with half of the inputs outside a cycle and half inside a cycle. None of this should lead to any apparent weakness after a modest number of iterations. This had to be wrong of course, the range does not separate into disjoint loops with a single linear strand leading into the loop. There is branching before the loop and multiple entry points into the loop. This reminds me of the analysis of the space-time tradeoff for brute forcing password hashes. Don't have it in front of me, but in that work effective estimates of the branching were taken into account. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why the exponent 3 error happened:
On Thu, Sep 14, 2006 at 11:25:11AM -0400, [EMAIL PROTECTED] wrote: James A. Donald writes: -+--- | snip | | ASN.1 provided additional redundant information, making | possible unexpected data layouts that should not | normally happen. It had too much expressive power, too | much flexibility. It could express cases that one does | not expect to deal with, could flex in more ways than | one's software is likely to be written for. | | snip Sir, There is a lesson here as important as Fred Brook's Adding people to a late project makes it later and I urge you to put this in some form of print at your earliest capability. No, not urge but rather beg. If so, I fear we are learning the wrong lesson, which while valid in other contexts is not pertinent here. TLS must be flexible enough to accommodate new algorithms, this means that the data structures being exchanged are malleable, and that implementations must validate strict adherence to a specifically defined form for the agreed algorithm, but the ability to express other forms cannot be designed out. This, in my view, has little to do with ASN.1, XML, or other encoding frameworks. Thorough input validation is not yet routinely and consistently practiced by most software developers. Software is almost invariably written to parse formats observed in practice correctly, and is then promptly declared to work. The skepticism necessary to continually question the implicit assumption that the input is well-formed is perhaps not compatible with being a well-socialized human. The attackers who ask the right questions to break systems and the few developers who write truly defensive code are definitely well off the middle of the bell-curve. It is not just PKCS#1 or X.509v3 that presents opportunities for crafting interesting messages. MIME, HTTP, HTML, XML, ... all exhibit similar pitfalls. Loosely speaking, this looks like a variant of Goedel's theorem, if the protocol is expressive enough it can express problematic assertions. We can fine-tune some protocols to remove stupid needless complexity, but enough complexity will remain to make the required implementation disciple beyond the reach of most software developers (at least as trained today, but it is not likely possible to design a training program that will a preponderance all strong defensive programmers). -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: mailer certificate retrieval via LDAP?
On Thu, Jun 08, 2006 at 02:32:01PM -0400, Steven M. Bellovin wrote: Are there any common mailers -- open source preferred but not mandatory -- that can query LDAP directories to retrieve X.509 certificates for use in S/MIME messages? Evolution and Thunderbird are both able to send S/MIME, but don't seem to have any easy certificate retrieval mechanisms. Thunderbird supports PKCS#11 plugins modules, so all you need is PKCS#11 plugin for LDAP. So question looks like a question about availability of plugins, rather than MUAs... -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of opportunistic encryption
On Wed, May 31, 2006 at 08:56:53AM +1000, James A. Donald wrote: Active attacks are rare, possibly nonexistent except for Wifi. If NSA and the other TLAs were doing active attacks, they would be detected some of the time. They don't like being detected. Active attacks at the network layer are relatively rare, but definitely not non-existent. Spammers occasionally hijack BGP prefixes, send some spam and move on. They can also hijack nameserver IPs, MX host IPs, but for now they prefer sending over receiving. This will likely change, the playbook of organized crime on the net has been expanding steadily when money overtook teen-age dare-do as the most common motivation for active attacks in ~2002. If anyone does an active attack, this is a one off event. If someone routinely and regularly does active attacks, the attack will be detected, the point where they are modifying messages will be detected, and will be bypassed. They keep moving around, some ISPs turn a blind eye in return for the revenue stream. Consequently, also SSH with GSS KEX, is not MITM resistant when the attacker can tamper with DNS responses. My understanding is that SSH when using GSS KEX does not cache the keys, which strikes me as a amazingly stupid idea, No, that's the whole point. What works for the individual administering 10 machines, does not scale to organizations with hundres of administrators managing tens of thousands of machines. With KEX you trust Kerberos, not your key store. The problem is that one also ends up trusting, DNS or NIS or LDAP, ... particularly when SSH key caching has been so successful, and when the user thinks he knows his security comes from key caching. The experience with PKI suggests that it is very difficult to have security without durable cached keys. Quite the converse, the PKI keys are too durable. (Segue to Wheeler Wheeler) the Kerberos online verification model is actually superior, but in practice the implementation runs into issues with insecure nameservices. We need a more secure stack. Attacks on DNS are common, though less common than other attacks, but they are by scammers, not TLA agencies, perhaps because they are so easily detected. Yes, but the scammers are getting into more markets, first spam and advance fee scams, then phishing, now pump and dump scams, they are evolving fast. We are largely standing still. Encrypting DNS is unacceptable, because the very large number of very short messages make public key encryption an intolerable overhead. A DNS message also has to fit in a single datagram. Workable DNS-SEC exists, what lacks now is the will and political muscle to make it happen. Signing is done on update, not on read. To accommodate these constraints, we need DNS certificates sent in the clear, and signed with elliptic curve public keys (which allow both signatures and certificates to be short enough to fit in a datagram). The real question is not how to do DNS-SEC, but how soon, and then how to leverage it in real protocols. Will there be a reasonably comprehensive set of Internet integrated services that work *together* securely in a reasonable fashion, or are we still building the tower of Babel (now in software). A more trustworthy DNS would IMHO be a good foundation. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
On Wed, May 31, 2006 at 09:41:57AM +1000, James A. Donald wrote: The obvious solution to the phishing crisis is the widespread deployment of SRP, but this does not seem to happening. SASL-SRP was recently dropped. What is the problem? The obvious solution is perhaps more difficult to deploy in an environment where loss of ubiquitous access trumps security gains. It takes years to *field* new infrastructure. When the designer calls the problem solved, the real work begins, or not, if the market is not yet ready for the solution. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: picking a hash function to be encrypted
On Sun, May 14, 2006 at 03:04:41AM -0500, Travis H. wrote: Suppose I want a function to provide integrity and authentication, and that is to be combined with a stream cipher (as is the plaintext). I believe that authentication is free once I have integrity given the fact that the hash value is superencrypted using the stream cipher, whose key is shared by only the sender and recipient. I believe what I'm looking for is a strongly universal hash. I don't need much; everything I've seen is simultaneously too much and too little, often calling upon a block cipher, which seems redundant. What I was thinking of doing was using Poly1305, and using the stream cipher instead of AES. I think in this case that I can leave the MAC exposed, since it's a MAC and not a hash. Is there an analogous, hash function that does not use encryption internally? Security is fragile. Deviating from well understood primitives may be good research, but is not good engineering. Especially fragile are: - Non-mainstream ciphers (often broken once someone good bothers to try) - Stream ciphers (additive) - RC4 (poor key schedule) - RSA (multiplicative) The first is to be avoided entirely, the second and third should be used only under duress, when block ciphers are a very poor fit for the application. RSA needs to be used only in very specific ways (PKCS 2.1, for example) that avoid the common pitfalls. TLS (available via OpenSSL) provides integrity and authentication, any reason to re-invent the wheel? It took multiple iterations of design improvements to get TLS right, even though it was designed by experts. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: picking a hash function to be encrypted
On Sun, May 14, 2006 at 07:56:17PM -0500, Travis H. wrote: On 5/14/06, Victor Duchovni [EMAIL PROTECTED] wrote: Security is fragile. Deviating from well understood primitives may be good research, but is not good engineering. Especially fragile are: Point taken. This is not for a production system, it's a research thing. TLS (available via OpenSSL) provides integrity and authentication, any reason to re-invent the wheel? It took multiple iterations of design improvements to get TLS right, even though it was designed by experts. IIUC, protocol design _should_ be easy Once upon a time, everyone agreed that cipher design was hard. Later people discovered that protocol design is hard too. More recently people are discovering that given solid ciphers and protocols, secure implementations are still hard... I could be wrong, but it does not seem that the trend is towards increasingly easy security, in the sense that anyone who learns a programming language reasonably well can develop security toolkits. :-( -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Linux RNG paper
On Thu, May 04, 2006 at 01:44:48PM -0500, Travis H. wrote: I guess perhaps the reason they don't do integrity checking is that it involves redundant data, so the encrypted volume would be smaller, or the block offsets don't line up, and perhaps that's trickier to handle than a 1:1 correspondence. Exactly, many file systems rely on block devices with atomic single block (sector) writes. If sector updates are not atomic, the file system needs to be substantially more complex (unavoidable transaction logs to support roll-back and roll-forward). Encrypted block device implementations that are file system agnostic, cannot violate block update atomicity and so MUST not offer integrity. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: History and definition of the term 'principal'?
On Wed, Apr 26, 2006 at 06:33:43PM +0200, Hadmut Danisch wrote: Some say a principal is someone who participates in a cryptographical protocol. The way I see it, the common English sense is direct participant, not a third party. During TGS requests the Kerberos KDC is a *principal* in the TGS transaction. Soon after, the acquired ticket and session key are used to communicate with the intended service and the KDC is then a third party and not a *principal*. So with Kerberos the word hasW its narrower named security entity technical meaning. With X.509 one tends to talk of subjects, issuers, registration authorities, certification authorities, ... and the word principal is less common. Can anyone give me some hints? Maybe about how 'principal' is related to Roger Needham? Or whether there is a precise and general definition? Seems to be mostly a matter of perspective, on the wire single-sign-on systems authenticate principals, while in the OS or application server ACLs authorize subjects. Oddly enough the difference in terminology better reflects the power balance between the royal issuer and petty subject in X.509. Wild guess, perhaps more seriously this dates back to X.509 as a supporting technology for X.500 ACLs. In the context of Kerberos, I think of principals as living in an external global (or at least potentially larger) namespace, while subjects or users in ACLs are often local system specific entities. This means that one often needs a mapping from principals (global naming) to subjects/users (local naming). So principal != account. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Secure Blue from IBM
On Thu, Apr 13, 2006 at 11:06:38AM -0400, Perry E. Metzger wrote: With Secure Blue, data is encrypted and decrypted as it runs through a processor, according to IBM. It is maintained encrypted in the device memory, or RAM. One of the few times data would not be scrambled is when it is actually displayed. http://news.com.com/2100-7355_3-6059276.html Easy enough for ephemeral data (RAM, network, ...), but what do they propose for stored data? Is this an architecture for general-purpose computers, or for special-purpose media devices? Is more detail available? As soon as data is stored, new key management issues come to the surface. I for one would not want to lose my hard-drive if the CPU is fried... -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Cfrg] HMAC-MD5
On Wed, Mar 29, 2006 at 10:51:08AM +0200, [EMAIL PROTECTED] wrote: In am nearly sure that a preimage attack (MD5) will be found in the next two or three years. Is there already evidence of progress in that direction? -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Linux RNG paper
On Wed, Mar 22, 2006 at 02:31:37PM -0800, Bill Frantz wrote: One of my pet peeves: The idea that the user is the proper atom of protection in an OS. My threat model includes different programs run by one (human) user. If a Trojan, running as part of my userID, can learn something about the random numbers harvested by my browser/gpg/ssh etc., then it can start to attack the keys used by those applications, even if the OS does a good job of keeping the memory spaces separate and protected. Why would a trojan running in your security context bother with attacking a PRNG? It can just read your files, record your keystrokes, change your browser proxy settings, ... If the trojan is a sand-box of some sort, the sand-box is a different security context, and in that case, perhaps a different RNG view is justified. Some applications that consume a steady stream of RNG data, maintain their own random pool, and use the public pool to periodically mix in some fresh state. These are less vulnerable to snooping/exhaustion of the public stream. The Postfix tlsmgr(8) process proxies randomness for the rest of the system in this fashion... -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Zfone and ZRTP :: encryption for voip protocols
On Wed, Mar 15, 2006 at 02:52:15PM -0800, Ed Gerck wrote: cybergio wrote: Zfone :: http://www.philzimmermann.com/EN/zfone/index.html ...it achieves security without reliance on a PKI, key certification, trust models, certificate authorities, or key management... Good. But, uf course, there's a trust model and you need to rely on it. ...allows the detection of man-in-the-middle (MiTM) attacks by displaying a short authentication string for the users to read and compare over the phone. Depends on the trust model. May not work. Indeed, but it looks to be the right security model for the mass market. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
On Wed, Mar 01, 2006 at 06:15:36PM +0100, Ian G wrote: Email is hard to get encrypted, but it didn't stop Skype from doing encryped IMs easily. Likewise I have secured email communications with my wife via a single key exchange, so what? Skype has not easily created an interoperable federated system that secures all IM communications end-to-end, and many of the issues in doing that are non-technical. Right. Nor did email create a single federated system that crosses across to mobile phones. There is always a boundary where a system stops. Federated accross millions of account issuing organizations, not technologies, and email did do that, and IM did not. IM is like email from a choice MCI, Sprint or ATT, sure they can control the medium better, but this is a temporary state of affairs... The point is that the non-technical issues we are looking at here are *better* handled at the level of competitive systems, because they have incentives to solve them, whereas technical committees writing RFCs do not. These are closed systems that compete with each other, once they become federated, they can no longer compete on end-to-end security, because that is a property of the interoperability framework, not the individual product. Also with millions of account issuers, the abuse and identity problems become just as bad as for email. The problem is intrinsic, is not the result of lazy RFC writers. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
On Wed, Mar 08, 2006 at 12:53:16PM -0700, Peter Saint-Andre wrote: These are closed systems that compete with each other, once they become federated, they can no longer compete on end-to-end security, because that is a property of the interoperability framework, not the individual product. Also with millions of account issuers, the abuse and identity problems become just as bad as for email. The problem is intrinsic, is not the result of lazy RFC writers. Well, in the Jabber/XMPP world we require authentication, servers must stamp the from addresses, and we use (at a minimum) reverse DNS lookups to verify server identities (or use certs with TLS + SASL-EXTERNAL if you want true server-to-server authentication). So I'd say the abuse and identity problems are not as bad in IM (at least the IM technology I'm familiar with) as in email. But you'd hope that we've learned a thing or two since email was invented. ;-) What is the value of such authentication? Which organizations will you trust? For example, most mail that passes SPF is spam... Authentication by the issuing organization is only useful, if you can keep bad issuers of the net... If federated Jabber becomes universal, the bad guys cannot be excised from the network. The botnets cannot be excised from the network, ... The problem is technology neutral. Loosely along the lines of Goedel's incompleteness theorem, any universally deployed federated communications medium will exhibit spam. MaximEither it is not mature enough, or it has spam./Maxim -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
On Wed, Mar 08, 2006 at 01:55:16PM -0700, Peter Saint-Andre wrote: I never made the strong claim that the federated Jabber network is or always will remain spam free, only the weaker claim that its abuse and identity problems are and will remain less serious than those of the federated email network as it exists today. Time will tell. All I expect from the ultimate (~3 years out) rollout of email authentication is less backscatter, not less phishing or spam. I do not dispute that if Jabber becomes popular enough, there will be rogue servers that don't enforce local authentication (although with server dialback and TLS they can't fake from addresses at other domains, see RFC 3920), and that those who deploy Jabber services will need to blacklist those domains. Of course new domains are less than $4 each in bulk... How will you lock out throw-away domains? The black-list problem for email is not solved. The good lists are nowhere near 100% effective. Is the equivalent of port 25 blocking tractable for Jabber? Is there a difference between the user-to-server port/protocol and the server-to-server port/protocol in Jabber? I do not dispute that there will be spam bots and that server admins or end users will need to block communication with those bots (e.g., using the privacy list protocol defined in RFC 3921). I do not dispute that there will be phishing attacks (e.g., using internationalized addresses that look like but are not identical to familiar addresses) and that client software will need to take appropriate measures to differentiate between legitimate and mimicked addresses (e.g., using petname systems as described in JEP-0165). Yes petname systems are an important UI tool for preserving the integrity of existing peer communications. If IM is to replace email as some want to claim, it needs to support messages from a fair share of total strangers (we have never met). All I'm saying is that we have a lot of the infrastructure in place (and are building more) to make abuse harder and identity stronger than it is on the existing email network. Is Jabber perfect? No. We're just trying to make it good enough that the bad guys will go elsewhere (which, so far, they have). My claim is that, while indeed it is easier to set the initial barriers higher when you design with greater hindsight, and some of the tractable, but not widely deployed email security measures will be there in IM systems from the start, never the less IM systems if they are to encroach on the ubiquity of email for ad-hoc communications between strangers (it is far easier to address strangers via email today) will encounter exactly the same intrinsic issues, and that technical measures will have equally partial efficacy. I am willing to speculate that the more likely scenario is that IM will not become the ubiquitous medium that email is, and will escape the problem by avoiding scope creep. I am willing to speculate that people will continue to unfairly tarnish the competence of the email RFC writers, without regard to the intrinsic properties of the medium. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
On Sun, Feb 26, 2006 at 01:42:56PM -0800, Trevor Perrin wrote: Perhaps this is further support for Iang's contention that we should expect newer, interactive protocols (IM, Skype, etc.) to take the lead in communication security. Email-style message encryption may simply be a much harder problem. This is neither surprising, nor relevant to email. We are at this point reasonably good at encrypting unicast traffic and the associated key management problem is often viable. Encrypting stored data is a substantially more difficult problem. We have increasingly common opportunistic TLS encryption of email traffic, with occasional fully verified secure-channels between some pairs of sites. We could conceivably some day (political barriers primarily at this point) have a secure DNS for secure MX record lookups and key distribution enabling secure channels between most sites. This is viable, traffic encryption is a tractable problem. Encrypting email content, to be stored encrypted, and decrypted when read off-line, or read again later, ... is a problem that the IM and VoIP vendors don't have to solve. They also don't have to solve global federation of universally interoperable systems... -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
On Sat, Feb 25, 2006 at 07:33:38PM +0100, Ian G wrote: Hence, IM/chat, Skype, TLS experiments at Jabber, as well as the OpenPGP attempts. There are important lessons to be learnt in the rise of IM over email. Likewise the rise of the telephone over paper mail, but the phone does not obviate the need for paper mail. Email is held back by its standardisation, chat seems to overcome spam quite nicely. Where's Gaddi Evron when you need him? This is just not true, the spam volume is rising for both blogs and IM. Email is hard to get encrypted, but it didn't stop Skype from doing encryped IMs easily. Likewise I have secured email communications with my wife via a single key exchange, so what? Skype has not easily created an interoperable federated system that secures all IM communications end-to-end, and many of the issues in doing that are non-technical. The competition between the IM systems is what is driving the security forward. As there is no competition in the email world, at least at the level of the basic protocol and standard, there is no way for the security to move forward. IM is islands of automation, luckily email works globally. Phishing is possible over chat, but has also been relatively easy to address - because the system owners have incentives and can adjust. This is naive, IM will become federated and decentralized and abuse issues will be the same as for email. You can't fence the bad guys out of the network. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
On Thu, Feb 16, 2006 at 09:36:16AM +1000, James A. Donald wrote: In the case in question, going bad means that the program appears to be encrypting data, but is NOT encrypting data, or is only trivially encrypting data. This is far worse for the customer than an encryption program that simply aborts. Who said the program's primary function is data security? The program may be handling entirely public data, available from multiple sources. One of the sources may offer opportunistic encrypt, which though potentially useful, is inessential and mostly does no harm. It takes hubris for libgrypt to *assume* that is functions are essential. The dichotomy between pretending to encrypt data and exiting is false. It is plainly correct to not encrypt any data and say so (return errors from the encryption API). I'm outta here. I did not expect any controversy on this point, and don't expect views to shift dramatically. If the developers were open to the issue, the request might have been fruitful. If they dig in their heels, I am free to use other libraries. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
On Tue, Feb 14, 2006 at 01:00:33PM -0500, Steven M. Bellovin wrote: We all agree that critical errors like this should be caught; the only question is at what layer the action should take place. I'm an adherent to the Unix philosophy -- when a decision is made at a lower level, it takes away the ability of the higher level to do something different if appropriate, and this loss of flexibility is a bad thing. Thanks, this makes the point very clearly! Let me suggest a C-compatible possibility: pass an extra parameter to the library routines, specifying a procedure to call if serious errors occur. If that pointer is null, the library can abort. The pass-a-function pointer approach covers the simpler cases. Large utility libraries (OpenSSL, Kerberos, ...) sometimes have a tougher problem to solve. - The function needs error detail arguments so it can take the right actions. - Errors may need a classification system, so that new errors of the same type can be handled generically in legacy code as the library evolves. - The function needs an application context argument so it has access to the data it needs to take the right actions. So, the more sophisticated C-language designs (e.g. OpenSSL or Kerberos) include an error management API. These are clearly work-arounds for lack of real exceptions. They take care to design and implement, and it may be difficult or impractical to retrofit an existing design that did not pay the price from the start, but I find claims that the exit() approach is best *on architectural grounds* rather surprising... ERR_get_error(3)OpenSSL ERR_get_error(3) NAME ERR_get_error, ERR_peek_error, ERR_peek_last_error, ERR_get_error_line, ERR_peek_error_line, ERR_peek_last_error_line, ERR_get_error_line_data, ERR_peek_error_line_data, ERR_peek_last_error_line_data - obtain error code and data SYNOPSIS #include openssl/err.h unsigned long ERR_get_error(void); unsigned long ERR_peek_error(void); unsigned long ERR_peek_last_error(void); unsigned long ERR_get_error_line(const char **file, int *line); unsigned long ERR_peek_error_line(const char **file, int *line); unsigned long ERR_peek_last_error_line(const char **file, int *line); unsigned long ERR_get_error_line_data(const char **file, int *line, const char **data, int *flags); unsigned long ERR_peek_error_line_data(const char **file, int *line, const char **data, int *flags); unsigned long ERR_peek_last_error_line_data(const char **file, int *line , const char **data, int *flags); DESCRIPTION ERR_get_error() returns the earliest error code from the thread's error queue and removes the entry. This function can be called repeatedly until there are no more error codes to return. ERR_GET_LIB(3) OpenSSL ERR_GET_LIB(3) NAME ERR_GET_LIB, ERR_GET_FUNC, ERR_GET_REASON - get library, function and reason code SYNOPSIS #include openssl/err.h int ERR_GET_LIB(unsigned long e); int ERR_GET_FUNC(unsigned long e); int ERR_GET_REASON(unsigned long e); DESCRIPTION The error code returned by ERR_get_error() consists of a library num- ber, function code and reason code. ERR_GET_LIB(), ERR_GET_FUNC() and ERR_GET_REASON() can be used to extract these. The library number and function code describe where the error occurred, the reason code is the information about what went wrong. Each sub-library of OpenSSL has a unique library number; function and reason codes are unique within each sub-library. Note that different libraries may use the same value to signal different functions and rea- sons. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
On Sun, Feb 12, 2006 at 04:45:33PM +, Ben Laurie wrote: Werner Koch wrote: On Sat, 11 Feb 2006 12:36:52 +0100, Simon Josefsson said: 1) It invoke exit, as you have noticed. While this only happen in extreme and fatal situations, and not during runtime, it is not that serious. Yet, I agree it is poor design to do this in a library. I disagree strongly here. Any code which detects an impossible state or an error clearly due to a programming error by the caller should die as soon as possible. Quite so. No, libraries don't enough to decide what's fatal. The calling process (trying to an LDAP lookup via nsswitch.conf say...) may have other reasonable sources of data, and having the library kill it is unacceptable. If you try to resolve the problem by working around it will increase code complexity and thus error won't be detected. (Some systems might provide a failsafe mechanism at a top layer; e.g. by voting between independed developed code). But this is not why: if you attempt to fix impossible states, the problem is that you cannot know why (by definition) the code is in the state you are trying to fix, or what else might be broken. Continuing to run is giving the attacker the option to make good on his exploit. Not being able to access a resource is not an impossible state. Impossible states are corruption of internal data structures, invalid function arguments, ... Failure to obtain seed data is an error and needs to be reported as such. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
On Mon, Feb 13, 2006 at 11:29:00AM +0100, Simon Josefsson wrote:
However, looking at the code, it is possible for Postfix to handle
this. They could have installed a log handler with libgcrypt, and
make sure to shut down gracefully if the log level is FATAL. The
recommendation to avoid GnuTLS because libgcrypt calls exit suggest
that the Postfix developers didn't care to investigate how to use
GnuTLS and libgcrypt properly. So I don't think there is any real
reason to change code in libgcrypt here. Postfix could be changed, if
they care about GnuTLS/libgcrypt.
Yeah, right, really easy when GnuTLS is called from the system LDAP
libraries... In any case the only way for the handler to avoid
process death is longjmp() to a context created before calling
GnuTLS/libgcrypt()... not a particularly robust solution.
void
_gcry_log_fatal( const char *fmt, ... )
{
va_list arg_ptr ;
va_start( arg_ptr, fmt ) ;
_gcry_logv( GCRY_LOG_FATAL, fmt, arg_ptr );
va_end(arg_ptr);
abort(); /* never called, but it makes the compiler happy */
}
the handler is invoked in _gcry_logv()... The Postfix TLS functionality
is built over OpenSSL (not GnuTLS) and OpenSSL has an error stack, which
the application can process as it sees fit. The libgrypt approach to
error reporting is not acceptable.
--
/\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privilege,
and use is prohibited.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
On Tue, Feb 14, 2006 at 12:44:39PM +1000, James A. Donald wrote: Absent exception handling, mission critical tasks should have no exceptions, which is best accomplished by the die-on-error standard. Absent good library design, the developer's goals are best accomplished with the roll-your-own standard. If the authors of libgrypt instead of saying sorry, we know, it is a difficult problem, we are working on it, instead become defensive and erect false dichotomies to defend the developer from his own folly, I can add libgrypt to my list of tools to avoid when building large systems. As I said before, Postfix does not use GnuTLS directly, rather it is sometimes a victim of libgrypt design via GnuTLS imbedded in the system LDAP library. The current libgrypt is IMHO not suitable for linking into LDAP libraries, database client-server communication libraries, SMTP servers... As for Postfix, it does entropy gathering out-of-process (in the tlsmgr(8) daemon). The SMTP server and client daemons get entropy indirectly from tlsmgr(8) to seed their internal PRNG. Postfix uses OpenSSL, and error conditions in OpenSSL are recoverable (Postfix can and will return 454 in response to STARTTLS, fatal errors are not appropriate in this context). Postfix makes use of error reporting hooks in MySQL, PgSQL, SASL, OpenSSL, (non-GnuTLS) OpenLDAP... none of these have been reported to abruptly terminate the calling process instead of reporting errors to the caller. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
GnuTLS (libgrypt really) and Postfix
On Fri, Feb 10, 2006 at 09:15:26AM -0800, John Gilmore wrote: Subject: GnuTLS 1.2.10 - Security release If I may be granted the segue, the Postfix documentation has recently been updated to include the following text: NOTE: Do not use Gnu TLS. It will spontaneously terminate a process with exit status code 2, instead of properly reporting problems to Postfix, so that it can log them to the maillog file. This was discovered when the Postfix cleanup(8) daemon was reported exiting in LDAP initialization. The system LDAP library was linked against GnuTLS, and /dev/urandom was missing from the chroot jail. The real culprit is libgcrypt, whose log_fatal() macro terminates the calling process. This is undesirable in a general purpose library. If the authors of GnuTLS have any influence on the design/implementation of libgcrypt, I hope they will make an effort to see this issue addressed. cipher/cipher.c: log_fatal(cipher_encrypt: invalid mode %d\n, c-mode ); cipher/cipher.c: log_fatal (cipher_decrypt: invalid mode %d\n, c-mode ); cipher/dsa.c: log_fatal(DSA:: sign, verify failed\n); cipher/elgamal.c: log_fatal(ElGamal operation: encrypt, decrypt failed\n); cipher/elgamal.c: log_fatal(ElGamal operation: sign, verify failed\n); cipher/primegen.c: log_fatal (can't generate a prime with less than %d bits\n, 16); cipher/random.c: log_fatal (failed to create the pool lock: %s\n, strerror (err) ); cipher/random.c: log_fatal (failed to create the nonce buffer lock: %s\n, cipher/random.c: log_fatal (failed to acquire the pool lock: %s\n, strerror (err)); cipher/random.c: log_fatal (failed to release the pool lock: %s\n, strerror (err)); cipher/random.c: log_fatal (failed to acquire the pool lock: %s\n, strerror (err)); cipher/random.c: log_fatal (failed to release the pool lock: %s\n, strerror (err)); cipher/random.c: log_fatal(_(can't read `%s': %s\n), seed_file_name,strerror(errno) ); cipher/random.c: log_fatal (failed to acquire the pool lock: %s\n, strerror (err)); cipher/random.c: log_fatal (failed to release the pool lock: %s\n, strerror (err)); cipher/random.c: log_fatal (_(no entropy gathering module detected\n)); cipher/random.c: log_fatal (failed to acquire the pool lock: %s\n, strerror (err)); cipher/random.c: log_fatal (failed to acquire the pool lock: %s\n, strerror (err)); cipher/random.c: log_fatal (No way to gather entropy for the RNG\n); cipher/random.c: log_fatal (failed to acquire the nonce buffer lock: %s\n, cipher/random.c: log_fatal (failed to release the nonce buffer lock: %s\n, cipher/rndegd.c: log_fatal (EGD socketname is too long\n); cipher/rndegd.c: log_fatal(can't create unix domain socket: %s\n, strerror(errno) ); cipher/rndegd.c: log_fatal(can't connect to EGD socket `%s': %s\n, cipher/rndegd.c: log_fatal(can't write to the EGD: %s\n, strerror(errno) ); cipher/rndegd.c: log_fatal(can't write to the EGD: %s\n, strerror(errno) ); cipher/rndlinux.c: log_fatal (can't open %s: %s\n, name, strerror(errno) ); cipher/rndlinux.c: log_fatal(stat() off %s failed: %s\n, name, strerror(errno) ); cipher/rndlinux.c: log_fatal(invalid random device!\n ); cipher/rndlinux.c: log_fatal(read error on random device: %s\n, strerror(errno)); cipher/rndw32.c: log_fatal ( rndw32: can't get module handle\n ); cipher/rndw32.c: log_fatal ( rndw32: failed to get a toolhelp function\n ); cipher/rndw32.c: log_fatal ( rndw32: failed to take a toolhelp snapshot\n ); cipher/rndw32.c: log_fatal(can't run on a W32s platform\n ); cipher/rsa.c: log_fatal(RSA operation: public, secret failed\n); cipher/rsa.c: log_fatal(RSA operation: secret, public failed\n); src/secmem.c: log_fatal (failed to reset uid: %s\n, strerror (errno)); src/secmem.c: log_fatal (can't allocate memory pool of %u bytes\n, src/secmem.c: log_fatal (failed to drop setuid\n); -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Nonrepudiation - in some sense
On Fri, Feb 10, 2006 at 07:49:59PM +, Ben Laurie wrote: Secondly, obviously, you can only decrypt SSL if you have the private key, so presumably this is referring only to incoming SSL connections. And only if EDH (or more generally all PFS) ciphers are disabled. This is AFAIK common with HTTP servers, but the majority of TLS capable MTAs negotiate EDH ciphers. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
