Re: [cryptography] crypto mdoel based on cardiorespiratory coupling

[Paterson, Kenny]

The system is vulnerable to a simple chosen plaintext attack as soon as you 
extract a workable scheme from the vague description in the paper (see appendix 
A for the closest thing to an actual specification of an encryption scheme). 

It should be an embarrassment to both Phys Rev X and the University of 
Lancaster (which does have a serious cyber security research group, who surely 
were not consulted by the university's press office). 

I'll write up the attack and post it on IACR eprint. 

Best,

Kenny


> On 10 Apr 2014, at 05:59, "Jeffrey Goldberg"  wrote:
> 
>> On 2014-04-09, at 7:17 PM, travis+ml-rbcryptogra...@subspacefield.org wrote:
>> 
>> http://threatpost.com/crypto-model-based-on-human-cardiorespiratory-coupling/105284
>> 
>> This is nonsense, right?
> 
> Yep.
> 
>> Unbounded in the sense of relying on secrecy of the unbounded number of 
>> algorithms?
> 
> The distinction between algorithm and parameter (along with other things) 
> seem muddled.
> 
> I commented on it is a few posts in sci.crypt.  Here are trimmed highlights.
> 
> Jeffrey Goldberg wrote in Message-ID::
> 
>> […]the 60 item bibliography of their paper cites only one source in 
>> cryptography (and that is on quantum key exchange).
>> 
>> Somehow the first sentence of the paper doesn't inspire confidence either:
>> 
>> "It is often the case that great scientific and technological discoveries 
>> are …"
>> 
>> […]
>> What I see as I glance over this paper is that people who have been caught 
>> up in the fadish understanding of "chaos theory" see that they get PRNGs out 
>> of their dynamical systems (true enough).
>> 
>> But quite emphatically, the PRNGs that you get from most of this non-linear 
>> dynamical systems are not cryptographically appropriate. Indeed, there are 
>> tests that can distinguish whether the random sequences is likely to be from 
>> such a system. If I understand correctly, even their noise filtering 
>> component depends on exactly that technology.
> 
> 
> Cheers,
> 
> -j
> ___
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] European report says many crypto protocols have problems

[Paterson, Kenny]

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. 

You are quite right that PKCS#1v1.5 is very widely used and widely
supported in developer libraries. But that does not mean it should
continue to be used forever, especially in view of the fact that it has
been repeatedly broken (in a practical sense) in different application
scenarios. Let me know if you want the list of papers showing this - but
you could start by re-reading Bleichenbacher's "million message attack"
paper from Crypto 1998, and then the more recent paper by Bardou et al.
from Crypto 2012 (slides here:
http://www.iacr.org/conferences/crypto2012/slides/11-1-Steel.pdf).
PKCS#1v1.5 makes a great example of why theoretical weaknesses should not
be ignored: attacks that start off that way generally only get stronger
with time. 

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 this is an
opportunity to do so. It provides a lever for crypto engineers to start
pushing for more cryptographically robust solutions.

You mention SSL/TLS and the billions of devices and apps using it.
Interesting case study. By your argument, we should continue to use RC4 or
MAC-then-encrypt in that protocol, since, hey, everybody is using them,
they are good enough, and we can patch against the currently known
attacks. Interesting exercise in double-think to try to reconcile that
with your proposals over on the TLS mailing list (specifically
draft-gutmann-tls-encrypt-then-mac-00.txt). What gives?

By the way, I think you should write your proposed report. Or lobby for
some body like ENISA to commission it.


Cheers

Kenny

On 04/11/2013 00:40, "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_protocols_insecure_
>>suggests_enisa/
>
>The original paper was written by some very smart cryptographers.  And
>that's
>the problem, it was written by cryptographers, not security engineers.
>If I
>wanted to run crypto on a whiteboard, I'd definitely follow the
>recommendations in the paper.  However, looking at systems deployed in
>practice... well, I'll refer people to the Crypto Gardening Guide and
>Planting
>Tips, http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt, and in
>particular Questions I and J and the Final Thoughts.
>
>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 private key if you get even the tiniest
>implementation
>detail wrong.  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.
>
>So what I'd be interested in seeing in response to this report is another
>one
>written by security engineers which makes recommendations on what's
>practical
>in real life rather than on a whiteboard.  For example, we have several
>billion SSL/TLS apps deployed (every PC, laptop, tablet, and smartphone
>has
>one, not to mention any number of embdded devices, the figure "several
>billion" is not an exaggeration), how should we configure those to
>provide the
>best security possible?
>
>(NB: I am not volunteering to write this report :-).
>
>Peter.
>___
>cryptography mailing list
>cryptography@randombit.net
>http://lists.randombit.net/mailman/listinfo/cryptography
>


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Using same key for ECDSA and ECIES

[Paterson, Kenny]

Dominik,

You can certainly do it safely in this instance, because we have a
security analysis that says it's OK, but in general it's a bad idea to use
the same key-pair for more than one purpose, and, as the RSA-based example
in the paper shows, it can sometimes get you into serious trouble. Indeed,
there's even a cryptographic principle - key separation - which says "use
different keys for different functions".

Regards

Kenny

On 20/09/2013 19:35, "Dominik Schürmann" 
wrote:

>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>
>On 20.09.2013 17:17, Paterson, Kenny wrote:
>> It is "technically secure". See:
>> 
>> http://eprint.iacr.org/2011/615
>
>Thanks you so much for this paper, it's even mostly understandable
>with some basic knowledge of attack models :)
>
>> Even so, I would not recommend this approach unless you absolutely
>> have to use it.
>
>Could you elaborate more on this? Do you see problems besides Alan
>Braggins remark?
>
>
>In my scenario I have a network with nodes sending messages
>hop-by-hop, where the ids of these nodes are the public keys itself.
>The problem is that these networks are highly unreliable and have high
>delays (Delay tolerant networking). Thus, DH key exchange protocols
>are out of scope. The idea is to always sign messages with your
>private key which could be verified by anyone using the node id itself
>(your pub key), and encrypted using the destination's node id (which
>is the pub key of the destination).
>How you know if you are using the right node id (for verification or
>encryption) is not a problem which should be discussed here.
>
>Because ids should be as short as possible it would be nice to use the
>same pub key for verification and encryption.
>
>After reading related literature, I came to the conclusion to use
>ECDSA and ECIES (Both with Koblitz curves, as I am sceptical about the
>random curves ;),
>Bernstein's curve25519 would be too difficult to integrate, as I
>didn't found a library, which is present in current linux distros and
>handles both EC sign and encryption schemes.
>
>Regards
>Dominikh
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v1.4.14 (GNU/Linux)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
>iQEcBAEBAgAGBQJSPJVmAAoJEHGMBwEAASKC6rMH/1Q4edycmw1CIwTVBsz0RG0E
>wlstAuBkHm4Msd7nnVzK601imXfkqRaXI8uuzhm4XlCFhykh6DrPQ7W9idWqJSyG
>ioefr7od5up0aGZna5PZQCinm0X7b1e8HbcMLXFhgYcXVvQWMbcLfdikUpHgotbW
>XgiH4JwR9xC178bPzacduBZI0Gy7IZPNUO0geTCYEvvcS144V+w5WlGidzsP6F1p
>sDYEjI6oxfYxQ8ThzKnzxYQSNfzpPGaLIUdSb6WkLSJOGGtoPGCigxlAXUC3L6fE
>n3V6n2mALHDgjmnReMg/4cNK+8TFjJcohCL2k0ZO+8WiHNAl5PT//D+6Q8FSbPc=
>=Z59x
>-END PGP SIGNATURE-
>___
>cryptography mailing list
>cryptography@randombit.net
>http://lists.randombit.net/mailman/listinfo/cryptography
>


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Using same key for ECDSA and ECIES

[Paterson, Kenny]

Hi 

On 20/09/2013 16:07, "Alan Braggins"  wrote:

>On 20/09/13 13:22, Dominik Schürmann wrote:
>> I am wondering if it is okay to use the same asymmetric ECC key for
>> ECDSA and ECIES. Given that the signing and encryption algorithms are
>> not related like in RSA, I assume it is okay to use the same key for
>> both operations.
>>
>> Are there any things I need to pay attention to when combining both
>> schemes using same keys? Can Bob decrypt messages by forcing Alice to
>> sign messages? (as in naive RSA implementations).
>
>Even if it's technically secure (and I suspect it isn't), in some
>legislations you can be compelled to hand over a decryption key,
>or a dual use key, but not a signature _only_ key.
>http://www.legislation.gov.uk/ukpga/2000/23/section/49/enacted (9)
>
>So at least in some use cases, it's better to keep the signature key
>as a signature only key.


It is "technically secure". See:

http://eprint.iacr.org/2011/615


especially Section 4.

Even so, I would not recommend this approach unless you absolutely have to
use it.

Cheers

Kenny


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)

[Paterson, Kenny]

On 10 Mar 2013, at 11:01, Ben Laurie wrote:

> On 10 March 2013 10:58, Paterson, Kenny  wrote:
>> 
>> 
>> Right here:  http://www.w3.org/TR/WebCryptoAPI:
> 
> Somehow missed that. Thanks.
> 
>> 19.1. Recommended algorithms
>> 
>> This section is non-normative
>> 
>> As the API is meant to be extensible in order to keep up with future
>> developments within cryptography and to provide flexibility, there are no
>> strictly required algorithms. Thus users of this API should check to see
>> what algorithms are currently recommended and supported by implementations.
> 
> So ... despite Ryan's claim that the recommendations are for API
> implementers, it says here that they're also for users of the API.
> 
> In which case, clearly, AE modes should be recommended.

I fully agree. We have already made this point to the WebCrypto folks (see: 
lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0186.html), but without 
managing to bring about a shift in their position.

If people want to see how badly things can go wrong when you mix "legacy" (i.e. 
insecure) and secure algorithms, see, for example this NDSS 2013 paper:

http://www.nds.ruhr-uni-bochum.de/research/publications/backwards-compatibility/

[Full disclosure: I am an author on the paper.]

Cheers

Kenny




___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)

[Paterson, Kenny]

On 10 Mar 2013, at 10:51, Ben Laurie wrote:

On 10 March 2013 01:25, Tony Arcieri 
mailto:tony.arci...@gmail.com>> wrote:
On Sat, Mar 9, 2013 at 4:16 PM, Jeffrey Walton 
mailto:noloa...@gmail.com>> wrote:

The Web Cryptography Working Group looks well organized, provides a
very good roadmap, and offers good documentation.
http://www.w3.org/2012/webcrypto/.

for example they recommend CBC mode which is fraught with
problems.

Where?

Right here:  http://www.w3.org/TR/WebCryptoAPI:

19.1. Recommended algorithms

This section is non-normative

As the API is meant to be extensible in order to keep up with future 
developments within cryptography and to provide flexibility, there are no 
strictly required algorithms. Thus users of this API should check to see what 
algorithms are currently recommended and supported by implementations.

However, in order to promote interoperability for developers, there are a 
number of recommended algorithms. The recommended algorithms are:

  *   HMAC using 
SHA-256
  *   RSASSA-PKCS1-v1_5 using 
SHA-256
  *   ECDSA using 
P-256 curve and 
SHA-256
  *   AES-CBC
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Q: CBC in SSH

[Paterson, Kenny]

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 years ago when the first attacks 
>> popped
>> up.
> Hi Doctor. Out of curiosity, why wait?

The reason to wait, and to approach with extreme care, is contained in my 
previous message to Peter and repeated below. For SSH, it's not as simple as 
ripping out one algorithm/construction and replacing it with another.

> Krawczyk told us how to do authenticated encryption back in 2001.
> Confer: The Order of Encryption and Authentication for Protecting
> Communications (http://www.iacr.org/archive/crypto2001/21390309.pdf).
> He also said the details of the other schemes were tricky to get
> right, and history (failures?) has shown he was correct.
> 

Indeed he did. But his paper does apply in case your protocol is also trying to 
hide message lengths by encrypting them. Some Encrypt-then-MAC instantiations 
(in particular, CBC-mode encryption + any MAC) would also be insecure in SSH.

> I know its nothing new here. I'm just befuddled why standardized
> protocols written in stone by bright folks (IETF, IEEE, et al)
> continue to suffer defects that I don't make/endure (because I listen
> to cryptographers like you).

A simplistic answer: because they prioritise backwards compatibility over 
cryptographic security. In fact, the same thing is happening all over again 
with W3C's Web Crypto effort.

Cheers

Kenny


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Q: CBC in SSH

[Paterson, Kenny]

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 recent past.
> 
> 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 years ago when the first attacks 
> popped 
> up.

I think you're referring to the 2009 Oakland paper here? 

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 that message should be. So the receiver has to 
act on unauthenticated plaintext data. This (in combination with the use of CBC 
mode) is the root cause of the attack.

The attack on SSH would still work exactly as before if you adopted an 
encrypt-then-MAC construction in SSH with the encryption being implemented 
using CBC mode. So your proposal to fix SSH (after we sort out TLS!) should be 
approached with great care. 

Regards

Kenny




___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Q: CBC in SSH

[Paterson, Kenny]

Hi Ralph,

CBC mode is indeed a bad choice for SSH, but for other reasons than  
the recent artacks on TLS. The paper you mention was published as:

Albrecht, Paterson, Watson, Plaintext recovery attacks on SSH.  IEEE  
Symposium on Security and Privacy, 2009

and explains why.

CTR mode in SSH seems to be secure and is now preferred to CBC mode in  
SSH - see my Eurocrypt 2010 paper with Gaven Watson for a formal  
security analysis of this (it's also on eprint:   
http://eprint.iacr.org/2010/095 
)

I'm not aware of any other work on SSH's symmetric encryption since.

Cheers

Kenny

Sent from my iPhone

On 11 Feb 2013, at 19:15, "Ralph Holz"  wrote:

> Hi,
>
> 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 recent past.
>
> I was wondering to which degree the attacks that were possible on SSL
> with AES/CBC might also be applicable to SSH? Quickly asking Google
> yielded things like
>
> http://modular.math.washington.edu/home/wstein/www/home/malb/papers/plaintext_recover_attacks_against_ssh.pdf
>
> http://www.kb.cert.org/vuls/id/958563
>
> I was wondering if there have recently been any more insights?  
> Grateful
> for any pointers.
>
> Thanks,
> Ralph
>
> -- 
> Ralph Holz
> Network Architectures and Services
> Technische Universität München
> Phone +49 89 28918043
> http://www.net.in.tum.de/de/mitarbeiter/holz/
> PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF
>
> ___
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography