For more information about features coming to Chrome, check out the Chrome Blog.
Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug.
The Editor's analysis engine, responsible for reporting warnings and errors, is completely rewritten and is 20% faster at parsing and analyzing. Now, there’s no need to run all the unit tests just to discover a typo. The Dart Editor watches your back as you type.
In addition, Dart Editor makes it easier for developers to manage an evolving app. Some of the new features include:
Code completion has also improved. For example, completion is now camelcase aware. Type iE and Dart Editor finds isEmpty.
Finally, deploying a Dart web app is now easier, with the beta
pub deploy command. It creates a directory with your app's code and assets and prepares it for hosting on your favorite web server. You can use this command from Dart Editor or the pub command-line utility.
That's just the highlights - there are more improvements across the platform. You can read the full release notes for more details and changes. You can download the latest version of Dart Editor, including everything you need for Dart development, from dartlang.org. We look forward to your feedback!
This update covers week 24 on Intel’s work in Chromium and Blink.
During the time that the RSA patent was in force, DSA was the signature algorithm of choice for any software that didn't want to deal with patent licenses. (Which is why lots of old PGP keys are still DSA.) It has slowly disappeared since the patent expired and it appears that 4096-bit RSA is now the algorithm of choice if you're on the run from the NSA . (And if you're a journalist trying to get a reply: keyid BDA0DF3C.)
But DSA can also be used with elliptic curves in the form of ECDSA and, in that form, it's likely that we'll see it return in the future, at least to some extent. SSH and GPG both support ECDSA now and CAs are starting to offer ECDSA certificates for HTTPS.
Unfortunately, DSA has an important weakness that RSA doesn't: an entropy failure leaks your private key. If you used a machine affected by the Debian entropy bug then, in that time, messages that you encrypted with RSA can be broken. But if you signed anything with a DSA key, then your private key is compromised.
The randomness in DSA is absolutely critical. Given enough signatures, leaking just a handful bits per signature is sufficient to break it. In the limit, you can make the make the mistake that Sony did and not understand that the random number needs to be generated for each message and, seemingly, just pick one and code it in. (See XKCD.)
But it doesn't need to be this way! All that is required of the nonce is that it be unique for each distinct message and secret, and we can achieve that by hashing the message and private key together. That's what Ed25519 does and I've added the option to OpenSSL to do the same. Unlike RSA and Ed25519 signatures, DSA signatures are probabilistic - signing the same message twice with the same key will result in different signatures. Since someone may be depending on that, OpenSSL also hashes in some randomness to maintain that feature.
(p.s. if you're an actual cryptographer, please take a look at the core of the code and let me know if I'm an idiot.)
Since the DSA specification says that the nonce must be randomly generated, and compliance with the spec is important for many users, this isn't enabled by default. For ECDSA keys, one needs to call EC_KEY_set_nonce_from_hash, for example. But hopefully we can measurably improve things with little effort by doing this.
Here's an example of breaking DSA with a known nonce: essentially the Sony PlayStation hack. I've used the variable names from the Wikipedia page for those that want to follow along, although I'm not using a subgroup to keep things simple.
Let's pick some (public) DSA parameters:
p = 2903 F = GF(p) g = F(2) n = g.multiplicative_order()
Next, generate a key pair. x is the private key and y is the public key:
x = int(F.random_element()) % n y = g^x (x, y) (1282, 966)
Generate our nonce, which will be fixed for two different messages in this example:
k = int(F.random_element()) % n kInv = inverse_mod(k, n)
The first message that we sign will be 42 and the pair (r, s) is the signature. (Normally the message would be a hash of a much larger message.) The signature is very simple: r is gk and s is (m + xr)/k:
m = 42 r = int(g^k) % n s = ((m + x*r) * kInv) % n (r, s) (1401, 1168)
As an aside, we can verify the signature that we just made:
w = inverse_mod(s, n) u1 = m*w u2 = r*w v = g^u1*y^u2 v == r True
Next, we also sign the message 24 (which I'll call mm) and we gather the two signatures. We have s and ss, both with the same r. Since s = (m + xr)/k, we can subtract the two to get (m + xr - mm - xr)/k, which is just (m - mm)/k. Thus k = (m - mm)/(s - ss). Given k, we can rearrange the original equation for s: s = (m + xr)/k ⇒ sk = m + xr ⇒ sk - m = xr ⇒ (sk - m)/r = x. And thus we have the private key:
(r, s) = (1401, 1168) (r, ss) = (1401, 1212) kk = ((42 - 24)*inverse_mod(s-ss,n)) % n xx = ((s*kk - 42) * inverse_mod(r, n))%n print xx == x xx True 1282
getUserMediato access your webcam and microphone (with your permission, of course),
RTCPeerConnectionto stream your video to a friend, and
RTCDataChannelto transfer the bits that keep the gameplay in sync. If you and your friend are behind firewalls,
RTCPeerConnectionuses a TURN relay server (hosted on Google Compute Engine) to make the connection. However, when there are no firewalls in the way, the entire game happens directly peer-to-peer, reducing latency for players and server costs for developers.
RTCDataChannel, which provides an API similar to WebSocket, but sends the data over the
RTCDataChannelsends data securely, and supports an "unreliable" mode for cases where you want high performance but don't care about every single packet making it across the network. In cases like games where low delay often matters more than perfect delivery, this ensures that a single stray packet doesn't slow down the whole app.
RTCDataChannelsupports unreliable mode in desktop Chrome today. We're working on implementing the latest WebRTC spec, where we'll use the standard SCTP protocol to support reliable mode as well. WebRTC will also be available on Chrome for Android later this year, and you can try it now by flipping “Enable WebRTC Android” in chrome://flags. Several browsers are currently working on implementing WebRTC, and we’re looking forward to the day when you can have a Cube Slam face-off against your friends on any browser and any device.
This update covers week 23 on Intel’s work in Chromium and Blink.
This update covers week 22 on Intel’s work in Chromium and Blink.