Re: Intel to also add RNG
On Mon, 12 Jul 2010, Ben Laurie wrote: On 2 July 2010 13:19, Eugen Leitl wrote: http://www.technologyreview.com/printer_friendly_article.aspx?id=25670&channel=Briefings§ion=Microprocessors Tuesday, June 29, 2010 Nanoscale Random Number Circuit to Secure Future Chips Intel unveils a circuit that can pump out truly random numbers at high speed. Have they forgotten the enormous amount of suspicion last time they tried this? I love how they pretend to be the first ones with this, totally ignoring others who have had this for years, such as the VIA PadLock. The article lists NIST having done tests, but does not mention any CPU model where this is on. Anyone knows? Paul - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Intel to also add RNG
On Mon, 12 Jul 2010, Eric Murray wrote: Then there's FIPS- current 140 doesn't have a provision for HW RNG. They certify software RNG only, presumeably because proving a HW RNG to be random enough is very difficult. So what's probably the primary market (companies who want to meet FIPS) isn't available. So you can do HWRNG -> SWRNG -> Fips ? Which is what you should do anyway, in case of a hardware failure. I know the Linux intel-rng and amd-rng used to produce nice series of zeros. The padlock rng has never produced warnings piping it through rngd. So while I think it'd be great to have a decent RNG on chip (no more blocking on /dev/random!) I don't see it being much of a market advantage and would not be surprised if it never makes it in to a shipping product. With every phone doing crypto these days, I'd think you are wrong. Also, the VIA PadLock already ships with an HWRNG on die. It's been shipping for years. Paul - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Fw: Root Zone DNSSEC Deployment Technical Status Update
On Fri, 16 Jul 2010, Taral wrote: Neat, but not (yet) useful... only these TLDs have DS records: The rest will follow soon. And it is not that you had to stop those TLD trust anchors just now. Several are using old SHA-1 hashes... "old" ? Paul - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
SHA256 reduced to 112 bits?
Hi, I've heard rumors of an attack on the SHA-2 family reducing complexity of SHA256 to something less or equal of 112 bits. This attack will apparently be announced in a few days - perhaps at Black Hat or Def Con? I would be interested in knowing more. Paul - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Persisting /dev/random state across reboots
On Thu, 29 Jul 2010, Richard Salz wrote: At shutdown, a process copies /dev/random to /var/random-seed which is used on reboots. Is this a good, bad, or "shrug, whatever" idea? I suppose the idea is that "all startup procs look the same" ? "better then not". A lot of (pseudo)random comes from disk or network interrupts. These are often similar during stock system startup. It is even more important if there is no harddisk but flashdisk, which is not contribting to entropy of the system. This was a big issue for "openwrt" (a Linux on Linksys routers) which booted so similarly every time that there was not enough random left at all. By saving the entropy from a longer run system at shutdown, you increase the entropy of the next boot by adding randomness from the previous state(s) Paul - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: GSM eavesdropping
On Mon, 2 Aug 2010, Perry E. Metzger wrote: For example, in the internet space, we have http, smtp, imap and other protocols in both plain and ssl flavors. (IPSec was originally intended to mitigate this by providing a common security layer for everything, but it failed, for many reasons. Nico mentioned one that isn't sufficiently appreciated, which was the lack of APIs to permit binding of IPSec connections to users.) If that was a major issue, then SSL would have been much more successful then it has been. I have good hopes that soon we'll see use of our new biggest cryptographically signed distributed database. And part of the signalling can come in via the AD bit in DNSSEC (eg by adding an EDNS option to ask for special additional records signifying "SHOULD do crypto with this pubkey") The AD bit might be a crude signal, but it's fairly easy to implement at the application level. Requesting specific additional records will remove the need for another latency driven DNS lookup to get more crypto information. And obsolete the broken CA model while gaining improved support for SSL certs by removing all those enduser warnings. Paul - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: GSM eavesdropping
On Mon, 2 Aug 2010, Nicolas Williams wrote: If that was a major issue, then SSL would have been much more successful then it has been. How should we measure success? "The default mode for any internet communication is encrypted" By that measure TLS has been so much more successful than IPsec as to prove the point. I never claimed IPsec was more successfulIt was not. Of course, TLS hasn't been successful in the sense that we care about most. TLS has had no impact on how users authenticate (we still send usernames and passwords) to servers, and the way TLS authenticates servers to users turns out to be very weak (because of the plethora of CAs, and because transitive trust isn't all that strong). Let's first focus on foiling the grand scale of things by protecting against passive attacks of large scale monitoring. Then let's worry about protecting against active targetted attacks. But note that the one bit you're talking about is necessarily a part of a resolver API, thus proving my point :) Yes, but in some the API is pretty much done. If you trust your (local) resolver, the one bit is the only thing you need to check. You let the resolver do most of the bootstrap crypto. One you have that, your app can rip out most of the X.509 nonsense and use the public key obtained from DNS for its further crypto needs. ...but we grow technologies organically, therefore we'll never have a situation where the necessary infrastructure gets deployed in a secure mode from the get-go. This necessarily means that applications need APIs by which to cause and/or determine whether secure modes are in effect. But by now, upgrades happen more automatic and more quickly. Adding something new to DNS won't take 10 years to get deployed. We've come a long way. It's time to reap the benefits from our new infrastructure. Paul - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: /dev/random and virtual systems
On Mon, 2 Aug 2010, Yaron Sheffer wrote: In addition to the mitigations that were discussed on the list, such machines could benefit from seeding /dev/random (or periodically reseeding it) from the *host machine's* RNG. This is one thing that's guaranteed to be different between VM instances. So my question to the list: is this useful? Is this doable with popular systems (e.g. Linux running on VMWare or VirtualBox)? Is this actually being done? Both xen and kvm do not do this currently. It is problematic for servers. Paul - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: 2048-bit RSA keys
On Tue, 17 Aug 2010, Steven Bellovin wrote: They also suggest that a 3-4 year phase-out of 1024-bit moduli is the proper course. Note that this is because they take into consideration that secrets have to be unbreakable for decade(s), which is not the case for all uses of RSA. For example in DNSSEC, a key can be rolled in a matter of hours or days. Paul - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
On Thu, 26 Aug 2010, d...@geer.org wrote: > as previously mentioned, somewhere back behind everything else ... there > is strong financial motivation in the sale of the SSL domain name digital > certificates. > While I am *not* arguing that point, per se, if having a better solution would require, or would have required, no more investment than the accumulated profits in the sale of SSL domain name certs, we could have solved this by now. Currently, the IETF keyassure WG is working on specifying how to use DNS(SEC) to put the certs in the DNS to avoid the entire CA authentication. It seems to be deciding on certs (not raw keys/hashes) to simplify and re-use the existing TLS based implementations (eg HTTPS) Paul - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: 2048 bits, damn the electrons! [...@openssl.org: [openssl.org #2354] [PATCH] Increase Default RSA Key Size to 2048-bits]
On Thu, 30 Sep 2010, Thor Lancelot Simon wrote: That would only happen if we (as security experts) allowed web developers to believe that the speed of RSA is the limiting factor for web application performance. At 1024 bits, it is not. But you are looking at a factor of *9* increase in computational cost when you go immediately to 2048 bits. At that point, the bottleneck for many applications shifts, particularly those which are served by offload engines specifically to move the bottleneck so it's not RSA in the first place. I'm sure its nothing compared to the 3 layers of url shorter redirects and their latency :P Also, consider devices such as deep-inspection firewalls or application traffic managers which must by their nature offload SSL processing in order to inspect and possibly modify data You mean it will be harder for MITM attacks on SSL. Isn't that a good thing? :P This too will hinder the deployment of "SSL everywhere", and handwaving about how for some particular application, the bottleneck won't be at the front-end server even if it is an order of magnitude slower for it to do the RSA operation itself will not make that problem go away. The SSL everywhere problem has been a political one, not a technical one. I am sure the "free market" can deal with putting SSL everywhere, if that expectation has come from every internet user - instead of that internet user clicking away many warnings about self signed certs, redirects and SSL man-in-the-middle "protection". Paul - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Disk encryption advice...
On Fri, 8 Oct 2010, 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? Use a VM based solution where the Windows images are stored on a NAS that uses disk encryption (and requires an admin when it would reboot), yet the Windows based VM's would need no disk encryption supported whatsoever. My laptop for instance is running Fedora with whole disk encryption, and I run various Windows VM's that have their image stored on that encrypted disk. Paul - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
On Sat, 7 Sep 2013, Gregory Perry wrote: Insecure DNS deployments are probably in the top five attack vectors for remotely compromising internal network topologies, even those sporting split DNS configurations. As you were "...deeply involved in the IETF's DNSEXT working group" then I presume you know this. Correct me if I am wrong, but in my humble opinion the original intent of the DNSSEC framework was to provide for cryptographic authenticity of the Domain Name Service, not for confidentiality (although that would have been a bonus). Yes that was the original intent, but I remember the reason for optin was that it was impossible to realisticly fit the .com zone in the RAM of modern servers at the time. Also signing would have taken much longer to generate all the NSEC(3) records. In general, the TLDs preferred a phased-in deployment where they could exchange hardware over time. That is what optin offered, at the expense of making spoofing just a tiny bit harder instead of much harder for non-DNSSEC domains. Seems like a normal economical based decision to me. These days, I don't think anyone should still run with opt-in anymore. There are many different camps within the DoD. About as many as we have cryptography and cypherpunks mailing lists :P Paul ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] "Is DNSSEC is really the right solution?" [djb video]
On Sun, 8 Sep 2013, Daniel Cegiełka wrote: Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" http://www.youtube.com/watch?v=K8EGA834Nok Is DNSSEC is really the right solution? That is the most unprofessional talk I've seen djb give. He bluffed a bunch of fanboys with no knowledge of DNSSEC that it was bad. His claims about caching, amplification, etc were completely wrong, as Kaminsky and I spend pointing out in the days after that CCC talk. http://dankaminsky.com/2011/01/05/djb-ccc/ http://dankaminsky.com/2011/01/07/cachewars/ He seems to mostly egage in DNSSEC bashing to advertise his curve25519, dnscurve and his "curve25519 the entire internet" ideas. The easiest number to debunk was the DNS cache hit rate. The day after his talk I collected statistics from the CCC event itself, A large Dutch ISP and one of the largest American ISPs, and the numbers were above 80% at minimum and close to 99% for the dns cache at the CCC itself. His suggestion to pollute port 53 with non-DNS traffic, and to kill DNS data authentication and replace it with transport-only security have always been rejected by the community at large as insane. His proposal to DDOS all DNS servers by making them perform crypto isn't very realistic for deployments either. DNSSEC is the result of a lot of fundamental design goals such as "100% backwards compatibility", data authenticity, offline crypto signing, crypto agility, not bypassing the cache infrastructure, etc etc. Do I trust curve25519 more then the NIST curves? Yes I do. Do I think djb should design internet protocols. No. DNSSEC is a very secure and reasonable compromise for all the requirements various parties had to secure the DNS. If you believe that is not the case, please speak out with verifiable technical arguments, and not with video hype. And I'll gladly take the time to explain things. Paul ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] History and implementation status of Opportunistic Encryption for IPsec
History and implementation status of Opportunistic Encryption for IPsec NOTE: On September 28, there is be a memorial service in Ann Arbour for Hugh Daniel, manager of the old IPsec FreeS/WAN Project. Various crypto people will attend, including a bunch of us from freeswan. Hugh would have loved nothing better than his memorial service being used as a focal point to talk about "new OE", so that's what we will do on Saturday and Sunday. If you are interested in attending, feel free to contact me. In light of the NSA achievements, a few people asked about the FreeS/WAN IPsec OE efforts and whatever happened to it. The short answer is, we failed and got distracted. The long answer follows below. At the end I will talk about the current plans that have lingered in the last two years to revive this initiative. Below I will use the word "we" a lot. Its meaning changes based on the context as various communities touched, merged, intersected and drifted apart. OE in a nutshell For those not familiar with IPsec OE as per FreeS/WAN implementation. When activated, a host would install a blocking policy for 0.0.0.0/0. Every packet to an IP address would trigger the kernel to hold the packet and signal the IKE daemon to go find an IPsec policy for that destination. If found, the tunnel would be build, and an IPsec tunnel to the remote IP would be established, and packets would flow. If no policy was found, a "pass" hole was poked so packets would go out unencrypted. Public keys for IP addresses were looked up in the reverse DNS by the IKE daemon based on the destination address. To help with roaming clients (roadwarriors), initiators could store their public key in their FQDN, and convey their FQDN as ID when performing IKE so the remote peer could look up their public key in the forward DNS. This came at the price of two dynamic clients not being able to do OE to each other. (turns out they couldn't anyway, because of NAT) What were the reasons for failing to encrypt the internet with OE IPsec (in no particular order) 1) Fragmentation of IPsec kernel stacks In part due to the early history of FreeS/WAN combined with the export restrictions at the time. Instead of spending more time on IKE and key management for large scale enduser IPsec, we ended up wasting a lot of time fixing the FreeS/WAN KLIPS IPsec stack module for each Linux release. Another IPsec stack, which we dubbed XFRM/NETKEY appeared around 2.6.9 and was backported to 2.4.x. It was terribly incomplete and severely broken. With KLIPS not being within the kernel tree, it was never taken into account. XFRM/NETKEY remained totally unsuitable for OE for a decade. XFRM/NETKEY now has almost all functionality needed - I found out today it shoudl finally have first+last packet caching for dynamic tunnels, which are essential for OE. Since the application's first packet triggered the IKE mechanism, the application would start retransmitting before IKE was completed. Even when the tunnel finally came up, the application was usually still waiting on that TCP retransmit. David McCullough and I still spend a lot of time fixing up KLIPS to work with the current Linux kernel. Look at ipsec_kversion.h just to see what a nightmare it has been to support Linux 2.0 to 2.6 (libreswan removed support for anything lower then recent 2.4.x kernels) Linux IPsec Crypto hardware acceleration in practise is only possible with KLIPS + OCF, as the mainstraim async crypto is lacking in hardware driver support. If you want to build OE into people's router/modem/setup box, this is important, though admittingly less so as time has moved on and even embedded hardware and phones are multicore or have special crypto CPU instructions. An effort to make the kernel the sole provider of crypto algorithms that everyone could use also failed, and the idea was abandoned when CPU crypto instructions appeared directly accessable from userland. 2) US citizens could not contribute code or patches to FreeS/WAN This was John Gilmore's policy to ensure the software remained free for US citizens. If no US citizen touched the code, it would be immune to any presidential National Security Letter. I believe this was actually the main reason for KLIPS not going in mainstream kernel, although personal egos of kernel people seemed to have played a role here as well. Freeswan people really tried had in 2000/2001 to hook KLIPS into the kernel just the way the kernel people wanted. (Ironically, the XFRM/NETKEY hook so bad, it even confuses tcpdump and with it every sysadmin trying to see whether or not their traffic is encrypted) I still don't fully understand why it was never merged, as the code was GPL, and it should have just been merged in, even against John's wishes. Someone would have stepped in as maintainer - after all the initial brunt of the work had been done and we had a functional IPsec stack. In the summer of 2003, I talked to John
Re: [Cryptography] [cryptography] very little is missing for working BTNS in Openswan
On Thu, 12 Sep 2013, Nico Williams wrote: Note: you don't just want BTNS, you also want RFC5660 -- "IPsec channels". You also want to define a channel binding for such channels (this is trivial). To summarize: IPsec protects discrete *packets*, not discrete packet *flows*. This means that -depending on configuration- you might be using IPsec to talk to some peer at some address at one moment, and the next you might be talking to a different peer at the same address, and you'd never know the difference. IPsec channels consist of ensuring that the peer's ID never changes during the life of a given packet flow (e.g., TCP connection). BTNS pretty much requires IPsec configurations of that make you vulnerable in this way. I think it should be obvious now that "IPsec channels" is a necessary part of any BTNS implementation. This is exactly why BTNS went nowhere. People are trying to combine anonymous IPsec with authenticated IPsec. Years dead-locked in channel binding and channel upgrades. That's why I gave up on BTNS. See also the last bit of my earlier post regarding Opportunistic Encryption. We can use IDs to identify "anonymous" and sandbox these connections. If you want authenticated IPsec, use a different loaded policy that has nothing to do with OE IPsec. In libreswan terms: conn anonymous right=yourip rightid=@serverid rightrsasigkey=0xAQ[] left=%any leftid=@anonymous leftrsasigkey=%fromike conn admin [all your normal X.509 authentication stuff] Merging these into one, is exactly why we got transport mode, authenticated header,IKEv2 narrowing and a bunch of BTNS drafts no one uses. Stop making crypto harder! Paul ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
