Hi Peff,
On Fri, 16 Jun 2017, Jeff King wrote:
> On Fri, Jun 16, 2017 at 03:24:19PM +0200, Johannes Schindelin wrote:
>
> > I have no doubt that Visual Studio Team Services, GitHub and Atlassian
> > will eventually end up with FPGAs for hash computation. So that's
> > that.
>
> I actually doubt
On Fri, Jun 16 2017, Jonathan Nieder jotted:
> Part of the reason I suggested previously that it would be helpful to
> try to benchmark Git with various hash functions (which didn't go over
> well, for some reason) is that it makes these comparisons more
> concrete. Without measuring, it is hard
Junio C Hamano wrote:
> Junio C Hamano writes:
>> Adam Langley writes:
>>> However, as I'm not a git developer, I've no opinion on whether the
>>> cost of carrying implementations of these functions is worth the speed
>>> vs using SHA-256, which can be assumed to be supported everywhere
>>> alre
Junio C Hamano writes:
> Adam Langley writes:
>
>> However, as I'm not a git developer, I've no opinion on whether the
>> cost of carrying implementations of these functions is worth the speed
>> vs using SHA-256, which can be assumed to be supported everywhere
>> already.
>
> Thanks.
>
> My imp
Adam Langley writes:
> However, as I'm not a git developer, I've no opinion on whether the
> cost of carrying implementations of these functions is worth the speed
> vs using SHA-256, which can be assumed to be supported everywhere
> already.
Thanks.
My impression from this thread is that even
On Fri, Jun 16, 2017 at 03:24:19PM +0200, Johannes Schindelin wrote:
> I have no doubt that Visual Studio Team Services, GitHub and Atlassian
> will eventually end up with FPGAs for hash computation. So that's that.
I actually doubt this from the GitHub side. Hash performance is not even
on our r
On Fri, Jun 16, 2017 at 6:24 AM, Johannes Schindelin
wrote:
>
> And while I am really thankful that Adam chimed in, I think he would agree
> that BLAKE2 is a purposefully weakened version of BLAKE, for the benefit
> of speed
That is correct.
Although worth keeping in mind that the analysis resul
Hi,
On Fri, 16 Jun 2017, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Jun 16 2017, brian m. carlson jotted:
>
> > On Fri, Jun 16, 2017 at 01:36:13AM +0200, Ævar Arnfjörð Bjarmason wrote:
> >
> >> So I don't follow the argument that we shouldn't weigh future HW
> >> acceleration highly just because y
On Fri, Jun 16 2017, brian m. carlson jotted:
> On Fri, Jun 16, 2017 at 01:36:13AM +0200, Ævar Arnfjörð Bjarmason wrote:
>> On Fri, Jun 16, 2017 at 12:41 AM, brian m. carlson
>> wrote:
>> > SHA-256 acceleration exists for some existing Intel platforms already.
>> > However, they're not practical
On Fri, Jun 16, 2017 at 06:10:22AM +0900, Mike Hommey wrote:
> > > What do the experts think or SHA512/256, which completely removes the
> > > concerns over length extension attack? (which I'd argue is better than
> > > sweeping them under the carpet)
> >
> > I don't think it's sweeping them unde
On Fri, Jun 16, 2017 at 01:36:13AM +0200, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Jun 16, 2017 at 12:41 AM, brian m. carlson
> wrote:
> > SHA-256 acceleration exists for some existing Intel platforms already.
> > However, they're not practically present on anything but servers at the
> > moment,
On Fri, Jun 16, 2017 at 12:41 AM, brian m. carlson
wrote:
> On Thu, Jun 15, 2017 at 02:59:57PM -0700, Adam Langley wrote:
>> (I was asked to comment a few points in public by Jonathan.)
>>
>> I think this group can safely assume that SHA-256, SHA-512, BLAKE2,
>> K12, etc are all secure to the exte
On Thu, Jun 15, 2017 at 02:59:57PM -0700, Adam Langley wrote:
> (I was asked to comment a few points in public by Jonathan.)
>
> I think this group can safely assume that SHA-256, SHA-512, BLAKE2,
> K12, etc are all secure to the extent that I don't believe that making
> comparisons between them o
(I was asked to comment a few points in public by Jonathan.)
I think this group can safely assume that SHA-256, SHA-512, BLAKE2,
K12, etc are all secure to the extent that I don't believe that making
comparisons between them on that axis is meaningful. Thus I think the
question is primarily concer
On Thu, Jun 15, 2017 at 09:01:45AM -0400, Jeff King wrote:
> On Thu, Jun 15, 2017 at 08:05:18PM +0900, Mike Hommey wrote:
>
> > On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote:
> > > Footnote *1*: SHA-256, as all hash functions whose output is essentially
> > > the entire inter
Hi,
On Thu, 15 Jun 2017, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Jun 15 2017, Jeff King jotted:
>
> > On Thu, Jun 15, 2017 at 08:05:18PM +0900, Mike Hommey wrote:
> >
> >> On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote:
> >>
> >> > Footnote *1*: SHA-256, as all hash functio
Brandon Williams writes:
>> It would make a whole of a lot of sense to make that knob not Boolean,
>> but to specify which hash function is in use.
>
> 100% agree on this point. I believe the current plan is to have the
> hashing function used for a repository be a repository format extension
>
Hi Dscho,
Johannes Schindelin wrote:
> From what I read, pretty much everybody who participated in the discussion
> was aware that the essential question is: performance vs security.
I don't completely agree with this framing. The essential question is:
how to get the right security properties
On 06/15, Johannes Schindelin wrote:
> Hi,
>
> I thought it better to revive this old thread rather than start a new
> thread, so as to automatically reach everybody who chimed in originally.
>
> On Mon, 6 Mar 2017, Brandon Williams wrote:
>
> > On 03/06, brian m. carlson wrote:
> >
> > > On Sat
On Thu, Jun 15 2017, Jeff King jotted:
> On Thu, Jun 15, 2017 at 08:05:18PM +0900, Mike Hommey wrote:
>
>> On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote:
>> > Footnote *1*: SHA-256, as all hash functions whose output is essentially
>> > the entire internal state, are suscept
On Thu, Jun 15, 2017 at 08:05:18PM +0900, Mike Hommey wrote:
> On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote:
> > Footnote *1*: SHA-256, as all hash functions whose output is essentially
> > the entire internal state, are susceptible to a so-called "length
> > extension attac
On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote:
> Footnote *1*: SHA-256, as all hash functions whose output is essentially
> the entire internal state, are susceptible to a so-called "length
> extension attack", where the hash of a secret+message can be used to
> generate the h
Hi,
I thought it better to revive this old thread rather than start a new
thread, so as to automatically reach everybody who chimed in originally.
On Mon, 6 Mar 2017, Brandon Williams wrote:
> On 03/06, brian m. carlson wrote:
>
> > On Sat, Mar 04, 2017 at 06:35:38PM -0800, Linus Torvalds wrote:
23 matches
Mail list logo
