BitFolk Users March 2016

users@mailman.bitfolk.com

7 participants
3 discussions

Dear Entropy service users, what software uses /dev/random?

by Andy Smith

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

6 years, 2 months

Routing issues anyone?

by Tony Andersson

Hi you clever people, Is there anyone else experiencing any routing issues at the moment? Two of my sites have been very hard to reach during the evening (or possibly longer, haven't checked earlier) 22:20:21$ ping 85.119.83.157 PING 85.119.83.157 (85.119.83.157) 56(84) bytes of data. From jack.bitfolk.com (85.119.80.20) icmp_seq=1 Destination Host Unreachable C:\Users\Tony>ping 85.119.83.157 Pinging 85.119.83.157 with 32 bytes of data: Reply from 85.119.83.157: bytes=32 time=420ms TTL=59 Reply from 85.119.80.20: Destination host unreachable. 22:47:10$ ping 85.119.83.157 PING 85.119.83.157 (85.119.83.157) 56(84) bytes of data. 64 bytes from 85.119.83.157: icmp_seq=1 ttl=62 time=0.180 ms (and so on) 22:54:44$ ping 85.119.83.157 PING 85.119.83.157 (85.119.83.157) 56(84) bytes of data. From 85.119.80.20 icmp_seq=1 Destination Host Unreachable No changes to any routing tables or some such has happened, and the two machines I am trying with are in two completely different locations. Linux machine is in the Bitfolk network, just like the intermittently unreachable machine. Another IP, 188.40.132.132, is unreachable tonight too. Seems like a bit of too much a coincidence for this to happen at the same time, so I thought I'd better ask the vast expertise here if it's just me. Probably is! :-P Cheers, __ /ony

8 years, 1 month

We will be charging for additional IPv4 addresses on a recurring basis from Monday 14th March 2016

by Andy Smith

Hi, If you just have the one IPv4 address on your VPS then you can safely stop reading as nothing is going to change for you. As for the 11% of paying customers who do have more than one IPv4 address, read on… For a long time now I have been unsatisfied with our policies for granting requests for additional IPv4 addresses. For the last 9 years we've done what was considered the proper thing in a world where available IPv4 addresses were running low: we haven't charged for additional IPv4 addresses, we've only asked customers to technically justify their requests. That had a number of problems: - It's often very difficult to pin a customer down on what exactly it is they're doing. The ideal scenario where one network engineer talks to another about requirements is rarely the case here. This very often left me in a position where I wasn't convinced that use of extra IPv4 addresses was technically required, but it's what the customer wanted and the sale depended upon it. There is no sane administrative fee that could be charged that would cover that amount of work. - Once a request was granted it has been very difficult to audit. There has been no incentive for customers to return IPv4 addresses that they are no longer using. - I don't know of another company in this same space that is bothering to require technical justification for IPv4 use. - We're no longer in a world where IPv4 is running out. IPv4 has already run out. The point of recording why any given IPv4 address was in use was for the case where BitFolk had to go back to RIPE to ask for more IPv4. Those records would have been used to prove that the IPv4 allocation that BitFolk already has really is all used up. BitFolk won't be going back to RIPE because there's no IPv4 left to go back for. We just have to manage what we have. So, from Monday 14th March we're going to start charging for each IPv4 address after the first one. The charge will be £0.50+VAT per IPv4 per month (£1.40+VAT per quarter or £5.00+VAT per year). This will take effect immediately for new signups, but existing customers will only see it on invoices falling due on or after 14th March. Those with PayPal subscriptions will have the subscriptions altered, and those with Direct Debit authorisation will see the authorisation cancelled (they're for a fixed amount) so will need to re-authorise. If you're paying monthly or quarterly and your next bill falls due some time between now and March 14th you could consider switching to yearly, as you then won't be charged for this until that year runs out. You'd therefore save £6.00+VAT per IPv4 per year (£0.50 x 12 monthly payments). I should point out that (under either this or the previous regime) BitFolk is not in any realistic danger of running out of IPv4 addresses; this is just about managing what we already have in a better, fairer and more transparent way which is also more in line with customer expectations. IPv6 /64s and /56s remain entirely free and there are no plans to change that. If there is something I have forgotten to cover, please do let us know, either by replying here to to support(a)bitfolk.com. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting "It is I, Simon Quinlank. The chief conductor on the bus that is called hobby." — Simon Quinlank _______________________________________________ announce mailing list announce(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/announce

8 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

BitFolk Users March 2016