<unnamed>

Public Key

npub1f2v97kt6qhpp6eey57fvtf8yw29rh02nz6rc4zvt2306l6s9nl9swsvzp8

Profile Code

nprofile1qqsy4xzlt9aqtssavuj20yk95nj89z3mh4f3dpu23x94gha0agzeljcprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqyxhwumn8ghj7mn0wvhxcmmvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsn606hg

Publishing to

relay.snort.social

nos.lol

relay.damus.io

Last Notes

2023-06-07 18:09:34 UTC

- reply

📅 Original date posted:2018-01-18
📝 Original message:> If being secure against partial share leakage is really part of your
> threat model the current proposal is gratuitously insecure against it.
I don't think that is true. Shared secret is an input of KDF which
should prevent this kind of attack.
> If partial share disclosure were an actual concern, I would recommend
> that after sharing and before encoding for transmission (e.g. before
> applying check values and word encoding to the share) the individual
> shares be passed through a large block unkeyed cryptographic
> permutation. Under reasonable-ish assumptions about the difficulty of
> inverting the permutation with partial knowledge, this transformation
> would prevent attacks from leaks of partial share information.
Actually, we've been considering something like that. We concluded that
it is to much "rolling your own crypto". Instead of diffusion layer we
decided to apply KDF on the shared secret.

2023-06-07 18:09:34 UTC

- reply

📅 Original date posted:2018-01-22
📝 Original message:>
> My post provided a concrete example. I'd be happy to answer any
> questions about it, but otherwise I'm not sure how to make it more
> clear.
My apologies, I didn't read it carefully. You are absolutely right. Our
scheme doesn't protect against the scenario.
> Quite the opposite-- a large block cipher is a standard
> construction
I'm happy to hear it. Nevertheless, I didn't find any standartisation or
implementation of the CMC mode (excluding the paper).
Do you have some experience with other modes (such as HCTR, HEH)?

2023-06-07 18:09:33 UTC

- reply

📅 Original date posted:2018-01-18
📝 Original message:Thank you for your comments, Gregory and Russell!
Gregory, thank you for you explanation of perfect secrecy, there is no
need for that, however. I'm professional mathematician and cryptographer.
> I read the above
> as "these are similar because they are based on math"...
They are based on algebra (group and commutative ring theory), which is
a great similarity. RSA and SHA, for example, are based on completely
distinct parts of mathematics.
> Complicated does not mean secure. And from an information theoretic
> perspective the hash does almost nothing (other then some small
> destruction of entropy due to its lack of perfect uniformity which is
> information theoretically equivalent to using a smaller perfect code).
> using error correcting codes and truncated hash functions create
identical amounts of information theoretic redundancy
I agree, see my last note in the previous mail. Adding redundancy by a
hash function is more secure than adding redundancy by a linear
relations. Just my opinion.
I see the difference between RSA and SSS you mentioned and I understand
your arguments about perfect secrecy. Just two comments:
(1) Our proposal doesn't use SSS for the whole secret, but it divides
the secret into bytes and uses SSS for every byte separately. This
scheme is weaker because to reconstruct n-th byte it suffices to have
n-th bytes from k shares.
(2) SSS is information-theoretic secure if you know k-1 or less
shares, where k is the threshold. But the proof doesn't hold if you know
for example a small part of every share.
> It is of no use to apply the precautionary principle against
impossible attacks, especially at the cost of losing the useful
properties of a real error correcting codes that would provide actual
guarantees against likely errors.
The discussion isn't about mathematics or about security proofs but
about cryptographic scheme design. In our use case you cannot assume
that all premises of security proof theorems (including SSS's perfect
secrecy) hold true (see the comment above).
In my opinion, to make a cryptographic scheme more robust it's better to
stick to general "intuitive" principles. Of course you have to consider
the advantages and disadvantages of this approach. That's why we
disclosed our draft and welcome all comments.
> The discussion of using a proper code was primarily related to the
> outer check value which protects the shares themselves and is sitting
> unprotected in plaintext
OK then. I was defending the hash in the inner check value.

2023-06-07 18:09:31 UTC

- reply

📅 Original date posted:2018-01-17
📝 Original message:The entropy argument is as follows:
There is a rule of thumb which says it is safer plaintext to have low
redundancy, see
https://en.wikipedia.org/wiki/Redundancy_(information_theory), i. e.
it's better to encrypt random or compressed data than natural language.
This rule is based on Shannon's information theory which means that a
breach of the rule usually doesn't induce a vulnerability (there is no
known generic attack). This rule is application of a precautionary
principle.
Nevertheless, here are some examples of cryptographic attacks which may
be considered as a consequence of the breach of the rule:
* Related Message Attack by Coppersmith, Franklin, Patarin, Reiter
(https://pdfs.semanticscholar.org/899a/4fdc048102471875e24f7fecb3fb8998d754.pdf)
- given RSA ciphertext of two plaintexts x and a*x + b, where a, b are
known, it's possible to effectively compute x provided public exponent
is three. From the informaton-theoretic point of view the second message
is redundant, because it's determined by the first one. Which means that
relative redundancy of both messages is at least one half.
* Stereotyped Messages by Coppersmith
(https://www.di.ens.fr/~fouque/ens-rennes/coppersmith.pdf, section 7) -
given RSA ciphertext and (1-1/e) fraction of plaintext (where e is
public exponent), it's possible to effectively compute x. Message is
highly redundant, because only 1/e of the message is unknown. Relative
redundancy of the message is at least (1-1/e).
Consider a few notes:
* Nowadays there exists more complicated variants of mentioned attacks
which have weaker premisses.
* There is a considerable similarity between RSA and SSS. Both schemes
are algebraically-based (rather than boolean function based).
* CRCs (and error-correcting codes generally) introduce redundancy
into the message. Moreover the redundancy is induced by a linear
relationship among message (compare with the premise of the Related
Message Attack).
* Related Message Attack wouldn't be possible if you had two
plaintexts x and hash(x). The relationship between messages has to be
(algebraically) uncomplicated. From the information-theoretic point of
view the situation is the same, but from the practical point of view it
is completely different.
To sum it up, there is a precautionary principle which tells us not to
increase redundancy of a message unless it is introduced in a
complicated way (for example by a hash function). That's why we use SHA
rather than CRC. One more reason why we stick to the principle is that
there's no randomisation in our scheme (such as padding or
initialisation vector). We understood advantages of error-correctings
codes over hash functions (minimal codewords distance property,
performance) and we considered it thoroughly.
Ondřej Vejpustek