RE: Security Practices

From: Mark Senior (Mark.Senior_at_gov.ab.ca)
Date: 05/18/05

  • Next message: daniel.engelsen_at_caremark.com: "RE: remote ssh for root"
    Date: Wed, 18 May 2005 10:08:31 -0600
    To: "Bryan McAninch" <bryan@mcaninch.org>
    
    

    Very interesting paper, I shall have to give it the time for a thorough
    read.

    If my understanding of the paper is correct, then that attack would
    apply to just about any cipher that makes heavy use of S-boxes. That
    includes RC4, AES, blowfish, and [3-]DES, so you don't have much
    possibility of choosing unaffected algorithms in SSH, unless some
    obscure implementation build around Helix instead of block ciphers and
    HMAC should arise...

    Cheers
    Mark

     

    > -----Original Message-----
    > From: Bryan McAninch [mailto:bryan@mcaninch.org]
    > Sent: May 17, 2005 14:34
    > To: secureshell@securityfocus.com
    > Subject: RE: Security Practices
    >
    >
    > The AES attack described by Dan Bernstein is impractical, as
    > it requires an enormous amount of known plaintext and is very
    > timing sensitive.
    > Furthermore, the issue does not lie within the algorithm
    > itself, but rather how it is implemented. The paper
    > specifically states that OpenSSL is vulnerable, which makes
    > OpenSSH vulnerable to the attack as well.
    >
    > Stick with AES.
    >
    > Cheers,
    >
    > Bryan
    >
    > -----Original Message-----
    > From: Nigel Stepp [mailto:stepp@atistar.net]
    > Sent: Tuesday, May 17, 2005 12:14 PM
    > To: David Busby
    > Cc: secureshell@securityfocus.com
    > Subject: Re: Security Practices
    >
    > David Busby wrote:
    > > List,
    > > I'm trying to get my a sshd setup as secure as possible,
    > some folks
    > > I know what to send financial data over this.
    > ...
    > > aes256-cbc cipher (only)
    >
    > http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
    >
    > You may want to be aware of this paper. I believe the
    > results are still preliminary, but it's something to follow.
    >
    > > I'm thinking that
    > > I'll make my key 4096bits to add some security.
    >
    > Heh, is your name Avi? (cryptonomicon reference, couldn't
    > resist) That's probably overkill, but that assumes no
    > codebreaking paradigm shifts or what have you.
    >
    > > Assume best means most secure even at
    > > the sacrifice of performance. Thanks!
    >
    > If you're going to use 4096 bit keys, you may want to move
    > away from md5 as a hashing algorithm, since it has been shown
    > to have some measure of weakness. You might look at SHA256,
    > SHA512, or something like whirlpool.
    > I'm not an expert, however, and I'm not sure how proven
    > whirlpool really is (or about the measure of support of these
    > hashes in ssh).
    >
    > > /djb
    >
    > --
    > :wq
    >
    >
    >

    This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

    This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.


  • Next message: daniel.engelsen_at_caremark.com: "RE: remote ssh for root"

    Relevant Pages

    • Re: Only people who originally frequent sci.crypt reply to this
      ... The mode of a cipher is one of the many, ... you need to get right in order to turn a secure algorithm into a secure ... there are no known attacks against AES. ... attack of any kind against a cipher, ...
      (sci.crypt)
    • Re: AES Timing Attack Implementation & Karl Malbrain code...
      ... |> Does this imply that an algorithm using large tables is susceptible to ... | This type of attack needs to be considered in any situation in which ... | need to be thought about during system design in order to determine ... most all contemporary machines have extensive caching with AES. ...
      (sci.crypt)
    • Re: AES Timing Attack Implementation & Karl Malbrain code...
      ... | This code implements AES without using large tables. ... |> to replicate the bernstein results. ... | typically vulnerable to this attack. ... Does this imply that an algorithm using large tables is susceptible to this ...
      (sci.crypt)
    • Re: AES Timing Attack Implementation & Karl Malbrain code...
      ... |> Does this imply that an algorithm using large tables is susceptible to ... | This type of attack needs to be considered in any situation in which ... most all contemporary machines have extensive caching with AES. ... if an attacker has been able to put a timing ...
      (sci.crypt)
    • Re: Quadruple Algorithms
      ... occurring" (a fatal flaw being found in AES, ... the most likely attack on your entire system, ... Threat one: Your implementation of AES has an undiscovered ... with the output of one cipher feeding ...
      (sci.crypt)

  • Quantcast