[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: |
Test Sv |
|
Subject: |
Re: [Linphone-developers] Fw: Re: bzrtp support for AES with 256-bit keys |
|
Date: |
Fri, 23 Jan 2015 08:04:28 -0800 |
Hello Peter;
You are making a valid point.
However, your point is a two way street. You say "all known cryptologists I've
ever read consider AES 128 to still be unbreakable". You too did not provide
your sources and their credintials. In my case, most of known cryptologists
I've ever read consider AES-128 is easily breakable. You also did not define
unbreakable: is it unbreakable in one or few days, or in 10,000 years?!. If I
have the time, I will try to send you some of those sources. You try to do the
same with your sources.
However, in anycase, the military grade encryption is based on aes-256, not
aes-128. In some case they will encrypt the info several times, up to three
times for increased security. I hope you at least accept that fact without the
need for any sources?!. Another point here is how serious the user about
encryption?.
Cheers;
--------------------------------------------
On Fri, 1/23/15, Peter Villeneuve <address@hidden> wrote:
Subject: Re: [Linphone-developers] Fw: Re: bzrtp support for AES with 256-bit
keys
To: address@hidden
Date: Friday, January 23, 2015, 10:43 AM
>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.
Guillaume
BIENKOWSKIhttp://www.belledonne-communications.com/
sip:address@hidden
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
-----Inline Attachment Follows-----
_______________________________________________
Linphone-developers mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/linphone-developers