On Sun, Sep 27, 2009 at 02:23:16PM -0700, Fuzzy Hoodie-Monster wrote:
> As usual, I tend to agree with Peter. Consider the time scale and
> severity of problems with cryptographic algorithms vs. the time scale
> of protocol development vs. the time scale of bug creation
> attributable to complex de
On Mon, Sep 7, 2009 at 6:02 AM, Peter Gutmann wrote:
> That's a rather high cost to pay just for the ability to make a crypto fashion
> statement. Even if the ability to negotiate hash algorithms had been built in
> from the start, this only removes the non-interoperability but doesn't remove
>
Thor Lancelot Simon writes:
>I think we're largely talking past one another. As regards "new horrible
>problems" I meant simply that if there _are_ "new horrible problems_ such
>that we need to switch away from SHA1 in the TLS PRF, the design mistakes
>made in TLS 1.1 will make it much harder.
On Thu, Aug 27, 2009 at 11:30:08AM +1200, Peter Gutmann wrote:
>
> Thor Lancelot Simon writes:
>
> >the exercise of recovering from new horrible problems with SHA1 would be
> >vastly simpler, easier, and far quicker
>
> What new horrible problems in SHA1 (as it's used in SSL/TLS)? What old
> h
Peter Gutmann wrote:
> Consider for example a system that uses two
> authentication algorithms in case one fails, or that
> has an algorithm-upgrade/rollover capability, perhaps
> via downloadable plugins. At some point a device
> receives a message authenticated with algorithm A
> saying "Algori
Ben Laurie writes:
>It seems to me protocol designers get all excited about this because they
>want to design the protocol once and be done with it. But software authors
>are generally content to worry about the new algorithm when they need to
>switch to it - and since they're going to have to up
On Aug 25, 2009, at 4:44 AM, Ben Laurie wrote:
Perry E. Metzger wrote:
Yet another reason why you always should make the crypto algorithms
you
use pluggable in any system -- you *will* have to replace them some
day.
In order to roll out a new crypto algorithm, you have to roll out new
sof
Perry E. Metzger wrote:
Yet another reason why you always should make the crypto algorithms you
use pluggable in any system -- you *will* have to replace them some day.
Ben Laurie wrote:
In order to roll out a new crypto algorithm, you have to roll out new
software. So, why is anything neede
On Tue, Aug 25, 2009 at 12:44:57PM +0100, Ben Laurie wrote:
> In order to roll out a new crypto algorithm, you have to roll out new
> software. So, why is anything needed for "pluggability" beyond versioning?
>
> It seems to me protocol designers get all excited about this because
> they want to d
On Tue, Aug 25, 2009 at 12:44:57PM +0100, Ben Laurie wrote:
> Perry E. Metzger wrote:
> > Yet another reason why you always should make the crypto algorithms you
> > use pluggable in any system -- you *will* have to replace them some day.
>
> In order to roll out a new crypto algorithm, you have t
Ben Laurie wrote:
Perry E. Metzger wrote:
Yet another reason why you always should make the crypto algorithms you
use pluggable in any system -- you *will* have to replace them some day.
In order to roll out a new crypto algorithm, you have to roll out new
software. So, why is anything needed
On Tue, 25 Aug 2009, Ben Laurie wrote:
> In order to roll out a new crypto algorithm, you have to roll out new
> software. So, why is anything needed for "pluggability" beyond versioning?
If active attackers are part of the threat model, then you need to
worry about version-rollback attacks for as
Perry E. Metzger wrote:
> Yet another reason why you always should make the crypto algorithms you
> use pluggable in any system -- you *will* have to replace them some day.
In order to roll out a new crypto algorithm, you have to roll out new
software. So, why is anything needed for "pluggability"
"James A. Donald" writes:
> Getting back towards topic, the hash function employed by Git is
> showing signs of bitrot, which, given people's desire to introduce
> malware backdoors and legal backdoors into Linux, could well become a
> problem in the very near future.
I believe attacks on Git's
[*] Linus Torvalds got the idea of a Cryptographic Hash Function
Directed Acyclic Graph structure from an earlier distributed
revision control tool named Monotone.
OT trivia: The idea actually predates either monotone or git;
opencm (http://opencm.org/docs.html) was using a similiar technique
Zooko Wilcox-O'Hearn writes:
> On Wednesday,2009-08-19, at 10:05 , Jack Lloyd wrote:
>
>> On Wed, Aug 19, 2009 at 09:28:45AM -0600, Zooko Wilcox-O'Hearn wrote:
>>
>>> [*] Linus Torvalds got the idea of a Cryptographic Hash Function
>>> Directed Acyclic Graph structure from an earlier distributed
On Wednesday,2009-08-19, at 10:05 , Jack Lloyd wrote:
On Wed, Aug 19, 2009 at 09:28:45AM -0600, Zooko Wilcox-O'Hearn wrote:
[*] Linus Torvalds got the idea of a Cryptographic Hash Function
Directed Acyclic Graph structure from an earlier distributed
revision control tool named Monotone.
O
On Wed, Aug 19, 2009 at 09:28:45AM -0600, Zooko Wilcox-O'Hearn wrote:
> [*] Linus Torvalds got the idea of a Cryptographic Hash Function
> Directed Acyclic Graph structure from an earlier distributed revision
> control tool named Monotone. He didn't go out of his way to give
> credit to Monotone,
18 matches
Mail list logo
