linphone-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-developers] Fw: Re: bzrtp support for AES with 256-bit key


From: Peter Villeneuve
Subject: Re: [Linphone-developers] Fw: Re: bzrtp support for AES with 256-bit keys
Date: Fri, 23 Jan 2015 15:43:23 +0000

>Those users should know that most of people
> can crack aes-128 without any difficulty.

Really? Who exactly? And how can "most people" crack AES-128?

I'm sorry but a bold statement like that needs some kind of basis in fact. What are your sources considering all known cryptologists I've ever read consider AES 128 to still be unbreakable.

Cheers,

Peter

On Fri, Jan 23, 2015 at 2:20 PM, Guillaume BIENKOWSKI <address@hidden> wrote:
Hello Test SV,

From Gmail's point of view, all your messages are marked as spam, this is the error messages that pops up when I look at your messages from my spam folder:

Why is this message in Spam? It has a from address in yahoo.com but has failed yahoo.com's required tests for authentication.  Learn more

(link is https://support.google.com/mail/answer/1366858?hl=en&expand=5 )

Maybe that's the reason.



On Fri, Jan 23, 2015 at 3:07 PM, Test Sv <address@hidden> wrote:




I am sending this email again after I received a very strange message from linphone in response to the email that my membership has been disabled due to excessive bounces which I am very clean what it means?!.






--- On Fri, 1/23/15, Test Sv <address@hidden> wrote:

> From: Test Sv <address@hidden>
> Subject: Re: [Linphone-developers] bzrtp support for AES with 256-bit keys
> To: address@hidden
> Date: Friday, January 23, 2015, 8:00 AM
>
>
>
>
>
> Hello;
>
> Nice
> job by the developers team at Simlar. It is an important new
> capability to linphone that many users needed and would like
> to use.
>
> In general, aes-256
> is highly recommended as by far the best encryption method
> currently available.  Although, there are well known
> serious vulnerabilities in some of the implementations for
> aes-256 which undermind the algorithm. Few years ago, at
> least one serious vulnerability was identified in zrtp, and
> was corrcted later by most of people.
>
> Therefore, aes-256 should be the default
> encryption on linphone that is automatically available to
> the user out of the box after installation (i.e. without
> having to go to the settings menu). Users who are interested
> in down grading to the aes-128, they can go to the settings
> menu to do so. Those users should know that most of people
> can crack aes-128 without any difficulty.
>
> To the best of my knowledge,
> linphone and bzrtp never been subjected to an indepedent and
> complete security audit. There are several organizations in
> Russia and Europe that provide such a highly specialized
> audit.
>
> Keep up the good
> work Simlar.
>
> Cheers;
>
>
>
>
>
>
> --------------------------------------------
> On Fri, 1/23/15, Johan Pascal <address@hidden>
> wrote:
>
>  Subject: Re:
> [Linphone-developers] bzrtp support for AES with 256-bit
> keys
>  To: address@hidden
>  Date: Friday, January 23, 2015, 6:15 AM

>
>  Hi Ben,
>  and
> thanks for the patch.
>
>  I
> had a quick look at it, very nice rework on
>
> the tests cases!
>
>  Few
>  remarks:
>  - I think we should
> stick to AES128
>  being the default (switch
> in
>  bzrtpCrypto_getAvailableCryptoTypes).
> The user
>  will set it to AES256 if
>  needed.
>
>  -
> You may want to export also
>  the algorithm
> defines and not only the
>  types in bzrtp.h
> (commit 4) otherwise the user
>  won't be
> able to safely
>  use the get/set
>  functions.
>
>
> - We shall
>  ensure that mandatory algorithms
> are always present in the
>
>
> context supported list, by either checking
>
> their presence in the input
>
> supportedTypes
>  of
> bzrtp_setSupportedCryptoTypes and queing them at the
>  end if they are missing or tweaking the
>  selectCommonAlgo to add them if
>  they are
>  missing.(first one
> seems cleaner)
>
>  - Same
> kind of problem (which was already there
>
> before your patches)
>  with the incoming
>  HelloPacket parsing: we shall ensure that if
> the
>  packet doesn't contain a mandatory
> algo, it
>  is added at the end of the
>  list as
>  specified in the RFC
> section 5.2:
>  "If a
>
> mandatory algorithm is not included in the list, it
>      is implicitly added to the end of the
>  list for preference."
>
> Which means the
>  in function
> bzrtp_packetParser, all the tests on
>
> messageData->xx == 0 to set the mandatory
>  algo shall be replaced by
>
> something
>  checking the presence of the
> mandatory algo in the
>  messageData->xx
> field after parsing it from
>  the packet.
>
>  - min function
>  seems fine to me as it is.
>
>
>  I'll have to rework the mediastream
> patch
>  as I've done some
>  modifications in
>  zrtp.c,
> they're in branch dev_dtls for now but will be
>
>  merge to master soon.
>
>  regards,
>
>
>  johan
>
>
>
>
>  On 23/01/15 03:58, Ben
> Sartor
>  wrote:
>  > Hi
> Johan,
>  >
>  > thanks
> for you
>  answer. I have tried to implement
> things like you
>  suggested.
>
> >
>  > Patches
>  0001 and
> 0002 are unchanged.
>  >
>
> > Patches 0003 to 0005 add the the getter
>  and setter you suggested.
>
> >
>  > Patches 0006 to 0009 implement
> the tests.
>  I completely refactored the
> function
>  >
>
> "test_algoAgreement". Is it ok for you to write
>  tests this way?
>  >
>  >
>  Patches 0010 to 0012 are
> some code cleanup suggestions and
>  were not
> discussed
>  > before. Let me know
>  what you think.
>  > Is there
> a better place
>  for the min-function? Maybe
> even a macro like
>  > discussed here [1]?
> Is
>  "__typeof__" ok?
>  >
>  > [1] http://stackoverflow.com/questions/3437404/min-and-max-in-c
>  >
>  > The
> mediastreamer2
>  patch of my initial post
> still applies and may be used
>  for
>  > testing.
>  >
>  > Kind Regards,
>
> >   Ben
>  >
>
> >> Hi Ben,
>  >>
>
> >>> Yes. Just to be sure, did you mean
>  implementing functions like this:
>  >>>
>  >>>
> void
>
> bzrtp_setSupportedCipherTypes(bzrtpContext_t
> *zrtpContext,
>  uint8_t
>
> >>> availableTypes[7],
>  const
> uint8_t availableTypesCount);
>
> >>>
>  >>>
>
> uint8_t bzrtp_getSupportedCipherTypes(bzrtpContext_t
>  *zrtpContext, uint8_t
>
> >>>
>  availableTypes[7]);
>  >>
>  >> Yes but you
> want to add an uint8_t
>  algoType
> argument(just like
>  >>
>  bzrtpCrypto_getAvailableCryptoTypes function)
> to both of
>  them in order
>
> >> to use the same
>  function to
> get/set the available algos for block
>
> >> cipher/key exchange/SAS
>
> rendering/Hash.
>  >>
>
> >>>> This means we also must add a
>  way to store the user configuration in
>  >>>> linphone. I was thinking
> the
>  easiest way would be to store it in
> the
>  >>>> config file and access
> it only
>  manually for now. I can implement
> this if
>  >>>> you're lost on
> the way
>  linphone manage the config file.
>  >>>
>  >>>
> I
>  haven't had a look to  linphone
> config file management,
>  yet. Let's
> see
>  >>> how far I
>
> get or if you find time first.
>  >>
>  >> It's quite simple, but if you
>  struggle tell me and I'll have a look
> at
>  >> it when you're done with
> bzrtp. We
>  can use an already existing
> config
>  >>
>  setting
> used to select SRTP protection profile(see misc.c
>  const
>  >> MSCryptoSuite
> *
>
> linphone_core_get_srtp_crypto_suites(LinphoneCore *lc);)
>  >> for the block cipher algo
> selection
>  and do something for the other
> algo
>  >>
>  types when
> needed.
>  >>
>
> >>>> Last, this must be covered by
>  automatic tests.(Key exchange between two
>  >>>> users using different set
> of
>  cipher block algo)
>
> >>>
>  >>> I'm not sure
> what you mean:
>  Would you prefer a test
> similar to the
>  >>> existing
>  >>> "test_algoAgreement"
> or
>  would it be better to write a test for
> the
>  >>> function
>
> >>> "selectCommonAlgo"
>
> directly?
>  >>
>
> >>
>  I was thinking of extending the
> test_algoAgreement to
>  include block
>  >> cipher selection and
>
> some test on linphone call to check correct reading
>  >> of the configuration from file, but
> it
>  can't harm to have a test for the
>  >> selectCommonAlgo too.
>  >>
>  >> Thanks
> for
>  your contribution.
>
> >>
>  >> Have a good day
>  >>
>  >> johan
>  >>
>  >>
>
> _______________________________________________
>  >> Linphone-developers mailing list
>  >> address@hidden
>  >> https://lists.nongnu.org/mailman/listinfo/linphone-developers
>  >
>  >
>
> >
>  >
>
> _______________________________________________
>  > Linphone-developers mailing list
>  > address@hidden
>  > https://lists.nongnu.org/mailman/listinfo/linphone-developers
>  >
>
>
> _______________________________________________
>  Linphone-developers mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/linphone-developers
>

_______________________________________________
Linphone-developers mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/linphone-developers


_______________________________________________
Linphone-developers mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/linphone-developers



reply via email to

[Prev in Thread] Current Thread [Next in Thread]