Natanael writes:
> This assumes performance requirements only comes from settings like
> datacenters, but this is also likely to eventually get used in embedded
> devices some of which may be battery powered. Consider NFC devices such as
> security keys (typically 1-10 mW, less than 100 Kbps, and f
Den ons 17 jan. 2024 21:11D. J. Bernstein skrev:
>
> > if we manage to eliminate a significant (albeit not huge)
> > amount of cycles through a careful security analysis that needs to be
> > done once, I expect this to be helpful for adoption.
>
> I don't see how this argument survives quantifica
> > This reduces load on security reviewers: everyone can see that the full
> > ct is included in the hash, without having to worry about KEM details.
> Here I disagree: the security analysis needs to be done *once* (and
> has been done, but of course still needs review; ideally also
> computer-ver
"D. J. Bernstein" wrote:
> Peter Schwabe writes:
Dear Dan, dear all,
> > we would like to have an answer to the question "What KEM should
> > I use" that is as simple as
> > "Use X-Wing."
>
> Having an easy-to-use, prepackaged answer is great!
Glad to hear that we agree!
> What I'm saying
Peter Schwabe writes:
> we would like to have an answer to the question "What KEM should
> I use" that is as simple as
> "Use X-Wing."
Having an easy-to-use, prepackaged answer is great! What I'm saying is
that the easy-to-use, prepackaged answer should _internally_ use a
combiner that includes
Ilari Liusvaara writes:
> I am not one of draft authors, but I tried to estimate the overhead
> and ended up with in ballpark of 7%.
To clarify, you mean that the _cycle_ counts go up by 7%?
My comparison was explicitly against the cost of "communicating the
ciphertexts". That's a much larger cos
On Thu, Jan 11, 2024 at 01:58:07PM -0600, Orie Steele wrote:
> Hybrids by their very nature are the explosion.
>
> If there will only ever be X-Wing, I think it's fine to not make it generic
> (since we admit that it is a special case, not an instance of a generic).
>
> However, if B-Wing (brainp
Ilari Liusvaara wrote:
> On Tue, Jan 16, 2024 at 08:49:24AM -0800, Eric Rescorla wrote:
> > On Tue, Jan 16, 2024 at 8:24 AM D. J. Bernstein wrote:
Dear Ilari, dear all,
> > > To be clear, I think other concerns such as efficiency _can_ outweigh
> > > the advantages of unification, but this has
On Tue, Jan 16, 2024 at 08:49:24AM -0800, Eric Rescorla wrote:
> On Tue, Jan 16, 2024 at 8:24 AM D. J. Bernstein wrote:
>
> > To be clear, I think other concerns such as efficiency _can_ outweigh
> > the advantages of unification, but this has to be quantified. When I see
> > a complaint about "ha
On Tue, Jan 16, 2024 at 8:24 AM D. J. Bernstein wrote:
> Bas Westerbaan writes:
> > X-Wing is a KEM - not a combiner.
>
> Sure, but there's a combiner present inside it---and even advertised:
> see "X-Wing uses the combiner" etc. at the beginning of this thread.
>
> If people are motivated by thi
Bas Westerbaan writes:
> X-Wing is a KEM - not a combiner.
Sure, but there's a combiner present inside it---and even advertised:
see "X-Wing uses the combiner" etc. at the beginning of this thread.
If people are motivated by things like http://tinyurl.com/5cu2j5hf to
use the same combiner with a
>
> The arguments for multiple KEMs are
> stronger than the arguments for multiple combiners.
>
X-Wing is a KEM — not a combiner. I agree there should preferably be one
go-to generic combiner. Insisting that X-Wing use that generic combiner, is
not dissimilar to insisting that every KEM that uses
Jack Grigg writes:
> As the paper states at the top of page 4, X-Wing includes the recipient's
> X25519 public key "as a measure of security against multi-target attacks,
> similarly to what is done in the ML-KEM design".
Thanks for the data. Assuming arguendo that this matters (as in my first
mes
On Mon, Jan 15, 2024 at 11:21 PM D. J. Bernstein wrote:
> If the goal is maximum streamlining for IND-CCA2 then
> one shouldn't include the _recipient's_ X25519 public key in the hash,
> so why exactly does X-Wing include it?
>
As the paper states at the top of page 4, X-Wing includes the recipi
> > 2. I think it's good that both of the X25519 public keys are included
> > where some hybrid constructions would include just one (labeled as
> > ciphertext).
> And it is required for the IND-CCA robustness: without it, it's not.
Well, that depends on _which_ X25519 key is included in the hash.
Scott Fluhrer (sfluhrer) writes:
> If we have a combiner with a proof that âif either of the primitives
> we have meet security property A, then the output of the combiner
> meets security property Bâ, and we have proofs that both our
> primitives meet security property Aâ, then doesnât tha
Bas Westerbaan writes:
> At the moment the choice of hybrid is left to the application/protocol.
> This has led to many different proposals for hybrids, which wastes a lot of
> engineering, standardisation and security review time. I think it's better
> if hybridisation is done at the level of cryp
On Thu, Jan 11, 2024 at 10:48 PM Martin Thomson wrote:
>
>
> On Thu, Jan 11, 2024, at 07:13, Bas Westerbaan wrote:
> > X-Wing aims for 128-bit security, and for that combines the time-tested
> > X25519 with ML-KEM-768 [8]. X-Wing uses the combiner
> >
> > SHA3-256( xwing-label || ss_ML-KEM || s
I can’t say I agree with this argument.
If we have a combiner with a proof that “if either of the primitives we have
meet security property A, then the output of the combiner meets security
property B”, and we have proofs that both our primitives meet security property
A”, then doesn’t that mea
Hybrids by their very nature are the explosion.
If there will only ever be X-Wing, I think it's fine to not make it generic
(since we admit that it is a special case, not an instance of a generic).
However, if B-Wing (brainpool + kyber) and P-Wing (p curve + kyber) also
end up getting made, we ne
I very much appreciate having a concrete hybrid scheme that is
intentionally not generic. This avoids the explosion of ciphertext suites
that would otherwise occur, and allows for better compatibility of
libraries. Fixing the key sizes to ML-KEM 768 and X25519 is aligned with
our preferred choices
I'm going to echo Bas to highlight that X-Wing is not generic to any IND-CCA
KEM, it is a particular primitive construction based on the internal
construction of ML-KEM in particular:
I don’t think it’s our place to try to shoe-horn everything into one construct.
Particularly when we are in th
I'm going to echo Bas to highlight that X-Wing is not generic to any
IND-CCA KEM, it is a particular primitive construction based on the
internal construction of ML-KEM in particular:
> Note that it doesn’t hash in the ML-KEM ciphertext. For a generic KEM one
cannot leave out the ciphertext, but i
+1 on making X-Wing a generic construction and stir in the KEM ciphertext.
In the ML-KEM case, the SHAKE256 cost of an additional 1-1.5KB ciphertext c2
will be miniscule compared to the other operations. And this will be similar
for other KEMs are well.
For example, from https://bench.cr.yp.to/
Hi Dan,
Thanks for your detailed comments.
Bas Westerbaan writes:
> > SHA3-256( xwing-label || ss_ML-KEM || ss_X25519 || ct_X25519 || pk_X25519
> > )
>
> 1. I'd include the post-quantum ciphertext (or a hash of it). Rationale:
> This makes the construction more generic,
This construction is not
Do we have a survey of hybrid patents?
To be clear, for security reasons I recommend a straightforward policy
of always using hybrids (https://blog.cr.yp.to/20240102-hybrid.html).
NIST reportedly bought out some hybrid patents; I'm not aware of hybrid
patents that predate the clear prior art; and
26 matches
Mail list logo
