It bugs me that so many of the input words are mostly zero. Using the
TLS Sequence Number for the nonce is certainly going to be mostly zero
bits. And the block counter is almost all zero bits, as you note,
(In the case of the TLS, limits on the plaintext size mean that the
first counter
On 9/10/13 2:42 PM, Ben Laurie wrote:
On 10 September 2013 18:00, zooko mailto:zo...@zooko.com>>
wrote:
Please ask your friendly neighborhood TLS implementor to move fast on
http://tools.ietf.org/id/draft-josefsson-salsa20-tls-02.txt .
We prefer https://datatracker.ietf.org/doc/draft-ag
On 11/09/13 01:36 AM, Jerry Leichter wrote:
(Generating a different one for this purpose is pointless - it would have to be
random, in which case you might as well generate the IV randomly.)
In a protocol I wrote with Zooko's help, we generate a random IV0 which
is shared in the key exchange
On Sep 10, 2013, at 7:27 PM, Nemo wrote:
>> E_0 = IV # Not transmitted
>> E_{i+1} = E(E_i XOR P_{i+1})
>
> Not sure what "not transmitted" means here. In typical CBC
> implementations, the IV is certainly transmitted...
Sure. The intent was just that the ciphertext starts with E1. IV has to
On Fri, Sep 06, 2013 at 06:18:05PM +0100, Ben Laurie wrote:
> On 6 September 2013 18:13, Perry E. Metzger wrote:
>
> > It would be good to see them abandon RC4 of course, and soon.
> >
>
> In favour of what, exactly? We're out of good ciphersuites.
Please ask your friendly neighborhood TLS impl
On Sep 9, 2013, at 7:30 PM, Michael Ströder wrote:
>
> > Peter Gutmann wrote:
>
>> > Do you have numbers about the relative and absolute performance impact?
>> > Personally I don't see performance problems but I can't prove my position
>> > with
>> > numbers.
>
> MBA-2:tmp synp$ openssl speed
On 10/09/13 10:00, Guido Witmond wrote:
Hi Peter,
We really have different designs. I'll comment inline.
On 09/09/13 19:12, Peter Fairbrother wrote:
On 09/09/13 13:08, Guido Witmond wrote:
I like to look at it the other way round, retrieving the correct
name for a key.
You don't give someo
> Date: Tue, 10 Sep 2013 13:42:57 +0200
> From: Adam Back
> To: "Perry E. Metzger"
> Cc: Alexander Klimov , Cryptography List
> , Adam Back
> Subject: Re: [Cryptography] how could ECC params be subverted & other
>
...
> The important potential backdoor is NIST 186-3 curves in Peter
> Fairbroth
Is there a TLS WG draft adding djb's Curve1174 to the list of named
curves supported by TLS? If there's credible doubt about the safety
of the NIST curves, it seems that Curve1174 (in Edwards form) would
make a good choice for EECDH, perhaps coupled with a similar curve
with ~512 bits.
Slides wit
On 2013-09-10, at 17:35, Ben Laurie wrote:
> On 10 September 2013 22:04, Joe Abley wrote:
>
>> Suppose Mallory has access to the private keys of CAs which are in "the"
>> browser list or otherwise widely-trusted.
>>
>> An on-path attack between Alice and Bob would allow Mallory to terminate
On 08/09/2013 21:51, Perry E. Metzger wrote:
> On Sun, 8 Sep 2013 14:50:07 -0400 Jerry Leichter
> wrote:
>> Even for one-to-one discussions, these days, people want
>> transparent movement across their hardware. If I'm in a chat
>> session on my laptop and leave the house, I'd like to be able to
On 09/10/13 19:08, Peter Fairbrother wrote:
> The only assurance given by the scheme is that if a person gave you
> a hash which he generated himself, and you match it with a string and
> that string matches what you know about the person (eg their name or
> photo), then no-one else can have MTM'd
On Tue, 10 Sep 2013 17:04:04 -0400 Jerry Leichter
wrote:
> Phil Rogoway has a paper somewhere discussing the right way to
> implement cryptographic modes and API's.
It would be useful to get a URL for it.
> In particular, he recommends changing the definition of CBC from:
>
> E_0 = IV # Not
On Tue, 10 Sep 2013 16:45:23 -0400 John Kelsey
wrote:
> [DBRG] seemed like a really weird place to put a backdoor, because
> it was insanely slow, and it seemed unlikely to get any significant
> use.
As an aside, this is just the instance we know about, partially
because they screwed up, partiall
On Sep 10, 2013, at 5:45 PM, Perry E. Metzger wrote:
>> [DBRG] seemed like a really weird place to put a backdoor, because
>> it was insanely slow, and it seemed unlikely to get any significant
>> use.
> As an aside, this is just the instance we know about, partially
> because they screwed up, par
I wonder what people's opinions are on things like the randomsound
daemon that is available for Linux.
Similarly, any hardware with an ADC input can be used as a hardware
random noise source, simply by cranking up the gain to suitable levels
where the low-order bit is sampling thermal noise.
On 10 September 2013 18:00, zooko wrote:
> On Fri, Sep 06, 2013 at 06:18:05PM +0100, Ben Laurie wrote:
> > On 6 September 2013 18:13, Perry E. Metzger wrote:
> >
> > > It would be good to see them abandon RC4 of course, and soon.
> > >
> >
> > In favour of what, exactly? We're out of good cipher
On Tue, Sep 10, 2013 at 7:42 AM, Jerry Leichter wrote:
> On Sep 9, 2013, at 12:00 PM, Phillip Hallam-Baker wrote:
> > Steve Bellovin has made the same argument and I agree with it.
> Proliferation of cipher suites is not helpful.
> >
> > The point I make is that adding a strong cipher does not ma
On Tue, Sep 10, 2013 at 10:59:37AM -0400, Marcus D. Leech wrote:
> I wonder what people's opinions are on things like the randomsound
> daemon that is available for Linux.
Daniel Silverstone, the author, specifically advises people to not use
it. :)
B.
At 04:42 AM 9/10/2013, Jerry Leichter wrote:
On Sep 9, 2013, at 12:00 PM, Phillip Hallam-Baker wrote:
> Steve Bellovin has made the same argument and I agree with it.
Proliferation of cipher suites is not helpful.
> The point I make is that adding a strong cipher does not make you
more secure.
On 09/10/2013 12:04 PM, Rob Kendrick wrote:
I wonder what people's opinions are on things like the randomsound
daemon that is available for Linux.
Daniel Silverstone, the author, specifically advises people to not use
it. :)
I haven't actually looked at the code. Conceptually, anything with an
On 10 Sep 2013, at 17:07, Walter van Holst wrote:
> On 08/09/2013 21:51, Perry E. Metzger wrote:
>> On Sun, 8 Sep 2013 14:50:07 -0400 Jerry Leichter
>> wrote:
>>> Even for one-to-one discussions, these days, people want
>>> transparent movement across their hardware. If I'm in a chat
>>> sessio
On Tue, Sep 10, 2013 at 3:36 AM, Joachim Strömbergson <
joac...@strombergson.com> wrote:
> 1. We as a community create a list of curves that we agree on are good.
> The list is placed in a document, for example an RFC that clearly states
> what criteria has been used, what the sources for the curv
much of the discussion these past few weeks seems to be centered on channel and
container
protection, secure paths, encrypted file systems, etc. much effort has gone
into ensureing
opaque environments for data to flow. and while interesting and perhaps
useful, not a whole lot
of effort se
On Tue, 10 Sep 2013 21:58:28 + bmann...@vacation.karoshi.com
wrote:
> some years back, i was part of a debate on the relative value of
> crypto - and it was pointed out that for some sectors, crypto
> ensured _failure_ simply because processing the bits introduced
> latency. for these sectors
(I apologize this message is not correctly threaded. I only subscribed
to the list recently, and I have found no way to cannot construct a
proper In-reply-to header from messages in the archive.)
Peter Fairbrother wrote:
> And most of their interception is passive, they just listen - you
> genera
On Tue, 10 Sep 2013 17:04:51 -0400 Joe Abley
wrote:
> On 2013-09-09, at 12:04, "Salz, Rich" wrote:
>
> > then maybe it's not such a "silly accusation" to think that
> > root CAs are routinely distributed to multinational secret
> > services to perform MITM session decryption on any form of
> > c
On 10 September 2013 22:04, Joe Abley wrote:
> Suppose Mallory has access to the private keys of CAs which are in "the"
> browser list or otherwise widely-trusted.
>
> An on-path attack between Alice and Bob would allow Mallory to terminate
> Alice's TLS connection, presenting an opportunisticall
On Tue, Sep 10, 2013 at 10:59 AM, Marcus D. Leech wrote:
> I wonder what people's opinions are on things like the randomsound daemon
> that is available for Linux.
I have not looked at that. A well thought out & well documented
RNG based on a sound card is:
http://www.av8n.com/turbid/paper/turbid
On Sep 10, 2013, at 2:30 AM, ianG wrote:
> The question of whether one could simulate a raw physical source is
> tantalising. I see diverse opinions as to whether it is plausible, and
> thinking about it, I'm on the fence.
I don't think simulating a physical source is itself a big challenge.
On 10/09/13 05:38, James A. Donald wrote:
On 2013-09-10 3:12 AM, Peter Fairbrother wrote:
I like to look at it the other way round, retrieving the correct name
for a key.
You don't give someone your name, you give them an 80-bit key
fingerprint. It looks something like m-NN4H-JS7Y-OTRH-GIRN. Th
I'm calling an end to the eggs, baskets, one cipher or a thousand
discussion. I don't think more will provide additional insight for
future protocol designers, and both major contributors have gotten
several rounds in already.
--
Perry E. Metzgerpe...@piermont.com
On Sep 10, 2013, at 12:43 PM, Nemo wrote:
> "GET / HTTP/1.1\r\n" is exactly 16 bytes, or one AES block. If the IV is
> sent in the clear -- which it is -- that is one plaintext-ciphertext
> pair right there for every HTTPS connection.
Phil Rogoway has a paper somewhere discussing the right way to
On Sep 9, 2013, at 9:10 PM, Tony Arcieri wrote:
> On Mon, Sep 9, 2013 at 9:29 AM, Ben Laurie wrote:
>> And the brief summary is: there's only one ciphersuite left that's good, and
>> unfortunately its only available in TLS 1.2:
>>
>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
>
> A lot of people d
On Sep 10, 2013, at 5:49 PM, "Perry E. Metzger" wrote:
>> Phil Rogoway has a paper somewhere discussing the right way to
>> implement cryptographic modes and API's.
>
> It would be useful to get a URL for it.
>
>> In particular, he recommends changing the definition of CBC...to
>>
>> E_0 = E(IV
On 10/09/13 14:03, Ben Laurie wrote:
On 10 September 2013 03:59, james hughes mailto:hugh...@mac.com>> wrote:
[...]
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
I retract my previous "+1" for this ciphersuite. This is hard coded
1024 DHE and 1024bit RSA.
It is not hard coded to 1024 bit R
The documents haven't yet been completely processed, but they've
already found some interesting features.
Quoting:
The NSA apparently believed that it had the authority to search
the telephone records database in order to obtain the 'reasonable
articulable suspicion' required to inves
On 2013-09-09, at 12:04, "Salz, Rich" wrote:
> ➢ then maybe it's not such a "silly accusation" to think that root CAs are
> routinely distributed to multinational secret
> ➢ services to perform MITM session decryption on any form of communication
> that derives its security from the CA PKI.
On Sun, 8 Sep 2013 15:22:32 -0400 "Perry E. Metzger"
wrote:
> Ah, now *this* is potentially interesting. Imagine if you have a
> crypto accelerator that generates its IVs by encrypting information
> about keys in use using a key an observer might have or could guess
> from a small search space.
O
The story has been floating around for some days now. Apparently, Man
in the Middle attacks have been used quite extensively, including
against the Brazilian state oil company, and a major international
wire transfer network.
http://www.slate.com/blogs/future_tense/2013/09/09/shifting_shadow_storm
Forwarding because Adam apparently has distinct envelope and From:
addresses and didn't notice the bounce.
Note that anyone replying and attributing this message to *me* will
be laughed at mercilessly as their message is rejected.
Perry
Begin forwarded message:
Date: Tue, 10 Sep 2013 13:42:57 +
On Sep 9, 2013, at 12:00 PM, Phillip Hallam-Baker wrote:
> Steve Bellovin has made the same argument and I agree with it. Proliferation
> of cipher suites is not helpful.
>
> The point I make is that adding a strong cipher does not make you more
> secure. Only removing the option of using weak
On Sep 9, 2013, at 9:17 AM, Kent Borg wrote:
>> Which brings into the light the question: Just *why* have so many random
>> number generators proved to be so weak.
>
> Your three cases left off an important one: Not bothering to seed the PRNG at
> all. I think the Java/Android cryptographic (!
On 2013-09-10 3:12 AM, Peter Fairbrother wrote:
I like to look at it the other way round, retrieving the correct name
for a key.
You don't give someone your name, you give them an 80-bit key
fingerprint. It looks something like m-NN4H-JS7Y-OTRH-GIRN. The m- is
common to all, it just says this
On 10/09/13 06:29 AM, John Kelsey wrote:
But I am not sure how much it helps against tampered chips. If I can tamper
with the noise source in hardware to make it predictable, it seems like I
should also be able to make it simulate the expected behavior. I expect this
is more complicated th
On 10 September 2013 03:59, james hughes wrote:
>
> On Sep 9, 2013, at 2:49 PM, Stephen Farrell
> wrote:
>
> On 09/09/2013 05:29 PM, Ben Laurie wrote:
>
> Perry asked me to summarise the status of TLS a while back ... luckily I
> don't have to because someone else has:
>
> http://tools.ietf.org/
Hi Peter,
We really have different designs. I'll comment inline.
On 09/09/13 19:12, Peter Fairbrother wrote:
> On 09/09/13 13:08, Guido Witmond wrote:
> I like to look at it the other way round, retrieving the correct
> name for a key.
>
> You don't give someone your name, you give them an 80-b
On Mon, Sep 9, 2013 at 9:29 AM, Ben Laurie wrote:
> And the brief summary is: there's only one ciphersuite left that's good,
> and unfortunately its only available in TLS 1.2:
>
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
>
>
A lot of people don't like GCM either ;) So we're screwed!
Well, aside from
>
> On Mon, Sep 09, 2013 at 06:41:23AM -0700, Andreas Davour wrote:
>> >So there *is* a BTNS implementation, after all. Albeit
>> >only for OpenBSD -- but this means FreeBSD is next, and
>> >Linux to follow.
>>
>> I might add that as far as I know, this work has not been picked up
>> yet by
Hi Hanno,
Please send any comments on this draft to the TLS Working Group mailing
list, t...@ietf.org.
Thanks,
Yaron
On 09/10/2013 12:14 AM, Hanno Böck wrote:
On Mon, 9 Sep 2013 17:29:24 +0100
Ben Laurie wrote:
Perry asked me to summarise the status of TLS a while back ...
luckily
On 09/10/2013 02:01 PM, Ben Laurie wrote:
>> Claiming that all the rest are no good also seems overblown, if
>> that's what you meant.
>
> Other than minor variations on the above, all the other ciphersuites have
> problems - known attacks, unreviewed ciphers, etc.
There are issues, sure. And
Ben Laurie writes:
>We need to get an extension number allocated, since the one it uses clashes
>with ALPN.
It does? draft-ietf-tls-applayerprotoneg-01 doesn't mention ID 0x10 anywhere.
(In any case -encrypt-then-MAC got there first, these Johnny-come-lately's can
find their own ID to squat on
On Sun, 2013-09-08 at 13:27 +0200, Eugen Leitl wrote:
> - Forwarded message from "James A. Donald" -
> On 2013-09-08 3:48 AM, David Johnston wrote:
> > Claiming the NSA colluded with intel to backdoor RdRand is also to
> > accuse me personally of having colluded with the NSA in producing a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aloha!
Tony Arcieri wrote:
> The question is... suitable for what? djb argues it could be used to
> find a particularly weak curve, depending on what your goals are:
> http://i.imgur.com/o6Y19uL.png
So, the question is then - how do we fix this?
I
On 9 September 2013 22:49, Stephen Farrell wrote:
>
> Hi Ben,
>
> On 09/09/2013 05:29 PM, Ben Laurie wrote:
> > Perry asked me to summarise the status of TLS a while back ... luckily I
> > don't have to because someone else has:
> >
> > http://tools.ietf.org/html/draft-sheffer-tls-bcp-00
> >
> > I
On 10 September 2013 11:29, Peter Gutmann wrote:
> Ben Laurie writes:
>
> >We need to get an extension number allocated, since the one it uses
> clashes
> >with ALPN.
>
> It does? draft-ietf-tls-applayerprotoneg-01 doesn't mention ID 0x10
> anywhere.
>
> (In any case -encrypt-then-MAC got there
56 matches
Mail list logo
