Hi,
If you do not use BitFolk's Entropy service and have no interest in
doing so then this email will be of little interest to you can be
safely ignored.
If you haven't heard about the Entropy service before, please see:
https://tools.bitfolk.com/wiki/Entropy
If you *do* use the Entropy service though, I'm interested to know
what software you have that actually uses /dev/random (and not
/dev/urandom).
Some background to this question:
To provide the Entropy service we use hardware entropy generators,
currently exclusively a pair of EntropyKeys manufactured by a UK
company called Simtec Electronics Ltd.
Despite the fact that these were extremely popular little devices
(compared to other fairly niche little gadgets), Simtec always had a
supply problem and then Simtec imploded as a company, so as far as I
know these are now impossible to obtain, the IP is lost forever etc.
Although I have one spare EntropyKey ready to put in service should
one of the two in service ever die (I've not experienced that yet),
that left me slightly worried as to what I'd do if I needed to get
more.
Then I saw the OneRNG kickstarter, and decided to pledge. So now I
have 5 of (the internal USB version of) these:
http://onerng.info/
I've not yet gone any further than verifying that they keep the
entropy pool full on the machine they're plugged into, but that's
good enough for now. Could be a decade before one of my existing
EntropyKeys dies.
I have since heard that this device proved far more popular than its
manufacturer expected (sense a theme?) and they're now extremely
difficult to get hold of because they need to get a new batch made
in China. I've had multiple people contacting me on the basis of a
tweet I did about getting these, asking me to sell them mine (which
I would, but they didn't want internal USB).
The point I'm trying to make here is that the world of hardware
random number generators is not one with reliable supply lines,
unless you want to spend a fortune on some black box.
So when I came across:
http://www.2uo.de/myths-about-urandom/
I was sad that the nerdery that is the Entropy service may be
misguided, but also happy with the possibility that I might never
have to source a hardware RNG again.
Let's just take the argument posited by the article, that all
(Linux) software should just learn to love /dev/urandom¹, as true.
If you don't agree with this claim, you are disagreeing with some
pretty big names in crypto. The Hacker News commentary on the
article may also prove of interest:
https://news.ycombinator.com/item?id=10149019
At the very least, I feel the Entropy article on the BitFolk Wiki
needs an update in light of this. To justify the service's
existence, if nothing else.
Going further, the question becomes, well, what software is there in
existence that forces use of /dev/random with no configuration that
would allow otherwise? Because even if we agree that all software
*should* be using urandom, if some popular software *refuses* to
without recompile, then we're still going to have to provide an
Entropy service, because doing so is easier than running
non-packaged software.
So Entropy service users, what have you got that uses /dev/random?
Cheers,
Andy
¹ A more correct summary of it is probably, "urandom is fine all the
time except for on initial boot when a small amount of entropy
from outside the CSPRNG is desirable."
On shutdown all fairly modern Linuxes save the current entropy
pool to the filesystem and load it up from there on boot, so it's
only essential on first boot.
--
http://bitfolk.com/ -- No-nonsense VPS hosting
This might be more support-related, but has anyone set up delegated
reverse DNS for IPv6 with "all-knowing-dns"?
It handles PTR and AAAA records on the fly and lets me avoid doing the
whole zone-file thingy. But I'm uncertain about this bit :
"Please bear in mind that the zone
e.f.2.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa should already exist on all the
nameservers you list."
Can I use "all-knowing-dns" as an easy fix?
$ apt-cache show all-knowing-dns
Package: all-knowing-dns
Version: 1.7-1
Installed-Size: 38
Maintainer: Debian Perl Group <pkg-perl-maintainers(a)lists.alioth.debian.org>
Architecture: all
Depends: init-system-helpers (>= 1.11), perl, libmouse-perl,
libmousex-nativetraits-perl, libnet-dns-perl, libnetaddr-ip-perl,
libprivileges-drop-perl
Description-en: tiny DNS server for IPv6 Reverse DNS
AllKnowingDNS provides reverse DNS for IPv6 networks which use SLAAC
(autoconf), e.g. for a /64 network.
.
The problem with IPv6 reverse DNS and traditional nameservers is that the
nameserver requires you to provide a zone file. Assuming you want to
provide
RDNS for a /64 network, you have 2**64 = 18446744073709551616
different usable
IP addresses (a little less if you are using SLAAC). Providing a zone
file for
that, even in a very terse notation, would consume a huge amount of
disk space
and could not possibly be held in the memory of the computers available
nowadays.
.
AllKnowingDNS instead generates PTR and AAAA records on the fly. You only
configure which network you want to serve and what your entries should
look
like.
Description-md5: 1df6f6c08cc7056f9106168642d482b9
Homepage: https://metacpan.org/release/AllKnowingDNS/
Section: perl
Priority: optional
Filename: pool/main/a/all-knowing-dns/all-knowing-dns_1.7-1_all.deb
Size: 22260
MD5sum: 8f70307d17b1690e293595ecd349c436
SHA1: 5c9002dacf99bd5085d8e7ebfdc3f247d8a2287d
SHA256: 712b360eb1830fa175a8b476276979212dd6405987b4c859e5651c377346aac8
Hi,
Two-factor authentication for the BitFolk Panel and Xen Shell has
long been requested¹, and is finally now implemented. If you wish to
enable it please visit the "Security" section of the Panel to do so:
https://panel.bitfolk.com/account/security/
You should hopefully find the process straightforward. If you don't,
please let us know.
Thanks to the requesters and those who've been helping to test it
over the last ~week. For those who've been testing: I've disabled it
on your live account but left the key data there. If you don't want
to re-use the same key you can just invalidate it and generate
another one.
Cheers,
Andy
¹ https://tools.bitfolk.com/redmine/issues/117
PS It's worth looking over the list of outstanding feature requests
and seeing if there's any you'd like to vote for as it's nice to
know what is important to you.
https://tools.bitfolk.com/redmine/issues?query_id=1 (log in with
your usual BitFolk credentials if you want to vote / update
anything)
--
http://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hi,
Implementing two-factor authentication has long been a requested
feature:
https://tools.bitfolk.com/redmine/issues/117
I have implemented it on the panel test site at
https://testpanel.bitfolk.com and would really appreciate if those
who are interested in 2FA would give it a go to see if it works how
you want/expect.
If test site is currently pointed at the real database so changes
you make will be for real, although the real panel site does not
have 2FA deployed so you cannot lock yourself out of anything
important. I will purge all TOTP keys and set everyone back to
having TOTP disabled before it goes live.
If you have any comments then adding them to the feature tracker
(link above) would be appreciated.
Note that 2FA on the web panel is pretty pointless without also
having 2FA or similar on the SSH to Xen Shell. I am as yet undecided
about where to go with that (only that it needs to go somewhere). I
don't know whether it's acceptable to just have an option to restrict
it to SSH key auth only, or if the same 2FA should be used there
(there is a PAM module for TOTP 2FA:
https://packages.debian.org/jessie/libpam-google-authenticator)
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
Anyone else having routing problems? I'm unsure if it's me, as my ISP
has been having issues today so it could very easily be my end, but I
can't get to bitfolk from some locations, my packets seem to be getting
lost somewhere in zayo.com:
mstevens@mstevens-Vostro-460:~ % traceroute etla.org
traceroute to etla.org (85.119.82.193), 30 hops max, 60 byte packets
1 gateway (192.168.1.1) 0.294 ms 0.398 ms 0.510 ms
2 192.168.10.85 (192.168.10.85) 2.576 ms 2.606 ms 2.637 ms
3 172.30.4.135 (172.30.4.135) 10.433 ms 11.886 ms 14.330 ms
4 mai.b2.edge.as200876.rs.uk.evolving.net.uk (82.145.32.89) 16.494 ms 16.926 ms 11.980 ms
5 1717.net1.north.dc5.as20860.net (87.117.210.25) 35.128 ms 34.351 ms 35.158 ms
6 be3.asr01.thn.as20860.net (62.233.127.173) 18.842 ms 19.629 ms 19.581 ms
7 ae6.mpr1.lhr15.uk.zip.zayo.com (94.31.48.85) 19.650 ms 11.177 ms 10.736 ms
8 ae5.mpr2.lhr2.uk.zip.zayo.com (64.125.21.9) 12.184 ms 12.775 ms 13.125 ms
9 ae10.mpr1.lhr1.uk.zip.zayo.com (64.125.31.193) 16.533 ms 16.117 ms 16.703 ms
10 * * *
It works from other places, which is how I'm sending this email...
Michael
