Nico Williams writes:
>SSHv2 has a this approach and it has not been a disaster there.
It's still quite a mess. To compare the two, my TLS suite-choosing code is
more or less:
highestSuite = 0;
foreach suite
suite = readInteger();
if priority( suite ) > priority( highestSuite )
Hi Peter,
On 11 Feb 2013, at 22:45, Peter Gutmann wrote:
> Ralph Holz writes:
>
>> From what I can tell from our data, the most common symmetric ciphers in SSH
>> are proposed by client/servers to be used in CBC mode. With SSL/TLS and
>> XMLEnc, this mode has had quite some publicity in the r
Jeff,
>>
>> There have been attacks on SSH based on the fact that portions of the packets
>> aren't authenticated, and as soon as the TLS folks stop bikeshedding and
>> adopt
>> encrypt-then-MAC I'm going to propose the same thing for SSH, it's such a
>> no-brainer it should have been adopted ye
Nico Williams writes:
>If we want a policy of limiting what cipher suites we allocate codepoints to
>then we should have an *explicit* policy, and we should not wimp out when it
>comes time to enforcing it.
It'll never work, people will clamour for their pet vanity ciphers no matter
what you say
"Paterson, Kenny" writes:
>In fact, SSHv2 adopts a "Encrypt & MAC" construction and all fields in SSHv2
>are authenticated. But the issue is that this authentication cannot be
>checked until the whole message has arrived, and the receiver has to use a
>field in the plaintext to determine how long
On 12/02/13 13:20 PM, Paterson, Kenny wrote:
Hi Peter,
On 11 Feb 2013, at 22:45, Peter Gutmann wrote:
Ralph Holz writes:
From what I can tell from our data, the most common symmetric ciphers in SSH
are proposed by client/servers to be used in CBC mode. With SSL/TLS and
XMLEnc, this mode ha
On 12/02/13 03:04 AM, Peter Gutmann wrote:
Nico Williams writes:
I'd go further: this could be the start of the end of the cipher suite
cartesian product nonsense in TLS. Just negotiate {cipher, mode} and key
exchange separately, or possibly cipher, mode, and key exchange, in just the
same wa
On 12/02/13 04:49 AM, Kevin W. Wall wrote:
[Full-disclosure: I am not a Bit9 customer; I just get their
spam^H^H^H^H, er, informative product emails, thanks to a colleague
who signed me up for their mailing list.]
Security company, Bit9, has been hacked and have had their private
code-signing ke
On 2013-02-13 7:43 AM, ianG wrote:
This underlying force to appease every participant with a vanity tweak
is so powerful, it is one of the reasons why committees consistently
succeed in generating worse results than the original founders. But
they do keep everyone happier -- so there are wid
On Tue, Feb 12, 2013 at 5:00 PM, ianG wrote:
> On 12/02/13 04:49 AM, Kevin W. Wall wrote:
>
>
>
> In addition to
>> using their own software, you would have thought that they at least
>> would have air-gapped their code-signing private key, or at a minimum,
>> secured the private key with a st
I have seen several services/people using the phrase "zero knowledge"
recently, e.g.:
https://spideroak.com/
Based on my understanding of zero knowledge proofs and the traditional use
of "zero knowledge" in cryptography, this usage seems... novel, to put it
politely. In the case of SpiderOak, the
I've heard Steve Gibson (grc.com) use the phrase Trust No One (or TNO) when
referring to client-side encryption.
--
Tanner J.
On Feb 12, 2013 9:34 PM, "Tony Arcieri" wrote:
> I have seen several services/people using the phrase "zero knowledge"
> recently, e.g.:
>
> https://spideroak.com/
>
> Ba
On 13/02/13 05:33 AM, Tony Arcieri wrote:
I have seen several services/people using the phrase "zero knowledge"
recently, e.g.:
https://spideroak.com/
Based on my understanding of zero knowledge proofs and the traditional
use of "zero knowledge" in cryptography, this usage seems... novel, to
pu
On 13/02/13 05:15 AM, Kevin W. Wall wrote:
On Tue, Feb 12, 2013 at 5:00 PM, ianG mailto:i...@iang.org>> wrote:
On 12/02/13 04:49 AM, Kevin W. Wall wrote:
In addition to
using their own software, you would have thought that they at least
would have air-gapped their
14 matches
Mail list logo
