Is it possible to recover an RSA modulus from its signatures?

calculate
$$gcd(c_1^e - m_1 , c_2^e- m_2, \dots , c_k^e-m_k)$$

With a bit luck this should get $n$.
It will be an interesting exercise to calculate the probability of success based on the number of cleartect/ciphertext pairs.


Why algorithmic symmetry is important in hardware implementation?

Symmetry is something that is inherent in the design of SPN ciphers.  It doesn't explicitly make the layout of the cipher smaller, but it definitely helps.  You also see this in AES-NI where you can pipeline AES so each round is an instruction as you can just put latches on the boundaries.  For Feistel Ciphers, or Simon at least, I just run the ciphers as asynchronous circuits because they do not integrate as well on a per-round into a traditionally synchronous processors (even if they are much smaller in layout).

In hardware, symmetry is generally desired so that your wires stick on the same layers.  You have a stack of metal, and you generally run Metal 1 (M1) one direction and Metal 2 (M2) in the other direction. You just pick a direction for the data to "flow" On smaller processes with metal patterning, you find that you are forced in direction, also M1A and M1B need to go to M2 to make connections.

This "flow" is what helps AES implement nicer in hardware because of the nature of 8 in to 8 out bits of the S-Box and MixColumns.

The layout of an XOR in 14nm SOI looks like the following:

The two different colours of blue are the metal 1 lines for the tile (M1A is light blue, M1B is dark blue). I use this same layout for all of my cells, so I have the data flow from the top of the tile down.  I interrupt the M1A lines to go to M2A, and M2B (they are thicker because of M3 via rules in case I go M1->M2->M3)


Self-correcting encryption. What are the essential elements?

if there's an inner-layer error correcting code, will it be able to work without an encryption algorithm based on a stream cipher?

Depends on how the inner error correcting code works; what you want is an encryption method that does not radically increase the 'size' of any ciphertext errors (where 'size' is what's relevant to the error correcting code), given the likely ciphertext errors (and I believe that on Optical disks, burst errors are far more common than random unrelated bit flips).  If it is (for example) a Reed Solomon code, that means that it would not increase the number of incorrect (modified) symbols; there are alternatives (other than stream ciphers) with this property.
However, that does beg the question: "what do you hope to gain with this structure?"  Wouldn't this structure at least as good:

Encryption

"Inner" error correcting code

"Outer" error correcting code

(or combine "inner" and "outer" if that makes more sense).  That would (to me) appear to be at least as good with dealing with errors (and you don't have to select your encryption method with the error correcting code in mind)


Can zero knowledge proof and zero knowledge proof of knowledge transfer to each other?

A zero-knowledge proof $\rho$ demonstrates that an instance $\phi$ is in a relation $R$, i.e. there exists $w$ such that $(\phi, w) \in R$.

A zero-knowledge proof of knowledge $\pi$ for an instance $\phi$ demonstrates that the random tape of the PPT algorithm that calculated $\pi$ can be used as the input to a PPT extractor to output $w$ such that $(\phi,w) \in R$.

If $w$ does not exist, then there can be no such extractor.  Thus any zero-knowledge proof of knowledge is also a zero-knowledge proof.  However, not every zero-knowledge proof is a zero-knowledge proof of knowledge.  In particular, Groth-Sahai proofs do not have knowledge extraction.


Result of expressions using modular arithmatic for group signatures

The $\text{ mod } N$ is implied in all equations below.

In the signing process we have:

$$d_2 = T_2^{r_1} / g^{r_3}$$

In the verification process we have:

$$d_2 = T_2^{s_1 - c2^{\gamma_1}} / g^{s_3}$$

So we know that we must have the following equivalence:

$$T_2^{r_1} / g^{r_3} = T_2^{s_1 - c2^{\gamma_1}} / g^{s_3}$$

Substituting in the values for $s_1$ and $s_3$ we have:

$$T_2^{r_1} / g^{r_3} = T_2^{r_1 - ce_i + c2^{\gamma_1} - c2^{\gamma_1}} / g^{r_3 - ce_iw}$$
$$T_2^{r_1} / g^{r_3} = T_2^{r_1 - ce_i} / g^{r_3 - ce_iw}$$

From the paper we know that $T_2 = g^w$ and we can also use some exponent laws to simplify:

$$(g^w)^{r_1} / g^{r_3} = (g^w)^{r_1}(g^w)^{-ce_i} / g^{r_3}g^{-ce_iw}$$
$$g^{wr_1} / g^{r_3} = g^{wr_1}g^{-ce_iw} / g^{r_3}g^{-ce_iw}$$
$$g^{wr_1} / g^{r_3} = g^{wr_1} / g^{r_3}$$

Hence the equation provided are correct, and the verify procedure does indeed produce the same $d_2$ as the sign procedure. If you are producing incorrect results one thing to remember is that division $\text{ mod } N$ is equivalent to multiplication by the multiplicative inverse of the denominator.


Solution to Discrete Log as a Commitment

Obviously, this scheme is not perfectly hiding. But assuming the discrete logarithm is hard, receiver or an adversary can't determine the committed message prior to reveal, so I believe this provides computational hiding.

If the receiver had no other information about $m$, then you would be correct.
On the other hand, we typically assume that he has some information; the acid test is "if the receiver knew the committed value was either $m_0$ or $m_1$, he still cannot determine which it is from the commitment".
Obviously, your approach (or, for that matter, any deterministic method) cannot fulfill that requirement; you need to include some randomness to meet this criteria.


Although the answer is already accepted, I'll add an answer with a different look on things.

It's safe, but that's not what HKDF-expand should be used for. The idea of HKDF-expand is to call it twice, once for each key, using the info element to distinguish between the two (e.g. info could be an ASCII encoding of the key name). Note that HKDF should have a relatively short running time.
Although it is not required, it is best to use a salt. So unless there is some important reason not to, use a salt. For KBKDF's a salt is unusual, but the authors seem to think it is important; see the quote underneath this answer.
You could, however I would urge you to independently generate it using HKDF-expand, see answer (1).

Quote for part #2 (see 3.1 of the RFC):

  We stress, however, that the use of salt adds significantly to the
     strength of HKDF, ensuring independence between different uses of the
     hash function, supporting "source-independent" extraction, and
     strengthening the analytical results that back the HKDF design.


Difference between implicit signature and explicit signature

Actually, I never heard of the notation of an implicit signature before. However, when looking at MQV, there is a quantity which is denoted as an implicit signature, which is nicely described here:

  The MQV elliptic curve key agreement method is used to establish a shared secret between parties who already possess trusted copies of each other’s static public keys. Both parties still generate dynamic public and private keys and then exchange public keys. However, upon receipt of the other party’s public key, each party calculates a quantity called an implicit signature using its own private key and the other party’s public key. The shared secret is then generated from the implicit signature. The term implicit signature is used to indicate that the shared secrets do not agree if the other party’s public key is not employed, thus giving implicit verification that the public secret is generated by the public party.

Nevertheless, this only seems to be a terminology in context of MQV and not a common concept.

Edit (a more general justification of the wording)

A generic way to realize an authenticated key exchange (AKE) from Diffie-Hellman is to execute a Diffie-Hellman key exchange and to sign all the communication sent between the parties, i.e., party Alice and Bob own a key pair of some secure digital signature scheme each (where the authentic public verification key is known to the other party) and every party signs each sent message using its private signing key. Such an AKE protocol is sometimes also referred to as Signed Diffie-Hellman. I assume that this sometimes may also be referred to a as explicit signature, since every party computes explicit signatures for the messages and the construction is generic, i.e., every secure digital signature scheme such as ECDSA may be used.

MQV also assumes the possession of trusted copies of the other parties static public key ($A$ of Alice and $B$ of Bob in the referenced link). The respective secrets $a$ and $b$ are used in steps $3$ and $4$ (in the link) and the respective quantities $S_a$ and $S_b$ seem to be denoted as implicit signature sometimes, since they are no explicit digital signature schemes involved, but messages $3$ and $4$ achieve the same goal. Namely, the messages $3$ and $4$ prove to party Bob and Alice respectively, that the respective secret ($a$ and $b$) corresponding to the authentic public key is known to the sender of message $3$ and $4$ respectively.


Does Proxy re-encryption can re-encrypt large data?

Normally the data is not encrypted under PRE directly. The sender can encrypt the data using a random symmetric key using a secure symmetric cipher (e.g. AES), then encrypts the symmetric key under the sender's PRE key. The proxy can re-encrypt this ciphertext into a new ciphertext such that the receiver can decrypt it.


It is unclear what you are aiming for?
If you are trying to get a hash function collision resistent even in the face of a malicious adversary? murmur is no good regardless of concatenations.
You need to use a cryptographiclly secure hash such as something from the SHA-2 or SHA-3 families.

If you are talking about a non adverserial setup, murmur may suffice. But since modern cryptographic hashes have so fast implementations I usually recommend them anyway and have better piece of mind.

Regardless, both murur and the SHA families are defined on arbitraty length input so you can apply directly on concatenated input.

If you already have hashes, their concatenation(at double the output size) is at least as collision resistant as the underlying hash. The second construction at half the size also seems secure when a secure hash is used.


Is it possible to work out the hash algorithm from a list of known message-hash pairs?

In practice, maybe, if you got additional information, such as that the hash function is known to conform to some published standard (you just don't know which).

Theoretically, though, for any finite list of values, there is always more than one bounded algorithm that generates the list. You can never be absolutely sure you figured out the correct algorithm.


Applying differential cryptanalysis to ciphers with addition mod $2^{32}$

This is called an Even-Mansour cipher.

Actually, for the differential cryptanalysis it does not matter what sort of difference you use, you only need that it propagates deterministically through linear transformations  (whatever linearity means). In this case you use a difference modulo $2^{32}$:
$$
A \boxminus B \equiv (A-B)\pmod{2^{32}}.
$$

You compute the differential distribution table for $S$ in the same way, but replace $\oplus$ with $\boxminus$.


Technically, yes, it can be secure.

However you are worried about a server compromise. And the consequence of such a compromise would be that the user's private keys can get subject to attack by brute-force and / or dictionary attacks which usually doesn't end well because users tends to pick bad passwords. While you can make this harder using Argon2d (don't use PBKDF2) it's still not impossible for an attacker to even recover a moderately difficult password.

You see the problem now. Because of this I'd suggest leaving the user the choice to sync their encrypted private key to your cloud, to their own cloud service provider, to one of their other devices or don't sync it at all and give them a short explanation.

  This will synchronize your private decryption key to our cloud. If you
  lose this key you will no longer be able to access your encrypted
  messages. By synchronizing we can also ensure you can use this key
  from your phone and your laptop. However note that if we get
  compromised there's a risk that an attacker can recover your password
  and the key if you're not 100% confident in it. If you don't
  synchronize there's no risk of a server compromise leaking information
  about your messages or key.


Using ECDSA to sign a ECDiffieHellman-derived key

Sure, first you set up a 1:1 communication and then you establish trust in it. This is kinda like TLS 1.3 where encryption starts as soon as possible. Of course, anything up to the authentication of the entity and handshake can be generated by an adversary, so it is slightly dangerous in that sense.

And in general, you would try and authenticate as many handshake parameters as possible, rather than just the ongoing channel. Basically you try and tend to achieve confidentiality and authentication over as much data as possible. You could do that by hashing all the communication messages and then signing that separate hash, for instance.

As for the trust in the public keys: yeah, sure. This is almost identical to certificate pinning after all, where a certificate is trusted explicitly rather than just a public key. The advantage of using a certificate is of course that you can use a certificate chain later and that a certificate contains more information than just a public key (validity period, identification information, CRL and whatnot). So generally if you want to use a public key, why not create a self signed certificate for it and pin that instead.

The described scheme can certainly be part of a secure protocol. If the protocol is actually secure depends on a lot of other factors. And such details matter even for the specific scheme mentioned (parameter validation, side channel resistance, avoidance of replay attacks and mirror or reflection attacks), and so on. Creating a secure transport protocol is one of the most daunting tasks, especially for a beginner.


An advantage of a cryptographic accumulator and actually the reason to use them is that due to the quasi commutativity you can compute witnesses for
membership of values in the accumulator where the accumulator and the witnesses are of constant size.

Say you
have a set $Y=\{y_1,y_2,y_3\}$ and compute the accumulator as $acc=f(f(f(x,y_1),y_2),y_3)$ you want to compute a witness for a value say $y_2$, then by quasi commutativity, the value for your witness is $wit_{y_2} = f(f(x,y_1),y_3)$ and you can check given $y_2$ and $wit_{y_2}$ whether $y_2$ is in the accumulator $acc$, you can check whether $acc=f(wit_{y_2},y_3)$ holds.

Furthermore, existing accumulator schemes (CL02, C+09, N05) come with zero-knowledge proofs of accumulator membership (you do not have to reveal the value $y_2$ and the witness $wit_{y_2}$ directly, but you provide a zero-knowledge proof of knowledge of such a pair - which makes them attractive for privacy-preserving applications). Such accumulators are typically also dynamic, i.e., allow update of witnesses in the public if the accumulator is updated. Furthermore, there are also so called universal accumulators, which also allow to produce witnesses for non-membership of a value in the accumulated set (see A+09 or L+07).

All known efficient accumulators are based on number theoretic assumption, but I would not say that they are
inefficient. Note that in your last RSA example, the membership check requires one exponentiation, which is not really very expensive.

  is the function f weak in terms of eg. collision-resistance, is it not efficient enough...?

For a secure accumulator one requires collssion-freeness, i.e., it is computationally infeasible to find a witness for some value that is not accumulated in the accumulator. For RSA accumulators that requires that you only accumulate primes (so you have to map your values to accumulate to primes with some deterministic algorithm). Otherwise, you could factor your value into two factors and exponentiate one onto your witness and provide the second as value to be checked and the check would work. This is ruled out if you take primes. There are however, other secure pairing based accumulators that do not suffer from this problem.

Accumulators are used for various purposes, such as timestamping (the original application), membership testing, distributed signatures, redactable and sanitizable signatures as well as for revocation in group signatures and anonymous credential systems.

There are constructions for accumulators based on bloom filters (see Nyberg, Fast accumulated hasing, FSE 1996), but
they are rather impractical (but do not rely on number theoretic assumptions).


Zero knowledge proof relation + number is binary

To prove "the same" relation, just use the same response of $\Sigma$-protocol for each $s_i$ in relations for $Y$, $Z$ and $s_i \in \{0,1\}$. This technique was suggested by Chaum, Evertse, de Graaf in Eurocrypt'87 paper.

To prove OR relation, one would split the challenge, prove the valid part and simulate the false one. See Cramer, Damgaard, Schoenmakers Crypto'94 paper. For preprint link and extended "CDS" description see Alan Sz' answer at Zero-knowledge proof of a product.

It may be practical to get some chapters (in pdf) of "Rethinking PKI" book  from credentica.com for both proofs. Warning: it takes time to read and understand that.

Yet another technique would be extending $\Sigma$-protocol into polinomials of degree higher than linear in challenge, see a paper in MFCS 2012. It fits well polinomial graph representation, but might be an overkill for this task.


Can you point me to an MDS table reference for the Kalyna cipher?

The Kalyna paper does contain the elements on page 6, but it is not formatted in the familiar table manner, rather it describes it via mathematical formula and rotations, as the matrix is circulant:

$w_{i,j} = (υ \ggg i) ⊗ G_j $

$ υ = (0x01,0x01,0x05,0x01,0x08,0x06,0x07,0x04)$

Where $G$ is the input matrix and $W = (w_{i,j})$ is the output matrix

Additionally, the finite field is reduced modulo $x^8 + x^4 + x^3 + x^2 + 1$ or $0x11D$, which is the same field as the whirlpool hash function.

The familiar matrix format for $v$ would be as follows:

$$
 \begin{bmatrix}
1& 1& 5& 1& 8& 6& 7& 4 \\
4& 1& 1& 5& 1& 8& 6& 7 \\
7& 4& 1& 1& 5& 1& 8& 6 \\
6& 7& 4& 1& 1& 5& 1& 8 \\
8& 6& 7& 4& 1& 1& 5& 1 \\
1& 8& 6& 7& 4& 1& 1& 5 \\
5& 1& 8& 6& 7& 4& 1& 1 \\
1& 5& 1& 8& 6& 7& 4& 1 \\
 \end{bmatrix}$$

I believe the inverse matrix is as follows:

$$
 \begin{bmatrix}
AD& 95& 76& A8& 2F& 49& D7& CA \\
CA& AD& 95& 76& A8& 2F& 49& D7 \\
D7& CA& AD& 95& 76& A8& 2F& 49 \\
49& D7& CA& AD& 95& 76& A8& 2F \\
2F& 49& D7& CA& AD& 95& 76& A8 \\
A8& 2F& 49& D7& CA& AD& 95& 76 \\
76& A8& 2F& 49& D7& CA& AD& 95 \\
95& 76& A8& 2F& 49& D7& CA& AD \\
 \end{bmatrix}$$


Is a PRG more costly than AES or any other encryption standard?

A one-time pad requires a true random sequence that is as long as the material you want to encrypt. If you have a pseudo-random sequence, then you don't have a one-time pad: you have a stream cipher. If you have a stream of data that is only “nearly random”, then you don't have a one-time pad, you have a broken stream cipher.

Concretely, if the nearly-random sequence isn't uniform, it means that there are biases: certain arrangements of bits are more likely than certain others. Whenever these arrangements are aligned with a pattern in the plaintext — for example English text contains more E than J, text in most languages contains more spaces than any other character, HTML tends to have a > shortly after each <, … — the pattern in the plaintext becomes apparent in the ciphertext. So certain patterns appear in the ciphertext more often than chance, they will reveal patterns in the plaintext.

To generate a cryptographically secure random sequence from a source of randomness that isn't perfectly uniform, you need to pass this random source through a cryptographically secure pseudorandom generator. One of the cheapest techniques to build a pseudorandom generator is to use an encryption algorithm such as AES in a construction known as CTR_DRBG. If all you want to do is to encrypt one message, then it's simpler and cheaper to encrypt the message with AES-CTR than do use AES-CTR_DRBG to build a key stream and to use that key stream to encrypt a message.

In addition, a one-time pad doesn't help with the authenticity of the message. If the message is modified in transit, there's no way to detect it. Encryption algorithms can be combined with authentication algorithm, and the cost of doing the two together is less than the cost of doing the two completely independently. The computational cost is only slightly less, but the cost in code size or in gate count is significantly less. For example, once you have the AES block cipher, it only takes a little additional work to build an authenticated encryption mode such as GCM or CCM.


Well, no, there's no defined TLS ciphersuite that does the RC4 algorithm with a discard of the original stream.

I'm not a designer of TLS, nor am I a member of the IETF working group that controls it; I suspect that they'd prefer for people to transition to ciphersuites that use AES (or some other newer cipher), and so there's little incentive for them to add variant RC4 ciphersuites.

As for the problems that the know biases that the start of the RC4 stream can cause, well, those biases actually come in two flavors:

There are known biases in the keystream bytes themselves; for example, the second byte of the keystream is 0 with probability 1/128 (rather than the expected 1/256).  What this means is if you have a few thousand TLS sessions keyed with RC4, and you know that their plaintexts have the first few bytes in common, you might be able to deduce the values of the second plaintext byte; with more keystreams, you might be able to deduce the values of the first and third plaintext bytes.  Obviously, this is a security failure, and this may be of real concern if (for example) you're sending a password through the TLS session as the very first thing.
There are known correlations between the keystream bytes and the RC4 key itself.  These correlations aren't strong, and so you'd need thousands of keystreams from related keys to get much information about the key.  This is exactly the problem that WEP ran into; however, with TLS, they derive the RC4 key from a real key derivation function; that means that there are no known corrections between the keys from different connections, and so this observation is of no use.

The bottom line: if the first few bytes of the TLS stream are high-value, you probably shouldn't be using an RC4 ciphersuite.


The access codes were recently leaked (by whom, I don't know).  My Yubikey is listed and I can confirm that the access codes were necessary and sufficient to reprogram it.  You can change or remove the access code as part of reprogramming too.  The leak doesn't make the Yubikeys useless in the extremely unlikely event of Gox rising from the flames — no AES keys were leaked, only the reprogramming ("access") codes — but the AES keys are write-only, so consider whether you care about that unlikely event before doing anything you can't undo.

So go grab the tools, reprogram, and rescue your Yubikey from the TiVo Graveyard.  I think I'll be using mine in static mode only, with one slot unlocking my password manager and the other unlocking an encrypted partition on a headless machine at boot.  If you do something similar, don't forget that (unless similarly headless) you can type a prefix (something-you-know) before hitting the button on the key (something-you-have).


What are the first 4 and last 2 bytes in DH parameter files?

PEM consists of a header and footer that identify the object that has been encoded. It may sometimes also contain some arguments behind the header line. The actual data is base 64 encoded. You can view the contents by decoding it using a base 64 encoding.

Now the DH parameters are encoded using ASN.1 BER, which is a binary encoding. This encoding is used for most if not all PEM encoded structures. ASN.1 is a data description language. ASN.1 structures can be seen as a tree with constructed nodes (sequences) and primitive nodes (strings, byte arrays, integers and such) all using network ordering. These nodes are generally encoded using tag-length-value (TLV) encoding. As the tag for a SEQUENCE is the value 30 (in hex), the first base 64 letter is almost certainly an M.

The version of base 64 used by PEM pads anything that isn't a multiple of 4 characters (three bytes) to 4 characters using the = character.

So the first characters and the amount of = characters at the end is mainly dependent on the size of the parameters rather than their value.

This is the contents of the ASN.1 tree in the contents of your PEM text:

SEQUENCE(2 elem)
  INTEGER(256 bit) 1097277930034063274792561151504789680016548759529511363308187422232757…
  INTEGER2

and

SEQUENCE(2 elem)
  INTEGER(1025 bit) 331904441233693192104476260016584324479133460055459757886261577377912…
  INTEGER2

generated using the ASN.1 decoder here.


Constructing a custom protocol using well-vetted algorithms?

You might want to start by reading Lessons learned and misconceptions regarding encryption and cryptology.  I spotted 3 potential issues in your proposal that are explained there.

Instead of designing your own cryptosystem, you should try hard to use an existing well-vetted scheme, like TLS or DTLS for interactive communication, or GnuPG for storage or store-and-forward messaging.  The fact that communications are routed through a proxy server doesn't change this recommendation; you can still do end-to-end cryptography.

(If you are building your own protocol, you to use authenticated encryption, and deriving cryptographic keys from a passphrase tends to provide poor security.)

Since you haven't given us any specifics why you can't use existing schemes, it's going to be tough to provide you with more detailed advice.


Probably the biggest vulnerability is that the message expansion is too linear. The linearity of the SHA-1 message expansion is why we are able to find such good differential paths. There can be differences at the beginning of the message and by the end of the message expansion they are mostly canceled out.


Any algorithm with a master key for decrypting private key encrypted messages?

You're looking for "key escrow", which is often a very bad idea. Even if this fits your use case, you're creating a single point of failure.

I'm sure that there are more sophisticated approaches, but here is a very simple one:

You need a pseudorandom function (PRF) and a public key encryption scheme.

Draw a random key $k$ for the PRF and use it as master key.
Then whenever generating a public/private key pair, take a unique bitstring $id$, compute $PRF(k,id)$ and use the result as randomness for the key generation algorithm of the public key encryption scheme, which gives you a private key $sk$ and a public key $pk$. Store a table that maps $pk$ to $id$.

This fulfills everything that you want: As long as the key $k$ is not revealed, the public key encryption scheme works as intended and is secure. But if I know $k$, I can look $id$ up in the table, recompute $PRF(k,id)$, derive $sk$ and decrypt.

Here, $id$ is a nonce in the weak sense: it can either be fully random or implemented by a counter; you "just" need to make sure that it is never repeated. (If it is a counter, you can also not store the table in the first place, and just try enough counter values until you have the right one, if you need to decrypt rarely with the master key.)


This is adressed for example in Lattice-based Blind Signatures by Markus Rückert, 2008. I only had a quick glance, and it seems there is a construction for building blind signatures based on lattice problems.

But this isn't surprising, because lattice problems can be used for:

building post-quantum encryption schemes, key exchange, signatures, etc.
building fully-homomorphic encryption schemes. Such a system preserves a lot of algebraic structure (in contrast to OWFs), and it should be quite easy to use this to create blind signatures (which are often based on some semi-homomorphic property)


Generate random numbers whose sum is equal to a constant value modulo n

For $i=1, \dots, n-1$, generate $n-1$ random numbers $u_i \in [0,2^{κ+1})$ and define $u_n = \left(c - \sum_{i=1}^{n-1} u_i\right) \bmod 2^{κ+1}$.


Ring Signature - paper/code difference in trying to solve inverse trapdoor function?

I'm taking some stuff from my relevant question at Rivest's ring signatures with hashes instead of symmetric encryption

Remarkably, Wikipedia's Python code does not use a symmetric encryption function ($E_k$, as in "How to leak a secret"), but a hash function ($\mathcal{H}$). Indeed, the encryption function does not need to be invertible, if we close the ring of the signature at the very last (take $v^\prime$ random, $m$ is the hashed plaintext):

$$
\mathcal{H'}(x) = \mathcal{H}(x||m)\\
v=\mathcal{H'}(y_{r} \oplus \mathcal{H'}(y_{r-1} \oplus \mathcal{H'}(\ldots\oplus \mathcal{H'}(v'))))\quad r-s\enspace\text{times}\\
h=\mathcal{H'}(y_{s} \oplus \mathcal{H'}(y_{s-1} \oplus \mathcal{H'}(\ldots\oplus \mathcal{H'}(y_1 \oplus v))))
$$

now notice that
$$
v'=y_s \oplus h \Leftrightarrow y_s=v'\oplus h\\
x_s=g_s^{-1}(y_s)
$$

which "closes" the ring.

  My question is, why is the paper's implementation seem different than the one in the code?

To answer this question, I think we can only guess (or ask the authors). My guess would be that the authors didn't think of this trick, or that they didn't find it interesting enough to mention the possibility.

In my opinion, solving $C_{k,v}(y_1,y_2,\dots,y_3)=v$ by inverting $E_k$ (i.e., $E_k^{-1}=D_k$) seems more natural that "closing" the ring at the very last.

In terms of security, I think it has no influence on the proof in HTLAS, since they already modelled $E_k$ as a random oracle (and $\mathcal{H}'$ would be one too). I posted a new question about the security of this substitution.

  That is, why $x_s = g^{-1}(y_s)$  or  $x_s = g^{-1}(y_s \oplus x_s)$ ?

Don't get fooled here; what they denote in the code as u is what HTLAS calls $v$, so the sole thing they actually do in that step is $x_s=g_s^{-1}(y_s) = g_s^{-1}(v'\oplus h)$ (in my notation above).

The code on that page is very illegible to say the least, and may get removed soon. For future reference, here is the version in Wikipedia's history.


Attribute-based broadcast encryption with respect to ABE

At first, the abbreviation “ABBE” is used by Zhou et al. in [2] as a name for his ABE scheme. Zhou builds on top of a CP-ABE scheme which in addition supports “constant” ciphertexts (named CCP-ABE). From this perspective ABBE is a specific ABE scheme based on CP-ABE supporting constant ciphertexts.

However, in a more general way, I see ABE in the context of Broadcast communication as:

A merge ofthe notion of ABE and Broadcast Encryption. Broadcast related use-cases have special requirements which you have to take into consideration not only when applying ABE.

There are broadcast-enabled ABE schemes which build on top of KP-ABE[1,3] or CP-ABE[1,2,2a]. More or less broadcast-enabled ABE schemes face the same challanges and thus focus on similar properties/aspects.

Some often recurring aspects in ABE-based broadcast scenarios are:

Size of the ciphertext: a constant message size is often advantage. In addition the message size itself is of interest.
Access Structure: The ciphertext size depends on the embedded access structure. The access structure is important not only when thinking about how to enforce revocation.
General communication and storage overheads are more of importance in Broadcast scenarios - compare [2a].

[1] Attrapadung et al., 2009: Conjunctive Broadcast and Attribute-Based Encryption.

[2] Zhou et al., 2010:  On Efficient Ciphertext-Policy Attribute Based Encryption and Broadcast Encryption, Source: http://eprint.iacr.org/2010/395

[2a] Zhou et al.2015: Efficient Privacy-Preserving Ciphertext-Policy Attribute Based Encryption and Broadcast Encryption

[3] Sun et al., 2013: A Key-Policy Attribute-based Broadcast Encryption.


Block cipher encryption of decryption with the same key

If by $\operatorname{Enc}$ and $\operatorname{Dec}$ you mean the application of the block cipher primitive to a single block, then yes, it is assumed to be deterministic. (Since the size of input and output block is the same, and we want to be able to decrypt again, there is no way to be nondeterministic.)

(Note that in "normal" encryption/decryption usage, you'll have not the block cipher primitive, but a block cipher with a mode of operation, and together the encryption is usually are not determined by just the key, as it is also using an initialization vector.)

When you are thinking about block ciphers in compression functions for hashes, you are usually taking the block cipher primitive, so your determinism is given.

For collision resistance of a hash function, you don't need to show that there are no collisions (this is impossible, if the input size is larger than the output size), just that it is "hard" to calculate them. (Or if you want to show that a function is not resistant, show that you somehow can calculate a collision.)

Your idea of creating a collision is good – you just have to show on how it applies to the way a message is encoded and then passed to the compression function (i.e. the block cipher) to find two colliding messages. (This depends on your concrete candidate hash function.)

This is also the reason that we don't use a "pure" block cipher in real live compression functions, but add some feedback of either the "key" or the "plaintext" or both into the output.


Supersingular Isogeny Key Exchange broken?

Sorry I will have to answer my own question.

I received a mail from Luca De Feo a moment ago.
"Nope, I discussed this at length with Jean-François Biasse, and we couldn't find a way to apply this kind of attack to SSIKE."

I'll leave this question around for reference for the next person who wonders.


How to decode a (Vigenère?) substitution cipher?

This is, in fact, not a Vigenère cipher.

One clue to this is the fact that the ciphertext (which, conveniently, includes unenciphered word breaks) contains lots of repeated words like UTL, VCI, V, UB and QVRY that would be very unlikely to occur by chance in the output of a polyalphabetic cipher like Vigenère.

Another clue can be obtained by examining the letter frequency distribution of the ciphertext: while the letters of the alphabet have obviously been scrambled, sorting the letters by their frequency reveals a very similar distribution as unencrypted English text:

L: 305 #############################################################
V: 248 ##################################################
U: 246 #################################################
B: 175 ###################################
Z: 160 ################################
T: 158 ################################
C: 154 ###############################
A: 142 ############################
O: 140 ############################
H: 131 ##########################
I: 121 ########################
S:  77 ###############
R:  72 ##############
F:  63 #############
P:  63 #############
D:  49 ##########
Y:  42 ########
G:  41 ########
W:  41 ########
K:  39 ########
E:  37 #######
J:  22 ####
Q:  14 ###
X:   4 #
M:   3 #
N:   2

Both of these clues suggest that we're probably dealing with a basic monoalphabetic substitution cipher.

So, how do we break a cipher like this?

One way to get started is to guess that the three most common letters in the ciphertext (L, V and U) most likely correspond to the three most common English letters (E, T and A) in some order.

One of those letters, V, occurs several times in the ciphertext as a single-letter word (in fact, it's the only letter that occurs so).  The most common single-letter word in English is the indefinite article "a", so we might guess that the ciphertext letter V probably corresponds to the plaintext letter A.

Meanwhile, the other two most common letters, L and U, occur together in the most common word in the ciphertext, UTL.  As the most common word in English is the definite article "the", and as we've already guessed that L and U probably correspond to E and T (since V is A), it seems very likely that UTL in fact means "the".

This already gives us the following partial cipher alphabet:

plaintext:   abcdefghijklmnopqrstuvwxyz
ciphertext:  V   L  T           U

We might even go out on a limb, and guess that the very common three-letter ciphertext word VCI, which starts with the known plaintext letter A, might correspond to the common three-letter conjunction "and".  But at this point, it's probably a good idea to just try to decode some of the ciphertext using the partial alphabet we've guessed, just to see if it looks reasonable.  Doing this, we get something like:

  the ZettOnP ZSn RaZt HBnP ZhadBFZ aRABZZ the deRY. theAe FeAe nB FBAdZ, QSZt ZBSndZ. that needHe aHZB Dade a ZHBF ROARSOt aABSnd and aABSnd and aABSnd, ...

(Here, the uppercase letters are still undecrypted, while the lowercase ones have been decrypted according to our partial cipher alphabet.)

At this point, we can just start guessing at the partially decrypted words.  For example, "theAe" is probably "there", so A would be R, and "needHe" might be "needle", making H correspond to L, and so on.

Continuing in this manner (and occasionally checking to see if the resulting partial decryption still makes sense), it should be possible to work out the complete cipher alphabet.  I'll leave completing this task as an exercise, since that's what this is presumably meant to be.  I did verify, though, that it is indeed possible to decrypt the entire message in this manner, and that the guesses I've made above for the decryptions of various ciphertext letters are, in fact, correct.  (Note that this will not always be the case in general; sometimes, you do need to backtrack and try different guesses if it turns out that the decrypted message makes no sense after all.)


Is there any way to mapping point between 2 elliptic curves?

I wrote this since it is too long to comment;
First the SageMath code
K =  GF(43)
E = EllipticCurve(K,[0,7])
print(E)
print(E.order())
print(E.abelian_group())

G = E(21,25)

With $K$ one can use different fields, the $[a=0,b=7]$ is for $y^2 = x^3 + ax + b$.
This codes give us a lot of information about the curve

print(E) : The curve information:
Elliptic Curve defined by y^2 = x^3 + 7 over Finite Field of size 43

E.order() : Print the number of the rational points on the curve:
31

E.abelian_group(): The group structure of the curve:
Additive abelian group isomorphic to Z/31 embedded in Abelian group of points on Elliptic Curve defined by y^2 = x^3 + 7 over Finite Field of size 43

The last one is important since to exactly map a point $g$ and its multiples, they must have the same order in each group.
Actually, to map a curve to another, or a subgroup, one doesn't need the same $G$ to happen in both. The order is enough. We have to look for orders of the elements.
Let's look at your curves;

EllipticCurve(GF(17),[0,7])

Elliptic Curve defined by y^2 = x^3 + 7 over Finite Field of size 17
18
Additive abelian group isomorphic to Z/18 embedded in Abelian group of points on Elliptic Curve defined by y^2 = x^3 + 7 over Finite Field of size 17

E = EllipticCurve(GF(31),[0,7])

Elliptic Curve defined by y^2 = x^3 + 7 over Finite Field of size 31
21
Additive abelian group isomorphic to Z/21 embedded in Abelian group of points on Elliptic Curve defined by y^2 = x^3 + 7 over Finite Field of size 31

E = EllipticCurve(GF(43),[0,7])

Elliptic Curve defined by y^2 = x^3 + 7 over Finite Field of size 43
31
Additive abelian group isomorphic to Z/31 embedded in Abelian group of points on Elliptic Curve defined by y^2 = x^3 + 7 over Finite Field of size 43

E = EllipticCurve(GF(67),[0,7])

Elliptic Curve defined by y^2 = x^3 + 7 over Finite Field of size 67
79
Additive abelian group isomorphic to Z/79 embedded in Abelian group of points on Elliptic Curve defined by y^2 = x^3 + 7 over Finite Field of size 67

They are all isomorphic to $Z/18,Z/21,Z/31,$and $Z/79$, respectively.
The orders;
for i in (1..E.order()):
    print(E[i], E[i].order())

In the first curve, the orders of the elements are $1,3,2,6,9,18$
In the second curve, the orders of the elements are $1,3,7,21$

So, we have common order of $3$, then we can map these elements (5,8) and $(0,10)$ to each other.

A sample curve that is not isomorphic Z/n
E = EllipticCurve(GF(25, 'x'), [1, 1])

Elliptic Curve defined by y^2 = x^3 + x + 1 over Finite Field in z2 of size 5^2
27
Additive abelian group isomorphic to Z/9 + Z/3 embedded in Abelian group of points on Elliptic Curve defined by y^2 = x^3 + x + 1 over Finite Field in z2 of size 5^2

Birational Equivalent is another story!


How to calculate end point from private key in elliptic curve cryptography

Suppose that I can add two points together. Now, I have a point $G$, and I want to compute 197 times that point $G$. I could do that with 196 additions. But I can also do so much faster:

\begin{eqnarray*}
G + G &=& 2G \\
2G + G &=& 3G \\
3G + 3G &=& 6G \\
6G + 6G &=& 12G \\
12G + 12G &=& 24G \\
24G + 24G &=& 48G \\
48G + G &=& 49G \\
49G + 49G &=& 98G \\
98G + 98G &=& 196G \\
196G + G &=& 197G \\
\end{eqnarray*}
As you see, I computed 197 times the point $G$ in only 10 point additions, which is far cheaper than 196 additions.

This is known as the double-and-add algorithm. The gist is that when you have $nG$ for some integer $n$, then a single addition of $nG$ with itself yields $nG + nG = (2n)G$; and you can also get $(2n+1)G$ with an extra addition with $G$. You can think of the algorithm as maintaining a current point $P = nG$, and step by step altering $n$ so as to reach a given target value; it helps to think of $n$ as an integer in base 2:

Adding $nG$ to itself means multiplying $n$ by $2$, i.e. shifting it one bit to the left, filling the blank with a zero.
Adding $G$ to $(2n)G$ replaces that newly inserted zero with a one.

Thus, the square-and-multiply algorithm simply rebuilds the multiplier bit by bit. This yields a cost of $\log m$ doublings and at most $\log m$ extra additions, to compute $mG$.

There are many possible optimizations (window, NAF, wNAF...) that can be done to save on the extra additions. The baseline cost is that, to multiply by an integer that fits on $k$ bits, you'll need $k-1$ doublings, and some extra additions; the costs of doublings is the dominant one, because the window/NAF optimizations only reduce the number of extra additions.

The same algorithm is known as square-and-multiply in the context of modular exponentiations; it has its own Wikipedia page. This is the same thing, except that point additions become multiplications of integers, and multiplication by an integer becomes exponentiation.


What is the purely mathematical definition of encryption strength?

There isn't just one, because there are many different scenarios where you'd use such a function, where the attacker has lesser or greater powers, or variably stringent success goals—different attack models.  For example:

Does the attacker know any plaintext/ciphertext pairs encrypted with the same key?  (Known plaintext attack)
Is the attacker able to trick the defender into encrypting plaintexts of the attacker's choice, and observe the corresponding ciphertexts?  (Chosen plaintext attack)
In the latter case, is the attacker able to observe the ciphertexts in real time, and use this to make smarter choices of plaintext to submit?  (Adaptive chosen plaintext attack)
Is the attacker's goal to decrypt a message, or something weaker like telling true encrypted messages apart from random bits?  (The latter is what's called a "distinguishing attack," and strengths are often expressed in terms of that.)

So it's common for algorithms to have different security levels in different scenarios. If you look for example at the "Known attacks" section in Wikipedia's entry on AES, you'll see a variety of figures, all qualified by the relevant attack model.

Another detail is that strengths are often expressed not as one number but as a function of the resources that the attacker expends in some model (e.g., in a chosen plaintext attack, the number queries, i.e. the number of plaintexts that they submit to the defender).  Such functions generally give the probability that a randomized attacker will succeed if they expend that many resources.

And yet another detail is that often for some algorithms like block cipher modes of operation, which are parametrized by one or more primitives, the strength is often given as a function of the strengths of the primitives.  If you're math-inclined or even just math-curious, two papers I found very useful to understand this are:

Bellare, Kilian and Rogaway's "The Security of the Cipher Block Chaining
Message Authentication Code"
Bellare, Desai, Jokipii and Rogaway's "A Concrete Security Treatment of Symmetric Encryption"

These two papers are perhaps overwhelmingly detailed, but even just skimming the major points might be instructive.


Linear combination IOP for SNARK registers

The prover does not send another oracle as you suggest in #3. Rather, both parties invoke the FRI protocol for the function that is the random linear combination (random coefficients selected in #2). Now, every query to the function you refer to in #3 is answered by querying all oracles #1 and computing the linear combination #2 (which is something the verifier does). Thus, the soundness error for this function is 0 and there's perfect consistency, by construction.


What is the intuition of canonical-embedding in homomorphic encryption based on RingLWE?

Consider the $m^{\text{th}}$ cyclotomic ring $R = \mathbb{Z}[\zeta] \cong \mathbb{Z}[X]/\Phi_m(X)$, where $\zeta$ is the $m$th primitive root of unity and $\Phi(X)$ is the $m$th cyclotomic polynomial. There are many possible bases for this ring, including the power basis $\{ \zeta^0, \zeta^1, \ldots, \zeta^{n-1}\}$, where $n = \phi(m)$ (Euler totient function).

In lattice crypto, it is useful to have a notion of a short ring element. The metric used is often a function of the coefficients of the polynomial in $R$. However, different bases of this ring can result in different coefficients, including cases where 'short' elements have long coefficient vectors.

It is necessary, then, to define geometric quantities independently of the basis representation of $R$. This the use of the canonical embedding $\sigma$, which creates a map $\sigma\colon R \mapsto \mathbb{C}^n$ that is independent of the representation of $R$.
$$ a \in R,  \ \ \sigma(a) = \left<a(\zeta_m^i)\right> \ \ \text{for all } i \in (\mathbb{Z}/m\mathbb{Z})^*
$$We can now define all geometric quantities with respect to the canonical embedding. This results in a 'canonical embedding norm' which is really just any norm taken with respect to the canonical embedding. E.g. For $a \in R$, $||a||_2^{can} = ||\sigma(a)||_2$ or $||a||_\infty^{can} = ||\sigma(a)||_\infty$

There are many other useful properties of the canonical embedding, such as coordinate-wise addition and multiplication.


Is this approach able to protect against padding oracle attacks?

You have to differentiate between it being theoretically OK and practically. Without fully checking, I can say that such an approach may be possible to fully prove. However, practically, it is almost impossible to implement it. Specifically, you have to be able to make it impossible to differentiate between an error due to the symmetric decryption or the signature. However, this is really hard to do (actually, pretty much impossible). The reason is that you need to make it time-independent. But, if you have a padding error, you don't even know how long the message is to verify. The Lucky13 attack on TLS worked exactly because code that was written to be time-independent turned out to not truly be so in certain cases. So, I would never do such a thing.

A huge number of SSL/TLS weaknesses are due to doing MAC-then-encrypt, so don't do this. GCM is so fast today on Intel processors that there's no reason not to use (just make sure you always have a different nonce).


In which situation is HMAC mandatory rather than signature?

In principle, a signature can always be used in lieu of a MAC. You use a MAC when you want the legitimate recipient of a message to be able to verify its authenticity. With a signature, everyone, including of course the legitimate recipient, can verify the authenticity of a message.

The reason we use MACs at all, instead of just using signatures all the time, is of course that MAC constructions are more efficient. Thus an answer to the question could be: when a signature is not efficient enough for your purposes.


Why is Diffie-Hellman used instead of just RSA in key-exchange (TLS, IKE)?

What does DH add?

Perfect Forward Secrecy.

That is, suppose you have a secure session with the server Bob, and then you close the session down.  Then, someone steals the server (or serves a warrant to the owner).  If you use RSA to transport the random session key, well, the server still has the RSA private key, and so they'll be able to decrypt your session.

In contrast, assuming that the server and the client zeroizes the DH private values at the end of negotiation, they can't - no one is able to rederive the session keys, even if they grabbed both the client and the server.

Now, it's possible to do this with RSA (by zeroizing the old RSA private key, and generating a fresh one periodically); however generating RSA key pairs is expensive, and so no one does that - they use DH instead.


Do I have to recompute all hashes if I change the work factor in bcrypt?

To increase the work factor, there are three approaches you could take:

Rehash all passwords immediately, continue the same hash

Take the hash currently stored in the password file, and hash it a few more times.
We may (see below) be able to do this immediately with every entry in the password file.

Example: let's switch from a work factor of 10 (i.e., hashed 2^10 times) to the same hash function with a work factor of 11 (hashed 2^11 times).
To do that, we pull the old hash value from the password file -- that has already been hashed 2^10 times -- and use the same salt to hash it another 2^10 times to create the new hash value, and replace the old hash with the new hash.

Then we somehow tell the "login" program and the "passwd" program (or the equivalent), instead of using a work factor of 10, they now need to use a work factor of 11.

See "Is it possible to increase the cost of BCrypt or PBKDF2 when its already calculated and without the original password?"
for more discussion of this approach.

Alas, in some cases you can't simply "continue" to hash like this -- say, you want to switch to a completely different hash algorithm, or you want to change the salt,
or your current hash function has a "setup" or "finalize" step that interferes with "continuing" to hash like this.

Rehash all passwords immediately, without continuing the old hash

Take the hash currently stored in the password file, and hash it a few more times.
We can do this immediately with every entry in the password file.

Example: let's switch from MD5 (hashed once) with a 3-character salt, to bcrypt with a work factor of 11 (i.e., hashed 2^11 times) and a fresh 32-character salt.
To do that, we pull the old hash value from the password file, and replace it with a new hash value:

new_hash = bcrypt( old_hash, new_salt, work-factor=11 ).

Then we somehow tell the "login" program and the "passwd" program (or the equivalent) to use this somewhat awkward hash function:

bcrypt( MD5( password, old_salt ), new_secure_salt, work-factor=11 )

See
" Is this password migration strategy secure? "
for more discussion of this approach.

Rehash passwords one at a time, as people log in

Many UNIX-like systems are already set up so the sysadmin can change the "preferred" password algorithm, work factor, and salt length at any time.
Later, whenever a user logs in by typing their password, the system updates that user's row in the passwd file to use the system's current "preferred" work factor etc.
See a, b, c, d, e, f, g, h, i, j, k, L, m, n, o for how to tweaking the appropriate configuration file in order to set the "preferred" algorithm etc.
Typically this involves pluggable authentication modules (PAM).

Many passwd files (or thier equivalent) store, for each user,
not only the the salted hash,
but also the user-unique salt, the ID of the hashing algorithm used, and the work factor
(often dollar-sign delimited).
That allows us to gradually switch to a completely different password hash algorithm and salt width.

details:

For example, let's say we want to switch from inadequate amounts of salt and some obsolete hash to bcrypt with a work factor of 11.
The sysadmin sets the "preferred" algorithm, salt, etc. to "bcrypt with a work factor of 11", etc.

The next time a user logs in, resets their password, or changes to a new password -- i.e., uses the login or passwd programs -- those programs:

1) Hold on to the plaintext password the user typed in for a few moments.

2) Check the passwd file to see if that user's hash already uses the latest algorithm, work factor, and salt width. If so, continue with 4.

3) Authenticate the user with whatever old, obsolete algorithm the passwd file indicates for that user. If successful, additionally create a unique new salt with the latest salt width.
Run that salt, and the plaintext password that we're still holding on to, through "bcrypt with a work factor of 11" (or whatever today's preferred algorithm is) to get the new hash.
Update the passwd file for that user with the new hashing algorithm ID, the new work factor, the new salt, and the new hash.

4) Authenticate the user with the shiny new algorithm the passwd file indicates -- the latest algorithm, work factor, and salt width.

5) Then the server must forget the plaintext password.

After a month or two, if some rows of the passwd file still indicate some old, obsolete hashing algorithm and work factor -- i.e., those users haven't logged in for a month or two since you made the change -- you might send them a mail or call them on the phone and ask them nicely to log in soon.

After a few months, if there's still some user whose row of the passwd file still indicate some obsolete algorithm -- i.e., that user hasn't logged in for months -- perhaps you could reset that password and generate a new random unguessable password, more-or-less the same as if that user had forgotten the password and gone through the normal "I forgot my password" process.
If the user ever comes back, go through the normal "I forgot my password" process again to reset the password back to whatever the user wants to use.

See "Migrate old md5 passwords to bcrypt passwords"
for more discussion of this approach.

further discussion

"How to upgrade a password storage scheme (change hashing-algorithm)"
has some discussion of both the "Rehash all passwords immediately, without continuing the old hash" and the "Rehash passwords one at a time" options.

All of the above approaches have the advantage that your users can continue to use the same password -- it's a "transparent upgrade".
Alas, that means they all have the same flaw:
If any of your users was using a short or otherwise easy-to-guess password,
and then the bad guys somehow get their hands on old server backup tapes (you do make backups, right?) that contain the old, easy-to-crack hashes,
then the bad guys could use one of several infamous utilities to discover those easy-to-guess passwords -- passwords which will still work just fine after any of the above approaches.

The knee-jerk response of some system admins is to force your users to change their password every 90 days to one that is significantly different from any previous password they've ever used this year, and this time reject proposed new passwords unless they jump through a bunch of unnecessary hoops to make the password strength checker happy.


Is authentication length always a subset of encryption length?

When we have regions of the packet that we only authenticate but not encrypt, that happens because we have data that we want to bind to the encrypted region, but we don't need to include within the encrypted region.  Examples of this are:

For IPsec, we include the sequence number (as a part of the ESP header).  We include that within the authentication (otherwise someone in the middle could change that arbitrarily), however we don't want that to be encrypted (otherwise, the decryptor would have to decrypt the packet before processing the sequence number).
For TLS, we include the sequence number.  We include that to prevent someone from replaying a TLS record; however this is different from the IPsec case, as we don't actually include the sequence number in the packet; both sides are expected to include that implicitly.

Now, the question is: does the opposite make sense?  Do we ever have a case where we care about the privacy of a field (so we need to encrypt it), but we don't care about its integrity (so if someone changes it, we don't really care)?

Personally, I'm having problems thinking of a scenario where this makes sense; if we have an encrypted region, one would expect that we do authentication over that entire region, and not pick and choose.

I also can't think of a protocol which attempts to take advantage of that (other than protocols which don't do integrity checking on anything - we try to discourage that, but they do exist).


Single Party Encryption, Multi Party Decryption

Check out Pedersen's scheme for threshold ElGamal (link). Also, check out (this) for an application to electronic voting.

Basically, the scheme works like this. There are $n$ parties, out of which at least $t$ must be reliable or else the scheme collapses. They choose a prime $p = 2q + 1$ where $q$ is also prime, i.e.: $p$ is a safe prime. Additionally, they choose a generator $g$ of the $p$-order subgroup.

Every participant $i$ chooses a polynomial $f_i(x) \in \mathbb{Z}_q[x]$ of degree $t-1$ and privately distributes the points $f_i(j)$ to each participant $j$. Each participant $j$ adds together all the points he received: $f(j) = \sum_if_i(j) \mod q$. The participants have now shared a global polynomial $f(x) = \sum_if_i(x) \mod q$ which is uniquely defined by $t$ points. The secret is located in $f(0)$.

In order to make the scheme verifiable, each of these private shares $f_i(j)$ is accompanied by a public commit value $g^{f_i(j)}$. Each participant is commited to his share $f(j)$ in the global polynomial as $g^{f(j)} = \prod_ig^{f_i(j)} \mod p$ is publicly known.

In order to raise a value $h$ to the power $f(0)$, the participants do the following. Each participant raises $h$ to the power of his own share. They publish $h^{f(i)}$ along with a Chaum-Pedersen proof (link) that the exponent in this value with respect to base $h$ is the same as the exponent in the commit value $g^{f(i)}$ with respect to base $g$.

Anyone can now combine the shares and calculate using Lagrange interpolation $g^{f(0)} = g^{\sum_if(i)\prod_{j \ne i}{-j \over i-j}} = \prod_i(g^{f(i)})^{\prod_{j\ne{}i}{-j \over i-j}} \mod p$.

The indexes $i$ and $j$ run over any set of at least $t$ trustworthy participants. This exponentiation procedure is used once for key generation and once for ciphertext decryption. Note that this allows an arbitrary order of contributions from the participants, so long as at least $t$ participants remain uncorrupted. For the rest we follow the regular ElGamal cryptosystem.


What's the difference beteween SIDH and SIKE?

SIDH is a form of post-quantum Diffie–Hellman key exchange with a non-abelian structure using isogenies. It stands for Supersingular Isogeny Diffie–Hellman. SIKE is the name of the specific submission given to NIST for standardization with a set of specific, fixed parameters. It stands for Supersingular Isogeny Key Encapsulation. SIKE is SIDH, but not all SIDH parameters are SIKE.
From their official website, SIKE is standardized in two forms: SIKE.PKE, an asymmetric encryption algorithm, and SIKE.KEM, a key encapsulation mechanism. They both support four parameter sets: SIKEp434, SIKEp503, SIKEp610, and SIKEp751. SIDH is just an algorithm and doesn't standardize any parameters. You could say SIDH is to SIKE as ECDH is to (the public key part of) ECIES.


RSA public key can decrypt the ciphertext it encrypted?

The prime 2 is special, and too small.

You happened to choose an $e$ which is equal to $d,$ as I explain below.
For a proper choice of large primes, it is extremely unlikely that $d=e,$ but if it is, one can simply choose another $e$ and compute the corresponding $d.$

Also, a correction, you public key is $(n,e)=(14,5)$. It is your ciphertext which is $c=m^5~mod~14.$ For this tiny example it happens that $e=5$ satisfies $$e^2=1~(mod~\phi(14))$$ so $d=e$, thus your public and private exponents are the same, not a good thing.

Also you say your private key is $m^{11}~mod~14$, which I interpret to mean your private key $(d,p,q)$ has $d=11.$ This is a valid $d$ since $5\times 11=55=1~mod~\phi(14).$ The correct terminology is $$m=c^d~(mod ~n)$$since the letter $m$ is reserved for the message.


Can I make a cipher (ex: Vigenère) harder to break?

For Vigenère specifically, you can make it harder to break by increasing the size of the key and by making the key truly random.  If the key is truly random, longer than the plaintext and never reused, then Vigenère becomes equivalent to a One Time Pad.

Even without going that far, it is possible to strengthen many, though not all, cyphers by lengthening and/or randomising the key.


A byte is 8 bits; 10 random bytes are therefore 80 random bits, which is $2^{80}$ equiprobable alternatives (not $2^{40}$), which is 80 bits of entropy.  (Unless your 10 byte random string is actually an ASCII representation of a 40-bit hexadecimal value; since SecureRandom outputs full range byte[] I'll assume it's not that.)

  This secret is encoded afterwards (e.g. Base64). This is supposed to reduce entropy, while extending the string length.

This "entropy reduction" isn't real.  Any Base64 encoder is a one-to-one function—each of the $2^{80}$ inputs in your example is mapped to a unique output.  There are therefore $2^{80}$ unique possible outcomes as well, each one equally likely, and thus 80 bits of entropy like originally.

What's probably confusing you is that the binary representation of the Base64-encoded string is longer than 80 bits, but it's not made of uniform random bits, so in that sense it's not a full-entropy string—the 14-ish bytes in the Base64 string are 112 bits long but would only collectively have 80 bits of entropy.

  If I want to brute force the secret, does the encoding has any negative impact on the protection?

Not really.  Again, $2^{80}$ possible outcomes, all of them equally likely.


This doesn't address your question; however the algorithm in the paper is broken.  The paper does show that recovering the key requires you to solve the approximate GCD problem (which may be difficult); what they don't show is whether recoverying the plaintext requires solving a hard problem.  It turns out that it isn't that difficult at all (a bit of linear algebra), and hence the attacker can get at what he really wants (after all, the only reason we're interested in the private key is because the key would give us access to the data).

The insight behind this is that the decryption process for a fixed private key is entirely linear; the system attempts to make decryption without the key infeasible by restricting all plaintexts to be within an $N-1$ dimension subspace (where the ciphertexts are vectors of size $N$); however if the attacker knows $N-1$ linearly independent ciphertexts, and the values they correspond to, then he can, for any ciphertext within that $N-1$ dimension subspace, find the linear combination of the known ciphertexts that make it up (and hence deduce the plaintext that corresponds to it).  Since any valid ciphertext will be within that linear subspace (that's inherent in the system), that means that we can decrypt anything.

This doesn't address the question of "is approximate GCD a hard problem"; however it does break that specific cryptosystem.


That is a very good question. First, observe that in general, using a common random string (or any other form of trusted setup) is necessary to get any provable security guarantee, as soon as you want your proof system to handle statements outside of BPP. Indeed, it is known that non-interactive zero-knowledge proofs without any trusted setup can only exist for languages in BPP.

So, it is necessarily the case that "something" relies on the common reference string being sampled at random, in a trusted way. That "something" can be either soundness, zero-knowledge, or both (since those are the two security properties we care about). With most existing proof systems, the crs is actually needed for both:

if the prover picks the string himself, he can break the soundness of the proof (i.e., prove incorrect statements)
if the verifier picks the string himself, he can break the zero-knowledge property of the proof.

Whether this issue can be mitigated has been studied under the name of subversion resistance. This is a line of work which attemps to build NIZKs/SNARGs that maintain some security guarantees even if the common reference string is adversarially subverted. It was initiated in this paper. Essentialle, it shows that achieving zero-knowledge and preserving soundness under subversion at the same time is impossible - however, the other way around is possible. Several follow-ups (1, 2) have built various subversion-resistant SNARGs.

The transparent setup of STARKs avoid this issue essentially by relying on the Fiat-Shamir transform; in the random oracle model, it is in fact possible to have NIZKs without setup for arbitrary languages, so that's just what they do (succinctly). Of course, in the end, their non-interactive argument has no provable security guarantee in the plain model, but only heuristic security guarantees given by the analysis in the ROM.

So to conclude:

Standard SNARGs: you need to perform a trusted setup or find a globally verifiable source of randomness which is hard to manipulate (e.g. the result of the last 100 loteries, or randomness extracted from black spots on the sun, or whatever you like - to be honest, any nothing-up-my-sleeve number should work in practice, so you can just take the digits of Pi). But in exchange for that, they can be proven secure under some (non-standard) assumption, in the standard model.
STARKs: no trusted setup, you have a provably secure construction, but only in an idealized model with a random oracle. This gives you something heuristically secure, but with no formal security argument, when you replace the random oracle with a true hash function. However, it removes the burden of finding a source of globally verifiable randomness.


How do you derive the lambda and beta values for endomorphism on the secp256k1 curve?

Given that $N$ and $P$ are prime, one obvious way to do this is to select a random value $g$ from $[1, N-1]$, and compute $g^{(N-1)/3} \bmod N$; assuming that $N \equiv 1 \pmod{3}$, this resulting value will either be 1, the displayed value of $\lambda$, or $N-\lambda-1$ (with equal probabilities of each).  If $N \not\equiv 1 \pmod{3}$, then the only modular cube root of 1 will be 1.

And, to compute $\beta$, you do the same with $P$.


OpenPGP/X.509 bridge: how to verify public key?

If you can put the entire PGP certificate in a proprietary non-critical extension then you don't need to find the PGP certificate in a store. This solution depends on the condition that you are able to create your own OID and insert the PGP certificate in the extension. Furthermore, the server should accept such a certificate and contain methods of validating the PGP certificate as well.

The CA can accept or refuse requests containing a PGP certificate. It should at least check that the key in the PGP certificate matches the one in the signed request. One method of doing this is to validate that the modulus of the PGP and X5.09 public key match.


Dieharder How can I make my input file suitable for Dieharder?

Personally I never bother with ASCII and just go binary as it's easier, but so be it. There's a lot of good stuff on this page, but in essence what you need to do is...
One.
To use it with an ascii formatted file:

     dieharder -g 202 -f your-file.txt -a

   (your-file.txt should consist of a header such as:

    #==================================================================
    # generator I did it myself
    #==================================================================
    type: d
    count: 100000
    numbit: 32
    3129711816
      85411969
    2545911541
    etc...

Two.
Please read https://crypto.stackexchange.com/a/61546/23115. This is important. Dieharder is a glutton and craves loads and loads of data. 2,500,000 ASCII characters is way too low and the result will be absolutely meaningless other than just failing.  The example in the linked answer sucked up 246 GB of binary bits so as not to rewind the data sample. That's more than a terabyte of ASCII.
Tip.
Randomness is a function of sample size. The size of your data set indicates alternative tests, such as the original diehard, or NIST's randomness test suite. The latter is pretty common in the literature for modern RNG designs, and I prefer it.

dieharder -a -g 201 -f your-file.bin to do it in binary without all that header nonsense.


Most Compact Secure Post-Quantum Signatures and Public Keys?

First of all, you have to say bye to the assumption that you get something like RSA or even ECDSA. Sizes for post-quantum candidates are larger than for classical schemes. Period. There exist schemes with small public keys or signatures but never both. The point is that you can often shift information around between public key and signature but the sum remains the same or gets even worse.

Generally, you got three areas that you can pick from: Hash-based, lattice-based, or multi-variate signatures. Code-based and isogeny-based do not really have practical proposals, yet. Each of these areas has its advantages and disadvantages.

Hash-based gives you the most reliable security guarantees, small public keys and moderate size signatures. For small, fast signatures you require to maintain a state (XMSS / LM-HSS), for stateless schemes (SPHINCS, SPHINCS+, Gravity-SPHINCS) signatures get to the order of 10th of kilobytes.

Lattice-based crypto currently provides you with the best sizes. If the current parameters turn out to be secure you can get away with 2.5 kilobyte signatures and 1.5 kilobyte public keys (Dilithium). However, the cryptanalysis of lattice problems is still on the move. It would not be totally surprising if someone finds an algorithm that is an order of magnitude faster than current attacks (this does not mean that the schemes would be broken but that parameters would have to be adjusted).

Finally, for MQ or multivariate signatures you got two choices: You can go with schemes like UOV or Rainbow (careful: patents) which offer extremely  short signatures but somewhat large public keys (I do not know exact numbers  as all I found are numbers for classical attacks and 80bit security...). If you further add cyclic structure to the keys, public key sizes go down. However, these constructions are heuristic and we only know that they were not yet broken with known attacks. Especially, their security is not only linked to the MQ-problem but also to far less understood problems like IP and MinRank. Alternatively, you can go with something like MQDSS which has a security reduction from MQ. However, then you are at slightly larger sizes than SPHINCS.


Using a public key as a secret to authenticate the sender

In general this is not secure.
Proof (by Maeher): Given any public-key encryption system, we can make a variant that prefixes the ciphertext with the public key. Since the public key is assumed public (hence its name) in all standard security definitions, the new system is as secure as the previous one from the perspective of such definitions. But if we use that variant in the question's scheme, at step 4 Alice now sends the public key and some cryptogram. An adversary intercepts her message to Bob, gets the public key, generates a new $k$, encrypts it with the public key per the variant cryptosystem, then impersonates Alice including in step 6.
Another example, this time using a well-known (though insecure) public-key encryption scheme, would be textbook RSA encryption: at step 4 Alice computes and sends $k^e\bmod n$. An adversary replaces that cryptogram with the integer $1$ (or $0$). Bob successfully decrypts that message, to $k=1$ (or $k=0$), because $1^e\bmod n=1$ (or $0^e\bmod n=0$) for all RSA public keys $(n,e)$. Again the adversary knows $k$ and impersonates Alice including in step 6. Also, textbook RSA is among schemes performing essentially no check after decryption, thus step 5 just can't fail.
If on the other hand we use RSASSA-OAEP, I see no attack. That's because (contrary to Textbook RSA) there are stringent checks after decryption, no obvious way to craft a cryptogram that pass them without the public key, and only very little exploitable information about the public key leaking in a cryptogram. For any attack I think of, the question's protocol will stop at step 5 (if Alice was not involved in preparing the cryptogram) or/and it will use at step 6 a key chosen by Alice and unknown to the adversary. But this is not how RSAES-OAEP is designed to be used, thus that security is accidental and is not to be relied upon.
Exchanging out of band the secret key for a symmetric cryptosystem, and optionally using that to build a session key $k$ will do better.


Three party coin flipping protocol with only 2 active participants

Your requirements are not terribly precise, so here is what I think you mean:

"The result must be trusted by all three participants" ==> Even if Alice & Bob are both malicious & colluding, the output of Carol should be uniform. Also, all 3 should get the same output.
"The coin is flipped only by Alice and Bob" ==> Alice & Bob do all the work. At the most Carol should just send some information to them beforehand, and get some information from them afterwards.

In that case, it's impossible. Alice & Bob can collude and do the following to force the coin toss to be whatever they want. Suppose they want it to come up heads:

Receive the initial message from Carol.
Run the protocol between the two of them until they are just about to send the final messages to Carol. By our assumption, Carol is not involved in this part.
At this point Alice & Bob can compute what the output is going to be. They both get output eventually (by correctness, it must be the same output Carol will get). But they will receive no more messages from Carol so they must be able to compute their output without her.
If the output is going to be tails, repeat part 2 fresh. Since Carol has no input to the protocol during step 2, correctness of the protocol requires that doing this is undetectable. This must result in a completely fresh outcome, otherwise there is an attack where Carol can fix the outcome of the coin.
If the output is going to be heads, send the final message to Carol.


Properly securing a private key for remote storage

You should store a salt for HKDF-Hash alongside the encrypted message.  That way, the adversary can't attack many passwords simultaneously.
You should use your application's name, and the purpose of the key, as the info for HKDF-Extract.  That way, even if you are tempted in the future to use the same password for another purpose, it will be clearer what you must do to avoid accidentally reusing the key.
It may be OK to use a 128-bit key, but unless you're budget-constrained, you should use a 256-bit key to avoid multi-target attacks on AES.  There's nothing wrong with using a larger key than your target security level.
The way that AES-CTR works is that for a key $k$ and a nonce $n$, it generates a one-time pad $\operatorname{AES}_k(n \mathbin\Vert 0) \mathbin\Vert \operatorname{AES}_k(n \mathbin\Vert 1) \mathbin\Vert \cdots$, and xors that with your message to get the ciphertext.

What does $n \mathbin\Vert 0$ mean, exactly?  It's the concatenation of some bit encoding of a per-message nonce, which may be anywhere from 0 to 128 bits, with some bit encoding of a per-block counter, whose length must be $128 - \ell_n$ where $\ell_n$ is the maximum number of bits in the nonce.  The point is that we never reuse $\operatorname{AES}_k(x)$ for different parts of the plaintext.

In the WebCrypto API, §25.3 AesCtrParams dictionary, your obligation is to pass a byte array [0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b; 0x00 0x00 0x00 0x00] that will serve as the initial input with the nonce, and then specify how long the counter is to be incremented as an integer, marked in this example by a semicolon.

First, you must never use a nonce more than once with any given key.  If your key is used only once ever, then you can just use an all-zero or empty nonce.  If you reuse a key, then with AES, you should use a sequentially incrementing nonce, or think very carefully about what limits your application can live with on the number of messages you use any particular key with.  In this case, I recommend a single-use key; if you want to use the same password for different purposes, just derive an independent key using a different HKDF-Expand info parameter.

Second, the number of bits in the counter must fit the length of the longest message you can encounter.  That is, if you handle up to $\ell_m$-bit messages, then you must specify a counter length in bits that is at least $\lceil\log_2 \ell_m/128\rceil$.  Here we divide by 128 because each counter value corresponds to 128 bits of AES-CTR key stream.
Actually, you may not want to use AES-CTR directly because it does not provide authentication.  Unless you are again budget-constrained, or for some reason you want to avoid authentication (which makes sense in some applications, like a scheme to require 2FA for disk encryption so that the adversary can't even test a password guess without a separate physical token, but seems unlikely here), you should always use authenticated encryption by default absent a particular reason not to: AES-GCM, not AES-CTR.
Beware timing side channels in software implementations of AES (and GHASH, if you use AES-GCM)!  Even though hardware AES support is widespread today, it takes a lot of effort to audit your software stack well enough to guarantee it is reliably using the hardware AES support on all platforms that may be of interest to you.  If you use NaCl crypto_secretbox_xsalsa20poly1305 instead, this is not a problem.


What is the meaning of probabilistic polynomial time adversary?

Yes, but note as below, the probability is not biased.
From the Lindell, Katz book;

An algorithm $A$ is said to run in polynomial time if there exists a polynomial $p(\cdot)$  such that for every input $x \in \{0,1\}^*$, the computation of $A(x)$ terminates within at most $p(|x|)$ steps.
A probabilistic algorithm is one that has the capability of "tossing
coins", i.e. the algorithm has access to a random source of randomness
that yields unbiased random bits that are independently equal to 1
with $1/2$ probability and to 0 with $1/2$ probability.

Probabilistic Polynomial-time adversary means; An adversary runs in probabilistic polynomial time algorithm.

Different formulation (due to a comment of SEJPM):

A probabilistic polynomial-time algorithm is a probabilistic algorithm that may only perform a polynomial amount of operations including at most a polynomial number of coin-flips.
A probabilistic polynomial-time adversary is then any probabilistic polynomial-time algorithm.


How to determine RSA block size for decryption

Nobody (at least, nobody who does crypto seriously) splits up data into blocks to be independently encrypted with RSA. Not only is this inefficient, in CPU and in network bandwidth (because asymmetric encryption necessarily implies data enlargement), but we do not really know how "safe" it is. This is a little-studied question, so there is no accepted protocol for that.

Real-life protocols that use asymmetric encryption (e.g. CMS or OpenPGP) use hybrid encryption: the asymmetric algorithm is used to convey a symmetric key, which is then used with a symmetric encryption algorithm to process the bulk of the data. This has the extra advantage of also working with key exchange algorithms (like Diffie-Hellman) which are not asymmetric encryption algorithms (in a way, DH can be seen as an asymmetric encryption algorithm where you do not choose what you encrypt).

RSA-encrypting data "directly" is encountered mostly in protocols that must live under strict bandwidth constraints (e.g. in smart cards), where every single byte counts; but in that case, messages are very short, and there is no question of splitting messages into blocks.


key specifications for x25519 - need two clarifications please

About your first question, yes, the set of private keys is restricted to those $2^{251}$ values that are always a multiple of $8$ and that's security by design:

By making sure the input scalar of the scalar multiplication algorithm is a $255$-bit value will the algorithm specified in the RFC will always perform 254 loops and each of those loops will perform the exact same operations (one addition, one doubling): it's a simple protection against simple side-channel analysis
To prevent against the invalid point attack (Bob giving to Alice a point of low order on another curve), only the $x$-coordinate is used, so the point belongs either to the curve or its quadratic twist. The only points of low order on those curves have order $2$, $4$ or $8$, so if Bob submits one of those, Alice will always get $0$ (representing the infinity point in the X25519 function) as an output of the key-exchange and detect that it is invalid. Invalid point attack and small subgroup attack are prevented.

You might want to read the original papers on it: Curve25519:new Diffie-Hellman speed records and Can we avoid tests for zero in fast elliptic-curve arithmetic?

About your second question, it is just fast exponentiation. Look at the binary decomposition of $p-2 = 2^{255} - 19 - 2$. Or look at some already written code (most of Curve25519 implementation come from the same reference).


Cryptanalysis on Kasumi in A5/3 GSM algorithm-- why is it broken in 2G and not in 3G?

KASUMI is not "broken in 2G". In fact it is not even used in 2G. 2G systems use algorithms A5/1 and/or A5/2, which are unrelated to KASUMI (which is A5/3).

The 2010 attack is a "related-key attack": it is a rather esoteric kind of attack in which the attacker obtains plaintext/ciphertext pairs that are encrypted with different keys, but such that the keys differ in a specific and attacker-known way. In that kind of setup, Dunkelman, Keller and Shamir can rebuild the key after some computations (the two hours worth of computation time). However, this still relies on the exact situation with the keys that differ by known amounts; such a situation does not arise in 3G networks. In fact, related-key attacks almost never apply in practice, and in general we don't care much about them (e.g. they were not part of the AES selection criteria); they still count as noteworthy, at least academically speaking, because an ideal cipher, defined as a uniform selection of the cipher among the whole set of possible permutations over the space of block values, should not have even related-key attacks.


I read that something like this might be insecure as hashes become less secure the more often you hash them again.

While this is technically true, you shouldn't worry about it. This paper has precise bounds on how bad it is to iterate a random function and with the iteration count $r<10$ as you are worrying right now this is a non-issue for security.

  This would prevent someone who somehow got a (doubled) hashed password
  from our database from logging in into our api (since he needs to
  provide the 1st hash) and also would allow the app to not store the
  passwords of the user in plain text.

This is a good idea and also the ideal model of how client-side password hashing is supposed to work: You compute an (expensive) password hash on the client, send it to the server who then hashes (or somehow else one-way processes) it so that an attacker leaking the database doesn't get all the log-in hashes for free.

  Should I maybe use different hash-algorithms for both actions?

Yes. As explained in the previous paragraph, you want to use a slow password-hashing scheme on the client, like Argon2 and then you can use a fast (normal) hash function on the server, like SHA3-256.


Can a zero nonce be safely used with AES-GCM if the key is random and never used again?

Usually. However, if you are using 128-bit AES in CTR mode (remember that GCM is essentially just CTR with authentication), then a kind of attack called a multi-target attack can become possible. This attack is realistic when an attacker has a huge amount of stored ciphertext, each with a random key. While breaking a specific key requires performing up to 2128 operations, breaking any key is significantly easier. This attack can be mitigated either by using a larger key size, or by using a random nonce.

From the above-linked blog post by DJB:

  What the attacker hopes to find inside the AES attack is a key collision. This means that a key guessed by the attack matches a key chosen by a user. Any particular guessed key has chance only 1/2128 of matching any particular user key, but the attack ends up merging costs across a batch of 240 user keys, amplifying the effectiveness of each guess by a factor 240.


AES-GCM cipher tag and IV size, while attempting to render encrypted ciphertext useless by removing them

But, for the purpose of optimization, I was thinking to delete only its IV and Tag, thus hoping to make decryption of that segment's data computationally infeasible.

Neither work.  The IV might seem to work (as doing a brute force search over a space of size $2^{96}$ might appear to be daunting), however the attacker has another potential approach.

If an attacker has the ciphertext, has a correct guess to 16 bytes of the plaintext, and the key, he can recover the IV; from there, he can recover the rest of the plaintext.

Because of the likelihood of the attacker guessing 16 bytes of plaintext, this wouldn't appear to be feasible.

And, the tag is even worse (and so is the AAD, in case that occurs to you); an attacker with the key, iv and ciphertext can trivially decrypt the ciphertext without the tag.  He might not be certain that the ciphertext hasn't been modified; however he might be willing to assume that it wasn't.

Since I gave you two negative answers, lets give you a positive idea; why don't you make the key generation procedure:

key :=SHA2( master key || extra data )

Where the extra data is stored on in the segment header (and nowhere else); it is generated randomly when you first encrypt; when you decide to do a quick erasure, you overwrite it. The master key is the one derived from the password with PBKDF2.

If this extra data is at least 256 bits long, recovering the key is no easier than attacking AES-256 directly.


When knowledge soundness implies soundness

The difference is that in Section 4.5, knowledge soundness (i.e., extraction) is required to hold only for every $x\in L_R$, and so there is no requirement at all for the case that $x$ is not in the language. In contrast, in Definition 9 of Lin03, the knowledge soundness (i.e., extraction) is required to hold for all $x$. This implies soundness since you cannot extract a witness for $x\notin L_R$, and so the verifier cannot accept in this case (except with probability of the knowledge error).
Note that this is orthogonal to the question of whether or not $P^*$ is efficient (i.e., whether it's a proof versus an argument).


How to XOR two hex values and am I doing crib dragging correctly? (OTP)

Xoring this "hexadecmal" value of

7ECC555AB95BF6EC605E5F22B772D2B34FF4636340D32FABC29B

with the hexadecimal value of

73CB4855BE44F6EC60594C2BB47997B60EEE303049CD3CABC29B

will lead to:

0D071..... As the page told you.

Xoring is a so called modulo 2 addition without carry bit propagation. You are adding each bit with the corresponding bit of the other string. First you convert your hexadecimal representation into binary. Then you perform the modulo 2 addition. (dots are for better readability)

7ECC5 becomes 0111.1110.1100.1100.0101
73CB4 becomes 0111.0011.1100.1011.0100
--------------------------------------
XOR
--------------------------------------
              0000.1101.0000.0111.0001
which is converted into
              0    D    0    7    1

PS:

Apply the following rules for adding each bit.

0 xor 0 = 0
0 xor 1 = 1
1 xor 0 = 1
1 xor 1 = 0


Security of AES under modification of Sboxes and/or MDS mixing layer

Depends on what exactly you’re doing.

Assuming the regular AES algo being implemented like that, it might merely buy you some time/speed – but the standard AES algorithm can and will not get “stronger” (as in ”more secure”).

See, just because you implement the algorithm in a way that it works through several boxes “at the same time” (no  matter what exactly you mean when saying “at the same time”, as there are multiple ways to interpret that), that doesn’t mean you influence or even increase the AES algorithm’s security.

AES will always be AES. If it weren’t, you’ld quickly crash into incompatibilities due to practically having changed the AES algorithm… which would end up in being a completely different cipher, which might (or might not) be based on the AES algo and/or inherit some of its security features.

Which brings me back to my first line: “Depends on what exactly you’re doing.”

If you’re talking about standard AES, the answer boils down to “no, it won’t buy you any security… at all”. AES will always provide the same security, no matter how you implement it. (Off course, I’m assuming you implement it correctly and adher to the AES specification.)
If you’re talking about changing/modifying the AES standard, the answer ends up being a “maybe, but it will be hard to prove your new AES-inspired block cipher is actually safer than AES and it will be even harder to convince people that prefering your new block cipher indeed makes sense. Also, your new AES-inspired block cipher will definitely end up being incompatible to the standard AES algo as well as the several AES implementations out there”.


Yes, but it's different and not as cost-efficient.

The discrete log variant of the number field sieve goes (very loosely) like this:

Collect logarithms of many small primes using sieving and linear algebra (the precomputation stage)
Represent the target field element as a product of small primes and use the small logarithms to recover it (the individual logarithm stage)

In factorization by the number field sieve we do not have an individual log step, so the same principle used in Logjam does not apply directly. But if we look deeper into the inner workings of the number field sieve, we can obtain something similar.

The number field sieve begins by choosing two polynomials $f(x)$ and $g(x)$. The only conditions required for these polynomials is that they share the same root modulo $N$—the number to be factored—and that they are irreducible (if you find a splittable polynomial, you can immediately factor $N$). There are several ways to accomplish this, but the most common is (again, loosely):

Pick an appropriately-sized base $m$
Represent N in base m, and let $f(x)$'s coefficients be the $d+1$ base-$m$ digits of N. Thus $f(m) = 0 \pmod{N}$.
Let $g(x) = x - m$. Trivially $g(m) = 0 \pmod{N}$.

Then, we proceed with the number field sieve:

Find pairs $(a, b)$ such that both $b g(a/b) = a - bm$ and $b^d f(a/b)$ are smooth.
Once sufficiently many pairs have been found, use linear algebra to find two distinct squares modulo $N$: $t_1^2 \equiv t_2^2 \pmod{N}$.
Compute the square roots on both sides, and factor $N$ with $\gcd(t_1 - t_2, N)$.

Notice that $g(x)$, for any particular fixed $m$, is always a root of the polynomial regardless of which $N$ we are working with. This suggests a batching approach:

Pick an appropriately-sized $m$ for a given integer size (or set of integers $N_i$). Say, $m \approx \sqrt[6]{2^{1024}}$ for $N \approx 2^{1024}$.
Precompute a sufficiently-large number of pairs $(a, b)$ for which $a - bm$ is $B$-smooth for some appropriate bound $B$.
For every $N_i$, take the pairs $(a, b)$ precomputed earlier and find the ones for which $b^df_i(a/b)$ are also smooth. Then proceed with the number field sieve as usual.

This approach was suggested by Coppersmith as the "Factorization Factory", and is itself based on earlier work by Schnorr, who also found a batch version of a factoring algorithm by Miller. The complexity Coppersmith came up with was $L_N[1/3, 2.006]$ time and $L_N[1/3, 1.638]$ space for the initial precomputation, and then $L_N[1/3, 1.608]$ time for each individual factorization. Here $L[a, c]$ is the usual

$$
 L_N[a, c] = \exp((c + o(1)) (\log N)^a (\log \log N)^{1-a}).
$$

In 2001 Bernstein proposed the "circuit NFS", which used the area-time (AT) cost metric instead of the usual RAM metric (where memory is free), which had been used until then. This metric shows that the factorization factory is actually pretty terrible when it comes to cost, due to its enormous space (and time) requirements. Circuit NFS instead optimized for the AT cost—using mesh circuits instead of a more common RAM model—and reached an AT cost of $L[1/3, 1.97]$. The Batch NFS follow-up included Coppersmith's factorization factory ideas into the circuit NFS, and given sufficiently many numbers to factor reaches an AT cost of $L_N[1/3, 1.704]$ per factorization.

Now, this may make the Batch NFS sound great, and raise the question of why, say, the FREAK attackers did not use it. Firstly, the Batch NFS assumes a mesh circuit layout; this alone makes implementing it out of reach for the vast majority of people, since we are generally constrained to (more or less) RAM machines. Secondly, the results on the Batch NFS are purely asymptotic—we simply don't know what the constant factors look like in reality.

There is one instance of the factorization factory being used in practice—the Mersenne factorization factory. Here the authors flipped the idea above: instead of fixing $g(x)$ and testing $b^df(a/b)$ for smoothness, they fixed $f(x)$ and tested $a - mb$ for smoothness. The result was an estimated 50% savings in computation on the factoring of 17 Mersenne numbers, with a 70 TB storage overhead. This is a fairly modest saving, but according to the authors it gets worse for general (that is, RSA) numbers. In practice, without your own chip factory you are likely better off factoring each integer one by one with the classic number field sieve.


Any case that can require to encrypt a certificate revocation list before distribution

No. A CRL is as public as the certificate it revokes; it has to be signed to guarantee authenticity, but not encrypted. There are no optional confidentiality requirements for CRL distribution in RFC 5280. It is not even common practice to use anything other than plain http for the CRL distribution points. The whole idea with CRLs is to get them out there to as many as possible, as fast as possible, with as little performance overhead as possible, without sacrificing authenticity.

That said, it might be worth pointing out that an attacker who has compromised the private key corresponding to a certificate, might have an interest in preventing clients to download any CRL revoking that certificate. One way to counter an attacker that both controls the network and has compromised the private key, is for the client to explicitly check the status of a specific server certificate, prior to connecting to the server. Combining CRL distribution with OCSP over https MAY be one way to prevent certain attacks.


Transparent Voting and Advance Secret Code

I am assuming that [electronic elections whereby participants can vote over a network and the results can be publicly tallied without revealing any individual’s vote] refers to Blockchain technology. Are there any other ways of achieving the same?

Voting schemes using Blockchain technology mainly aim at avoiding a central authority. I doubt this is what's suggested, given the text, and it's age. I think it refers to voting remotely thru a network. A slightly later classic on this line of thought on electronic voting (among many) is Berry Schoenmakers' A Simple Publicly Verifiable Secret Sharing Scheme and Its Application to Electronic Voting, in proceeding of Crypto 1999.

For [construct new kinds of secret codes that do not require the communicators to agree in advance on the encryption and decryption algorithms], I am not sure which technology is he trying to refer.

The author likely has used algorithm where he meant key. He would then be referring to Diffie-Hellman key exchange. The book has a mere 9 pages on cryptography (including 3 of exercises/problems), and it's section on Public-Key cryptosystems does not cover DH (only RSA). I would not recommend it as an introduction to cryptography.


Can NORX be used as a general purpose hash function?

What security goals are you hoping for?

If NORX is a secure nonce-based AEAD as advertised (which it may or may not be—CAESAR dropped it and it's not widely deployed, so there's little incentive to study it), then what it will guarantee, as a nonce-based MAC, is antiforgery.  Specifically, no cost-limited adversary who can query an oracle ‘NORX-MAC’ for a single message under a single nonce can forge an authenticator for another message under that nonce.

But, for this security goal, there are much faster choices like Poly1305-AES.  If you want a stronger security goal, like a nonceless MAC or a PRF such as HMAC-SHA256 or keyed BLAKE2s or KMAC256 are conjectured to be, NORX may or may not provide that: it's not advertised as a security goal of NORX.  If you're looking for collision resistance, it's unlikely that you'll find it in NORX as is.