On 16 November 2015 at 19:52, Eric Rescorla wrote:
>> I have to ask why the continued insistence on calling the thing that
>> forms part of the nonce an "IV". I find it to be misleading.
>
>
> This is the historical terminology that TLS has used.
It was actually accurate when we were using CBC m
Hello,
Unfortunately the system doesn't allow me to attach .c files.
The documented source code is on my blog:
http://ismail-kizir.blogspot.com.tr/2015/11/hohha-dynamic-xor-algorithm-source-code.html
I am also regularly updating the site.
Please feel free to ask any questions.
Regards
Ismail Kiz
Please reply to me, I will summarize.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hello,
I've developed a new encryption algorithm, which dynamically changes the
key according to plaintext and practically impossible to break. I also
opened to public with MIT License.
It is also quite fast; ~80% faster than the fastest mode of AES without cpu
instruction set support.
I will pres
On Mon, Nov 16, 2015 at 7:01 PM, Martin Thomson
wrote:
> I have to ask why the continued insistence on calling the thing that
> forms part of the nonce an "IV". I find it to be misleading.
>
This is the historical terminology that TLS has used.
>
> Also, it might be worth noting that the stri
I have to ask why the continued insistence on calling the thing that
forms part of the nonce an "IV". I find it to be misleading.
Also, it might be worth noting that the string "early data key
expansion, server write " is never needed.
On 16 November 2015 at 17:25, Eric Rescorla wrote:
> https:
https://github.com/tlswg/tls13-spec/pull/346
As discussed in Seattle and Yokohama, I've broken out the traffic key
generation
into individual values. This makes life somewhat easier for those dealing
the
cryptographic modules, because some of this data needs to be public and some
of it needs to be
Double-checking, I see that some of the entries in the "TLS 1.3" column
for Extensions are wrong. Will be updating shortly.
On Mon, Nov 16, 2015 at 3:16 PM, Eric Rescorla wrote:
> PR: https://github.com/tlswg/tls13-spec/pull/345
>
> Per discussion in Yokohama, I have rewritten the IANA considera
PR: https://github.com/tlswg/tls13-spec/pull/345
Per discussion in Yokohama, I have rewritten the IANA considerations section
so that the 16-bit code spaces are "Specification Required" and they have
a "Recommended" column.
1. The Cipher Suites "Recommended" column was populated based on
the
[Reordering your message slightly so the important question is first.]
[MB] When I say “application,” I mean the code being hosted by the web
server that’s actually responding to the interpreted requests. While I’d
like to minimize code changes in the HTTP server, my primary constraint is
that I
10 matches
Mail list logo
