Cited in a comment on Schneier's blog:
https://www.schneier.com/blog/archives/2013/10/nsa_eavesdroppi_2.html
Register article with link to actual report:
http://www.theregister.co.uk/2013/10/31/most_security_protocols_insecure_suggests_enisa/
___
cryptog
Sandy Harris writes:
>Cited in a comment on Schneier's blog:
>https://www.schneier.com/blog/archives/2013/10/nsa_eavesdroppi_2.html
>
>Register article with link to actual report:
>http://www.theregister.co.uk/2013/10/31/most_security_protocols_insecure_suggests_enisa/
The original paper was wri
On 2013-11-04 10:40, Peter Gutmann wrote:
Beyond that, there are other problems with the recommendation. For example it
strongly recommends DLP algorithms over RSA. DLP is great on a whiteboard but
extremely brittle in practice, since the entire family has a distressing
propensity to leak the p
Peter,
(Full disclosure: I was one of the external reviewers of this report.)
I take your point that there is a gap between cryptography and security
engineering, and I understand the gap well from first-hand experience,
first from my time in industry and more recently as a consultant to
industry
On Mon, Nov 4, 2013 at 1:40 AM, Peter Gutmann wrote:
> Sandy Harris writes:
>
>>Cited in a comment on Schneier's blog:
>>https://www.schneier.com/blog/archives/2013/10/nsa_eavesdroppi_2.html
>>
>>Register article with link to actual report:
>>http://www.theregister.co.uk/2013/10/31/most_security_
On 4 November 2013 09:51, yersinia wrote:
> Nist recently posted a raccomandation very recently (IN DRAFT)
> http://csrc.nist.gov/publications/drafts/800-52-rev1/draft_sp800_52_r1.pdf
If you ignore the bits about FIPS-140 and SP800-90A, its not bad. But
fairly obvious.
It seems to be missing a c
By no means I claim to be an expert, but what I feel is that ENISA's
report is missing recommendations for TLS key exchange algorithms. I
would except this report to recommend algorithms that achieve forward
secrecy. In any case I found the report very comprehensive and well
suited for an engineer.
Peter Gutmann (at Monday, November 4, 2013, 1:40:26 AM):
> Then it deprecates PKCS #1 v1.5 (which pretty much the entire
> planet uses) because it doesn't have a security proof, while recommending a
> bunch of exotic alternatives that more or less nothing uses.
what is the purpose of academic re
"Paterson, Kenny" writes:
>So what are we to do? Continue to recommend something that is
>cryptographically dreadful simply because everybody is using it? Or to try to
>kickstart the process of breaking with the past? My view is that the latter
>is the right course of action. And a report like th
On 2013-11-06 21:11, Peter Gutmann wrote:
I'm arguing for incremental upgrades to existing protocols, not greenfields
developments.
Observe email.
You can't get there from here.
It's probably too late to invent a "better TLS" or "better PGP"
or "better S/MIME" now (although we can always do
On Thu, Nov 7, 2013 at 2:02 AM, James A. Donald wrote:
> On 2013-11-06 21:11, Peter Gutmann wrote:
>
>> I'm arguing for incremental upgrades to existing protocols, not
>> greenfields
>> developments.
>>
>
> Observe email.
>
> You can't get there from here.
>
>
> It's probably too late to invent
11 matches
Mail list logo
