The following Dart program reads random bits from /dev/random, and prints them:

import 'dart:io';

main() {
  new File('/dev/random').open().then((file) {
      file.read(20)
          .then((bytes) => print(bytes))
          .then((_) => file.close());
  });
}

I think this is sufficient, and if there is another random source only available through a native call, then a native extension can be written. So I would suggest closing this issue as "NotPlanned" or "WorkingAsIntended".

As an aside, I think cryptography should be done using native cryptography libraries where possible, especially OS-provided capabilities, or using supported packages.
Writing cryptographic encoding/decoding code in Dart is a sign that something is wrong - efficient access to the system cryptography or to fast native implementations should be provided.

Removed Type-Defect, Priority-Unassigned labels.
Added Type-Enhancement, Priority-Low, Area-IO, Triaged labels.

This comment was originally written by izaer...@gmail.com

The proposed code does not work client-side. Nor do native libraries.

Writing crypto code in Dart is not wrong. It depends on many considerations and the specific scenario. For example:

-How much you trust your underlying operating system/browser crypto APIs.
-If you are running on server or client.
-If you want to have a 100% Dart non-native solution (same controversies happened time ago with 100% Java and JDBC drivers, for instance).
-Etc.

There are already implementations of crypto in Javascript because they are needed in some specific scenarios (for an example look at Lastpass service). Why not in Dart?

Having a language/platform where it is impossible to run crypto algorithms in version 1.0 does not seem very useful in my opinion.

Said that, I understand the need for native solutions to achieve good performance. But crypto is not only about performance, there are more thinks to take into account.

Removed Priority-Low, Area-IO labels.
Added Priority-Unassigned, Area-Library labels.

The ideal would be to expose the cryptographic primitives of browsers. This should include the random-generator. Most users would use the provided functionality, but others could build on top of the source.

This doesn't have high priority now, though.
Note: in order to support this functionality in browsers different than Dartium, it would also needed to be exposed by JS. I'm not sure if this is already happening, or if there are plans for this.

This comment was originally written by iza...@gmail.com

Seems like there's some ongoing work to standardize crypto in JS: http://www.w3.org/TR/WebCryptoAPI/

See also

https://developer.mozilla.org/en-US/docs/Web/API/window.crypto.getRandomValues
https://api.dartlang.org/docs/channels/stable/latest/dart_html/Crypto.html#getRandomValues

This comment was originally written by @stevenroose

Any update on this?

As I'm porting a Bitcoin library to Dart, having strong randomness is crucial for security, so I'd really appreciate native support for this that works both in the DVM as with dart2js.

This is a duplicate of issue #1746 . The support comes from the embedder, so it will be in dart:io in the standalone vm, and in dart:html in the browser. It is already supported in dart:html Crypto.getRandomValues, so we just need dart:io support.

Providing more cryptographic operations, beyond the secure RNG, is now the job of package:crypto, at https://github.com/dart-lang/crypto

See also #1746