On 31 October 2017 at 11:48, Eric McCorkle wrote:
> On 10/30/2017 04:05, Julian Elischer wrote:
>> On 29/10/17 8:36 am, Eric McCorkle wrote:
>>> On 10/28/2017 09:15, Poul-Henning Kamp wrote:
In message <20171028123132.gf96...@kduck.kaduk.org>, Benjamin Kaduk
writes:
>>
On 29 October 2017 at 15:17, Eric McCorkle wrote:
> On 10/29/2017 09:46, bf wrote:
>> On 10/29/17, Poul-Henning Kamp wrote:
>>>
>>> In message , Eric
>>> McCorkl
>>> e writes:
On 10/28/2017 09:15, Poul-Henning Kamp wrote:
>
> In message <20171028123132.gf96...@kduck
On 27 October 2017 at 20:24, Poul-Henning Kamp wrote:
>
> In message
>
> , Ben Laurie writes:
>
>>OpenSSL includes (and is used for) lots of crypto that is not used in
>>SSL - since BearSSL targets SSL/TLS only, it can't, presumably, be
>>used to
On 27 October 2017 at 01:29, Eric McCorkle wrote:
> I was going to wait a bit to discuss this, but it's very pertinent to
> the trust infrastructure I described earlier this week.
>
> There was a good bit of discussion at vBSDCon about a possible crypto
> overhaul. This is my understanding of the
ECAPMODE means the syscall is forbidden, surely?
On 26 September 2017 at 20:37, Shawn Webb wrote:
> Hey All,
>
> I'm working on applying Capsicum to Tor. I've got a PoC design for how
> I'm going to do it posted here:
>
> https://github.com/lattera/PoCs/tree/master/capsicum_fdpassing
>
> Note tha
On 18 July 2014 00:41, Steven Chamberlain wrote:
> So I wonder, could a simplified arc4random for FreeBSD use Yarrow
> directly, to avoid making any of these sorts of mistakes we've seen?
Discovering that its OK to use this mechanism seems as vulnerable to
mistakes as the mistakes we've seen. I d
On 3 July 2014 17:07, Jonathan Anderson wrote:
> Eitan Adler wrote:
>>
>> Perhaps we should remove HTTPS support from libfetch and require the
>> user to install wget or curl if they want to use SSL? Having a
>> *default* certificate bundle (that could be removed / edited, of
>> course) is not ne
On 11 June 2014 13:14, Dan Lukes wrote:
> On 06/11/14 11:32, Ben Laurie:
>
>> Going forward we would only maintain two versions, so when 1.0.3 comes
>> out, 1.0.1 would be EOL.
>
>
> So, the date of EOL of 1.0.1 will not be known. Just some day the 1.0.3 will
> be re
We (the OpenSSL team) are considering a more aggressive EOL strategy.
In particular, we may EOL 0.9.8 right now, and 1.0.0 when 1.0.2 comes
out (currently in beta).
Going forward we would only maintain two versions, so when 1.0.3 comes
out, 1.0.1 would be EOL.
What do people think about this?
__
On 25 April 2014 22:38, Chad Perrin wrote:
> On Fri, Apr 25, 2014 at 09:52:25PM +0100, Ben Laurie wrote:
>> On 25 April 2014 21:46, Poul-Henning Kamp wrote:
>> > In message
>> >
>> > , Ben Laurie writes:
>> >>On 25 April 2014 21:24, Ronald F. Gui
On 25 April 2014 22:21, Ronald F. Guilmette wrote:
>
> In message
>
> Ben Laurie wrote:
>
>>But that would then hide the error condition of it being not set to a
>>new value after initialisation.
>
> The (modified/quieted) code example under discussion is
On 25 April 2014 21:46, Poul-Henning Kamp wrote:
> In message
>
> , Ben Laurie writes:
>>On 25 April 2014 21:24, Ronald F. Guilmette wrote:
>>> Separately, a code example of the following general form was discussed:
>>>
>>> if (condition) var
On 25 April 2014 21:24, Ronald F. Guilmette wrote:
> Separately, a code example of the following general form was discussed:
>
> if (condition) variable = value1;
> if (!condition) variable = value2;
> use (variable);
>
> It was noted that code of this form can generate a "
On 25 April 2014 13:24, Dag-Erling Smørgrav wrote:
> Chad Perrin writes:
>> Obviously, human judgment is an important part of the process of finding
>> and fixing bugs. If it wasn't, the last program we'd ever have to debug
>> would be the one that finds and fixes bugs.
>
> https://en.wikipedia.
On 23 April 2014 20:14, Charles Swiger wrote:
> Hi--
>
> On Apr 23, 2014, at 3:06 AM, Erik Cederstrand
> wrote:
>> Den 23/04/2014 kl. 03.12 skrev Ronald F. Guilmette :
> [ ... ]
>>> I do imagine that the truth or falsehood of your assertion may depend
>>> quite substantally on what one does or d
On 23 April 2014 02:12, Ronald F. Guilmette wrote:
>
> In message <20140423010054.2891e143d...@rock.dv.isc.org>,
> Mark Andrews wrote:
>
>>As for the number of CLANG analysis warnings. Clang has false
>>positives
>
> Please define your terms.
>
> I do imagine that the truth or falsehood of your
On 22 April 2014 22:28, Ronald F. Guilmette wrote:
>
> In message ,
> Charles Swiger wrote:
>
>>On Apr 21, 2014, at 6:38 PM, Ronald F. Guilmette
>>wrote
>>:
>>> In the aftermath of this whole OpenSSL brouhaha... which none other than
>>> Bruce Schneier publically pronounced to be a 12, on a sca
As suggested, adding freebsd-security.
On 15 January 2014 21:45, Xin Li wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 01/15/14 13:04, Ben Laurie wrote:
>> Have not read this yet, but someone at Real World Cryptography
>> pointed me at it. Sounded like
On Thu, Sep 27, 2012 at 10:49 AM, Dag-Erling Smørgrav wrote:
> RW writes:
>> "Dag-Erling Smørgrav" writes:
>> > You can't rely on the existence of a TSC. I would suggest using the
>> > fractional part of binuptime instead.
>> get_cyclecount() is supposed to be platform independent and should
>>
On Tue, Sep 25, 2012 at 6:32 AM, Pawel Jakub Dawidek wrote:
> On Tue, Sep 25, 2012 at 12:10:13AM +0200, Mariusz Gromada wrote:
>> W dniu 2012-09-24 23:56, Mariusz Gromada pisze:
>>
>> > Ok, finally I have some formal results. To be completely honest I need
>> > to point out that, in fact, we have
On Mon, Sep 24, 2012 at 10:56 PM, Mariusz Gromada
wrote:
> W dniu 2012-09-23 17:17, Pawel Jakub Dawidek pisze:
>
>> On Sun, Sep 23, 2012 at 02:37:48AM +0200, Mariusz Gromada wrote:
>>>
>>> W dniu 2012-09-22 21:53, Pawel Jakub Dawidek pisze:
Mariusz, can you confirm my findings?
>>>
>>>
>
On Mon, Sep 24, 2012 at 10:15 AM, Dag-Erling Smørgrav wrote:
> Doug Barton writes:
>> If you disagree with what this script is doing, please speak up.
>
> Do you mean initrandom? I dislike it only slightly less now than I did
> before. I hope Pawel's patch works out so we can nuke it.\
He mean
On Wed, Sep 19, 2012 at 9:20 PM, Pawel Jakub Dawidek wrote:
> On Wed, Sep 19, 2012 at 08:59:15PM +0100, Ben Laurie wrote:
>> On Wed, Sep 19, 2012 at 8:29 PM, Pawel Jakub Dawidek
>> wrote:
>> > On Wed, Sep 19, 2012 at 07:30:52PM +0100, Jonathan Anderson wrote:
>>
On Thu, Sep 20, 2012 at 7:54 AM, Jonathan Anderson wrote:
> On Wednesday, 19 September 2012 at 20:47, Ben Laurie wrote:
>
> Erring on the side of underestimation is wise here.
>
> I agree wholeheartedly, but underestimation means "calculating the correct
> value and then a
On Wed, Sep 19, 2012 at 8:29 PM, Pawel Jakub Dawidek wrote:
> On Wed, Sep 19, 2012 at 07:30:52PM +0100, Jonathan Anderson wrote:
>> > If all the times are more or less equally probable in this range […]
>>
>> They're very unlikely to be equally probable. It would make sense to do some
>> characte
On Wed, Sep 19, 2012 at 7:30 PM, Jonathan Anderson
wrote:
> On Tuesday, 18 September 2012 at 22:14, Pawel Jakub Dawidek wrote:
>> […] we have more
>> than 19 bits of entropy from this one call, but I reduced if to four
>> bits only, because there are devices that are much faster to attach.
>>
>
>
On Sun, Sep 16, 2012 at 10:27 PM, Doug Barton wrote:
> Finally, I still think that making changes to the entropy-feeding
> methods in initrandom or random are premature until we have a chance to
> review Arthur's work on what's actually happening with the buffer. Until
> we know where the problems
On Sat, Sep 15, 2012 at 1:07 PM, Mark Murray wrote:
> Ben Laurie writes:
>> I notice that events are also discarded when the queue reaches a
>> certain length. This seems like a problem, too.
>
> Hooboy.
>
> Please go back and read this whole thread from the beginnin
On Sat, Sep 15, 2012 at 12:07 PM, Mark Murray wrote:
> Ben Laurie writes:
>> > Are you aware of Yarrow's approach to poor entropy while harvesting?
>>
>> Yes. I am _only_ talking about fixes for the current practice of
>> discarding input - once Yarrow gets to e
On Sat, Sep 15, 2012 at 11:36 AM, Mark Murray wrote:
> Ben Laurie writes:
>> > I can certainly trigger a reseed at will, but allowing external writes
>> > to overwhelm the system by doing a
>> >
>> > $ cat /dev/zero > /dev/random
>> >
>>
On Sat, Sep 15, 2012 at 11:36 AM, Mark Murray wrote:
> Ben Laurie writes:
>> My point here is that you don't have full control of the inputs
>> to /dev/random, so assuming that they take some particular form
>> seems like a mistake to me - the aim, I would hope, would
On Fri, Sep 14, 2012 at 10:49 PM, Mark Murray wrote:
> Ben Laurie writes:
>> > My proposed solution is intended so address, if not solve that
>> > problem, by preventing file writes from filling up the harvest
>> > queue. Yarrow already has pretty good data hash
On Fri, Sep 14, 2012 at 9:15 PM, Mark Murray wrote:
> Ben Laurie writes:
>> What I am trying to do is extract whatever entropy there is in the
>> input. You appear to be saying that there's no point adding extra
>> entropy because it is estimated at zero. This makes no
On Fri, Sep 14, 2012 at 8:22 PM, Mark Murray wrote:
> Ben Laurie writes:
>> > What??! Have you seen how Yarrow does its harvesting??
>>
>> If you XOR into the as-yet-unharvested buffer, then appropriately
>> aligned repeated input makes the buffer zero.
>
I have
On Fri, Sep 14, 2012 at 8:06 PM, Mark Murray wrote:
> Ben Laurie writes:
>> > I'll send patches (untested) in a couple of hours for discussion.
>>
>> I used to like this idea, but it can break pretty badly if you repeat
>> input, so in the end I decided hash
On Fri, Sep 14, 2012 at 4:30 PM, Pawel Jakub Dawidek wrote:
> On Tue, Sep 11, 2012 at 04:01:17PM -0700, Xin Li wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 09/11/12 15:48, Arthur Mesh wrote:
>> > On Tue, Sep 11, 2012 at 03:37:09PM -0700, Xin Li wrote:
>> >> Using gzip is b
On Fri, Sep 14, 2012 at 3:59 PM, Mark Murray wrote:
>> 5) send all data to the kernel but XORing the data together on
>> overflow in the kernel (can control when buffer full and only then
>> take action when needed, indepedent on how seed data is chosen,
>> withdrawn)
>
> I've already coded this u
On Fri, Sep 14, 2012 at 3:46 PM, RW wrote:
> On Fri, 14 Sep 2012 14:43:53 +0100
> Ben Laurie wrote:
>
>> On Fri, Sep 14, 2012 at 2:38 PM, Bjoern A. Zeeb
>> wrote:
>> > 7) send all data to the kernel and hash (arch dependent?) it +
>> > counter value into t
On Fri, Sep 14, 2012 at 2:38 PM, Bjoern A. Zeeb wrote:
> 7) send all data to the kernel and hash (arch dependent?) it + counter value
>into the buffer on overflow, as in b[n] = H(b[n] + c + i[n]) in the
> kernel
>(can control when buffer full and only then take action when
>needed, ind
39 matches
Mail list logo
