The generator in the question internally transforms the $512$-bit string designated tag into an output determined either:

as $1/10^4$ of a non-negative integer less than $10^6$, whenever the "If the result is smaller.." clause applies;
as $1/10^2$ of a non-negative integer less than $2^{12}$, otherwise.

Determination process 2 occurs for $d_2=(2^{20}-10^6)^{25}\cdot2^{12}$ among the $2^{512}$ bit strings that tag could take (ignoring for now how tag is generated), which forms a tiny proportion $d_2/2^{512}=2^{-110.8\dots}$ of theses bit strings.

At this stage the applied cryptographer:

concludes that determination process 2 is much more likely to occur as the result of a malfunction of something than for any other cause (including if the adversary knows and can manipulate key and message), and ignores that determination process 2 (at least with the level of other information available);
sees that the only credible determination process remaining produces output numbers $x$ with $0\le x<100$ and exactly expressible with 4 decimal digits after the point, with flat distribution if the tag bit string has flat distribution;
sees that any distinguisher between a perfect TRNG producing such $x$ (hereafter: apparent goal), and the output, would also be a distinguisher for HMAC512 assuming unknown key, which he rejects summarily;

and moves on, satisfied that the PRNG in the question is close enough to its apparent goal for any practical purpose, including being unpredictable if the key is unknown.

The theoretician continues unmoved, and carefully classifies the possible outputs into two categories:

one of the $2^{12}$ numbers $x$ with $0\le x<40.96$ and exactly expressible with 2 decimal digits after the point;
other numbers $x$ with $0\le x<100$ and exactly expressible with 4 decimal digits after the point.

Each of the $10^6-2^{12}$ outputs in category 2 is reached only by determination process 1, thus for $c_2=(2^{512}-d_2)/10^6$ tag bits strings. Thus assuming flat distribution of the tag bit string, category 2 is reached with odds $\widehat{p_2}=c_2\cdot(10^6-2^{12})/2^{512}$, which is less than odds $p_2=1-2^{12}/10^6$ of reaching that category in the apparent goal: $\widehat{p_2}=p_2\cdot(1-2^{-110.8\dots})$.

That generator is broken in the theoretician's eye, for he has a distinguisher much better than anything he can dream of for HMAC512.

That is, the theoretician can devise a strategy that will allows him to win with odds $p>1/2$ when playing a game where the objective is to guess, from one given RNG output, if that RNG was selected (by fair coin toss) as the RNG in the question (reaching category 2 with known odds $\widehat{p_2}>1/2$), or as a TRNG with the apparent goal (of reaching that category with known odds $p_2>\widehat{p_2}$). The theoretician is interested in the strategy giving him the highest possible advantage, defined as $\epsilon=|p-1/2|$ (the absolute value is used because it is trivial to turn a strategy worse than answering based on coin toss into one better than that).

Towards that goal the theoretician would hypothetically bet on the RNG in the question when the given RNG output is in category 1, and otherwise bet on a TRNG (not randomly according to the criteria that I gave previously, sorry about that mistake but I'm of the applied kind). To compute the odds $p$ of winning, we consider the two mutually exclusive winning cases for this strategy:

the RNG in the question is selected, and its output is in category 1, which has odds $(1-\widehat{p_2})/2$;
the TRNG is selected, and its output is in category 2, which has odds $p_2/2$;

giving $p=(p_2-\widehat{p_2}+1)/2$ thus advantage $\epsilon=(p_2-\widehat{p_2})/2=2^{-111.8\dots}$.

It is left as an exercise to the reader to show that if $n>1$ outputs of the same chosen RNG are given, the advantage obtained is less than $n\cdot\epsilon$; is still desperately marginal with $n\approx 1/\epsilon\approx2^{111.8}$ outputs; becomes sizable at $n\approx \epsilon^{-3/2}\approx2^{167.7}$ outputs.


Is RC4 a problem for password-based authentication?

By George, you're on to something.

To answer the question you asked, I don't know of anyone actually attempting to recover a password this way, or it even being discussed.  However, it does appear to be feasible, given enough encrypted streams.

How many are enough?  Well, I've started running a few simulations; preliminary results indicate that with perhaps 2 billion encrypted streams that encode the same password, the attacker may be able to deduce enough information to narrow possible passwords to a reasonably small set.

I'll update this answer as I get more precise information on the number of streams needed; however, I've seen enough to be fairly confident that this attack can work.

UPDATE

I have experimentally verified the fact that you can decrypt RC4 if you get the same message encrypted enough times, albeit with somewhat more than I suggested above.  In particular, I encrypted a 16 character password using RC4/DROP-512.  With 8 billion encrypted messages (with the RC4 key for each message being chosen randomly and independently), I was able to successfully recover the exact password by analyzing the statistics for the streams.

I'll be writing up an eprint article detailing my observations.


Even though it is insecure, it still exists! Can someone tell why exactly do we need Aggressive mode? What is it that Main mode cannot do and Aggressive mode can (other than speed)

Well, the original reason behind Aggressive Mode was, in fact, performance.  Specifically, in used fewer round trips to establish the connection than Main Mode.
The original designers of IKE were well aware that Aggressive Mode had lesser security goals than Main Mode; however they did not know how important those goals were, compared to how important connection set up was.  Hence, they included both options.
When they reworked IKE in IKEv2, they reconsidered the options; they decided that the trade offs inherent in Aggressive Mode were a bad trade off (and telling people to support multiple 'modes' was also not a great design); they were able to rework things to get the performance advantages of Aggressive Mode, and keep the security goals of Main Mode.


The CRS must be generated in some trusted manner. One could use a secure coin tossing protocol involving a number of parties, and this would be fine as long as a majority of the parties are honest.

One could also apply a hash function to the New York Times of January 1st 2000 (or any other date) and use the result, although this would need a random oracle assumption.


How many bits are needed for an LFSR to generate a specific number of sequences?

An $n$-bit LFSR with a primitive feedback polynomial will cycle through all $2^n-1$ possible non-zero states. You will need an LFSR to generate $16\times 64 = 1024$ bits. An 11-bit LFSR will cycle through $2^{11} - 1 = 2047$ states and output as many bits, so for your purposes, an 11-bit state is sufficient.

If the feedback polynomial is not primitive, then the period will be unpredictable but not maximal. An example primitive polynomial suitable for use in a maximal-length 11-bit LFSR is $x^{11}+x^9+1$.

It's extremely important to know that an LFSR is not cryptographically secure. An $n$-bit LFSR can be broken after only $n$ bits of keystream are known ($2n$ bits if the feedback polynomial is secret).


Does make sense utilize TLS and Noise Protocol in the same application?

Using two transport protocols is not a good idea. You would double-encrypt your data. However, the symmetric ciphers are generally rather secure if applied correctly.

Besides double encrypting your data you would also get: double the security warnings to react to, double key management, double the initial handshake processing, double the latency.

If you want to encrypt twice it is probably better to perform additional end-to-end encryption / decryption on top of the point-to-point encryption that the TLS security offers. That way you can keep your messages secure over multiple point-to-point connections and after receiving them at the end points. For this you could device your own protocol or you could use web-security.

Generally it is better to perform encryption well once, instead of performing it badly twice. Bullet-proofing your TLS connection makes the most sense if you just require transport protocol security. Encrypting things twice should not be your goal. The goal is simply to secure your messages to the best of your ability.

The noise protocol seems to be in draft stage. Besides that, it seems a rather generic sum of possible algorithms more than an actual protocol. It seems that it mainly has been setup to explain the security behind WhatsApp rather than to be a protocol that you should consider. Just the formatting of the messages is already ill-defined, and it is unclear which kind of authentication method you should be using.


Why is keysize almost always expressed in bits?

It’s traditional.

(Don’t underestimate the power of Tradition. The main reason we use bits is that this is how things have been done for a lot of time. If only to avoid confusion, it is a reasonable idea to stick to traditions. You don’t need a compelling reason to do things in the usual way, but you’d need one to do things differently.)

Also, bytes have not always been octets. The PDP-11 used 9-bit bytes. Even the C standard defines bytes to have at least eight bits, but possibly more.


Assuming that $M_T$ is the order of $g$, then it's real easy to compute $(D)^{\%M_T}$: it's the value $D$.

That is, if $M_T$ is the order of $g$, then we have the identity $g^x = g^{x \bmod M_T}$ for any $x$, and in particular, $g^{r + M_S} = g^{(r + M_S) \bmod M_T}$.

The paper is just noting that the $\bmod$ operation happens implicitly here.

BTW: I've never seen the notation $(g^a)^{\%b}$ before; I don't believe that's very standard...


Are there predictable, yet secure hashes?

It sounds to me like you want to is produce a hash that proves integrity, and can be authenticated with some key pair.

In that case, I would release a HMAC using a RSA public key and your statement along with the RSA signature of the aforementioned HMAC.

That way someone could verify the integrity and authenticity of your statement while only knowing your RSA public key and the signed HMAC.


It's fairly simple.  1st byte of $k$ in pseudo code is:-toAscii("i") XOR toBinary(1st hex pair). ASCII code of "i" = 105 as an example. Then repeat for the remaining bytes to obtain all of $k$.

See ASCII and Hexadecimal for reference.


A key-derivation function that is as strong as the stronger of PBKDF2 and scrypt

scrypt uses PBKDF2 internally, so it's absolutely crucial to prevent nasty interactions. My suggestion would be a simpler scheme (using simplified syntax):

$k = \mathrm{scrypt}(\text{key}, \text{salt} \mathbin\| 0x0) \oplus \mathrm{PBKDF2}(\text{key}, \text{salt} \mathbin\| 0x1)$

This does exactly what you want - that is, the output key has exactly the strength of the stronger of the two, without nasty interactions. Your construction may or may not have the same property, but the close relationship of scrypt and PBKDF2 makes me rather nervous.


How to construct Hash function of type $H:\{0,1\}^x \times G \mapsto Z_p^*$?

Let $G$ have size $M.$ You can map the elements of $G$ in some order in a one to one fashion into $\{1,2,\cdots,M\},$ which can itself be mapped to a length $k=\lceil \log_2 M\rceil$ bitstring $(g_1,\ldots,g_k)$ where $2^{k-1}\leq M< 2^k$ by the normal encoding of positive integers.

Let $(u_1,\ldots,u_v) \in \{0,1\}$ be the binary string. Apply $H$ to the concatenated string, $$z=H(u_1,\ldots,u_v,g_1,\ldots,g_v),$$ convert the (say 512 bit) output of $H$ to an integer $z$ by the usual encoding. The final output of this process is $z\mod p.$


Would RSA make sense if we used no computers?

I thought about this and have done a bit of research, and the answer is no.
The problem is the gap between the difficulty of factorisation versus prime generation isn't really large enough at the scale of primes/moduli we can work with.
By 1588 the largest prime discovered was 524287, thanks to Pietro Cataldi. This was a prime generated by a single person's work. I don't know how much effort this took, but given that it was a world record at the time, I think we can assume it was a fair amount of effort.
In order to have a secure instance of RSA, we'd probably want to generate a modulus using two six-digit primes. That's already quite a bit of work.
However, a nation-state can draw on more resources. They could hire a team of people to try and break the message. One observation is that there aren't actually that many primes below 1,000,000: there are only 78,498! If we consider only the primes between 100,000 and 1,000,000, this number comes down to 68,906.
A nation-state could use the sieve of Eratosthenes to find all the primes below 1,000,000. This would be a one-off effort.  They would then need to attack any modulus which is the product of two six-digit primes.
Finally, to factor a particular spy's modulus they simply could give it to a pool of people who would work down through the list.
Let's say one person can try one division every five minutes. That seems like quite a long time given the size of the numbers. Nonetheless, in one eight-hour working day, they could try 96 divisions per day. Across a pool of 20 people it would take 35 days to run through the entire list.
In practice, most moduli would be solved much sooner than this because both primes will appear somewhere in the list.
This attack is entirely practical and thus makes RSA pretty useless for encryption in that historical period.


XMSS WOTS+ private keys vs XMSS private keys

Do I have to ignore the fact of array[len] n-Byte private keys and generate just 2^h WOTS+ keys using the chaining function?

In practice, what we do is follow the recommendations of section 4.1.11 of RFC 8391, and generate all the WOTS+ private keys dynamically as needed from a single secret seed.
The RFC recommends a two step process; you use the PRF function (with the ADR with the index of the WOTS+ key you're retrieving) to generate an n-byte value they denote as S_ots; then for each WOTS+ chain, you run the PRF function again on the S_ots value to generate the starting value for that chain.
And, if you're implementing XMSS^MT, you'll also want to pay attention to section 4.2.6, which adds a third layer to distinguish between different XMSS trees.  I suspect that step isn't needed (the ADR structure already distinguishes that); on the other hand, it's fairly cheap to follow the RFC's recommendations.


a salt cannot "weaken" a password in any way
long salts make pre-computation of rainbow tables completely infeasible, across all machines using that application worldwide. Basically, by choosing a random 16-byte salt you're basically ensuring that your password hash is unique worldwide no matter the password
Pseudo-random values are preferred to ensure global (or at least system-wide) uniqueness of the hash (as described in #2 above). These bytes should come from a CSPRNG ("true randomness" isn't required). Using predictable salts such as time stamps can allow an attacker to create rainbow tables for subsets of the passwords in use.

Finally, traditional salted hash constructions (such as SHA256(salt||password)) are insufficient for modern password storage. You should use a memory-hard, purpose-built password hashing function like Argon2 or scrypt. These also take salts as inputs, so the same logic applies as above.


This is not very secure. You directly leak the symbol distribution, because only the order of symbols changes. For short enough messages this allows easy decryption – e.g. "dr olllWeoH" is quite clearly "Hello World". Even for long messages or binary values, the fact that you leak e.g. a crucial byte may be enough.

You also have not defined how the same key would be used to encrypt multiple messages. Using the same stream of random numbers would be fatal, allowing easy known-plaintext attacks at the very least. You would need an IV/nonce of some kind, which may itself make the fact that the message is encrypted detectable.

If the problem you are trying to tackle is hiding the fact that the message is encrypted, you should look into either steganography or format-preserving encryption:

Steganography  is about hiding secret messages in normal-looking messages. You could use a standard encryption algorithm (say AES-GCM) to encrypt the message and then hide it in a cover message using some steganographic scheme.
Format-preserving encryption, on the other hand, allows you to keep the encrypted message in the same format as the plaintext, which might be sufficient to hide the fact that it is encrypted. For example, database fields can be encrypted in place. Beware that depending on the application FPE is not necessarily as strong as normal authenticated encryption can be.


The Collision Differential for MD4 - a question on notation (Wang, et al)

In the MD4 algorithm, the message which is being hashed is split into a series of 512-bit blocks. The collision attack which you reference forms a collision in a single block. That is, the attack forms two colliding messages, X and X', which are identical for every block but one. The paper refers to the blocks of X and X' which differ from one another as M and M', respectively.

Because the parts of X and X' which come before blocks M and M' are identical, they have the same hash. The hash of these blocks is referred to as H$_0$. So $\Delta$H$_0$ = 0 is just saying that the intermediate hash of the messages before blocks M and M' are identical.

$\xrightarrow{(M_,M')}$ means that block M is hashed as a part of its message, and block M' is hashed as a part of its message.

Once these message blocks have been hashed, the hashes of the two messages are still identical, which is what $\Delta$H = 0 is saying.

So, what the equation as a whole is saying, in English, is: "The intermediate hashes of two messages are identical. Then, we process a single block of each message. These blocks are called M and M'. Even though these blocks are not identical, their final hashes are identical."

Note that in some papers for differential cryptanalysis, M and M' will refer not to a single message block, but to the message as a whole. So this is not standard notation.

When I was starting out in differential cryptanalysis, I also had a hard time understanding this equation, but I hope this has helped you.


What is the correct name for bytes which are to be signed?

The correct term for bytes to be signed is “message”.
Generally, it does not really matter if a message to be signed is human readable or not. Sometimes, you may also find it mentioned as “digital message”… which practically is the same and merely extends the term to explicitly hint at the fact the message is digitally stored and/or processed.
References showing the use of the term can be found at various sources. For example: scientific papers and websites talking about cryptography and/or cryptanalysis in relation to digital signatures.
For your convenience, here are a couple of quotes showing its usage (bold-italic emphasis is mine):
randomly picked, yet well-known websites

source: https://en.wikipedia.org/wiki/Digital_signature

… Digitally signed messages may be anything representable as a bitstring: examples include electronic mail, contracts, or a message sent via some other cryptographic protocol. …

source: https://support.office.com/en-us/article/Secure-messages-with-a-digital-signature-549ca2f1-a68f-4366-85fa-b3f4b5856fc6

… By digitally signing a message, you apply your unique digital mark to the message. … This information proves to the recipient that you signed the contents of the message …

randomly picked, yet well-known crypto-related papers

source: Identity-based cryptosystems and signature schemes by A Shamir - Advances in cryptology, 1985

… However, when g is known, there is a very simple way to generate any number of signatures of any message even when the factorization of n is unknown. To sign the message m, the user chooses a random number r …

source: A digital signature based on a conventional encryption function by RC Merkle – Advances in Cryptology (CRYPTO'87), 1988

… If A wishes to sign message m …

source: Group signatures by D Chaum, E Van Heyst – Advances in Cryptology (Eurocrypt'91), 1991

… If person i wants to sign message n, he chooses randomly some set r of persons (including himself); his signature will be … If person i wants to sign message m=An), he randomly chooses …

source: The exact security of digital signatures-How to sign with RSA and Rabin by M Bellare, P Rogaway – Advances in Cryptology (Eurocrypt'96), 1996

… In order to sign message M , the signer first picks a random
seed T of length …


I have a plaintext about 18 bit size. I have to encipher it using RSA. How large have to be $p$ and $q$?

For security, the recommendation is: very large, like each at least 700 bits and the sum of their bit size at least 2000, so that their product is hard to factor. But maybe that's not the answer thought, for it does not consider plaintext size. Also, there are other conditions for security.
In textbook RSA, the public and private keys are $(N,e)$ and $(N,d)$, with $N=p\,q$, $e\,d\bmod(p-1)\;=\;1\;=\;e\,d\bmod(q-1)$, where $p$ and $q$ are primes. Encryption of a plaintext (integer representative of a) message $m$ is per $c=m^e\bmod N$, and decryption is per $e=x^d\bmod N$.
From the later equation and the definition¹ of $\bmod$ it follows that decryption can return the original message only if $0\le m<N$. This condition is sufficient when primes $p$ and $q$ are distinct (see this question), which we'll assume.
Thus $p$ and $q$ should be large enough that the largest possible $m$ verifies $m<p\,q$. If $m$ is 18-bit, by the definition² of bit size, it is sufficient that $p\,q\ge2^{18}$.
In term of bit size of $p\,q$: at least 19 is sufficient.
In term of sum of the bit sizes of $p$ and $q$: at least 20 is sufficient. This follows from $\|p\|+\|q\|-1\le\|p\,q\|\le\|p\|+\|q\|$.

p=61, q=127 not working

Correct. One way to prove this is that $2^5=32\le p=61<64=2^6$ and $64=2^6\le q=127<128=2^7$, therefore $p$ is 6-bit and $q$ is 7-bit, therefore $p\,q$ is no more than 13-bit, thus all 18-bit $m$ are such that $m\not<p\,q$, thus such $m$ does not belong to the plaintexts that can be enciphered and deciphered back to the original.

p=997, q=4253 OK working

Correct. One way to prove this is that $2^9=512\le p=997<1024=2^{10}$ and $4096=2^{12}\le q=4253<8183=2^{13}$, therefore $p$ is 10-bit and $q$ is 13-bit, therefore $p\,q$ is no less than 22-bit, thus all 18-bit $m$ are such that $m<p\,q$, thus such $m$ belongs to the plaintexts that can be enciphered and deciphered back to the original.
By computing $p\,q=4240241$, we can find that $p\,q$ is 23-bit (rather than the minimum of 22 established above), thus $p=997$, $q=4253$ allows decryption of all messages up to and including 22-bit, and some 23-bit messages.

¹ For integer $i$ and strictly positive integer $k$, the quantity $i\bmod k$ is uniquely defined as the integer $j$ with $k$ dividing $i-j$ and $0\le j<k$. It is written $j=i\bmod k$ without an opening parenthesis immediately on the left of $\bmod$.Contrast with $j\equiv i\pmod k$, which means that $k$ divides $i-j$, but leaves the range of $j$ unspecified.
² The bit size of a strictly positive integer $a$ is the uniquely defined integer $b$ with $2^{b-1}\le a<2^b$. It holds $b=\left\lceil\log_2(a+1)\right\rceil=\left\lfloor\log_2(a)\right\rfloor+1$. In a cryptographic context, it can be written $b=\|a\|$.


Availability of a simple limited PRNG algorithm

Yes.  This paper on nist.gov gives five such PRNGs.

Three of them are based on hash functions and two of them are based on block ciphers.


How to handle points in extended finite field

As you note, the elements of $\mathbf F_{p^2}$ can be represented as $a+bi$  with $a,b \in \mathbf F_p$ and $i^2 = -1$; however note that this only works if $p\equiv 3 \pmod 4$.

Then you can add and multiply two elements of $\mathbf F_{p^2}$ in basically the same way you add and multiply complex numbers. Namely, $(a+bi)+(c+di) = (a+c)+(b+d)i$ and $(a+bi)(c+di) = (ac-bd)+(ad+bc)i$.

And the formula for point addition is the same, but you need to keep in mind that all your "numbers" are elements of $\mathbf F_{p^2}$ and must be handled as above.


How to calculate a private key from public key on elliptic curve?

Yes your method is mathematically correct but it isn't feasible because of the size of the secret key $k$ that is used in practice.

Typically you are using curves over $\mathbb{F}_q$ where $\log_2 q \approx 256$. This means that there are $2^{256}$ possibilities for $k$ and, on average, it will take a very, very, very long time to find the correct one.

As a comparison, the Universe itself is estimated to be "only" $2^{58.5}$ seconds old. This means that even if you could try $1,000,000 \approx 2^{20}$ values of $k$ every second, it would take you $2^{255-20} = 2^{235}$ seconds to try half of the possible values. This amount of time is $2^{235-58.5} = 2^{176.5}$ times greater than the age of the Universe.


PKCS11: CKA_VALUE_LEN attribute and Unwrap key

Yes, I think that's sufficiently unclear to ask for clarification of the authors of the document, and it probably needs fixing.
However, what I do know is that the key size is definitely clear from the wrapped key itself. So there is definitely no need to specify CKA_VALUE_LEN during the call to C_UnwrapKey. There is no need to check it either; I'd be more worried about the value of the key then the size of the key if the key can be altered somehow.
What is possibly meant is that the key size of the wrapped key is determined using CKA_VALUE_LEN during key generation. Because in that case the type by itself doesn't specify the output length, i.e. the size of the key being unwrapped.


Why might SHA-384 throughput be lower than SHA-512 throughput in hashcat and more secure?

The only differences in calculations are the initial value and the output size. From NIST FIPS 180-4

The initial hash value, $H^{(0)}$, shall be set as specified in Sec. 5.3.4; and
The 384-bit message digest is obtained by truncating the final hash value  $H
^{(N)}$, to its left-most 384 bits:
$$H_0^{(N)} \mathbin\|H_1^{(N)} \mathbin\|H_2^{(N)} \mathbin\|H_3^{(N)} \mathbin\|H_4^{(N)} \mathbin\| H_5^{(N)}$$

When two source codes are compared inc_hash_sha384.cl and inc_hash_sha512.cl one can see that actually, SHA-384 does less job than SHA-512. It is not coded simply truncate the SHA-512 with different initial values. For the little speed difference, one explanation can be the vectorization that helps SHA-512 during the final calculations.
In the case of password protection, the tiny difference does not make much difference. In password hashing, actually, we use specially designed password mechanisms like PBKDF2 and Argon2 which was the winner of the password hashing competition.
In the security perspective, SHA384 has resistances to length extension attack but SHA512 doesn't have. SHA384 has 128-bit resistance against the length extension attacks since the attacker needs to guess the 128-bit to perform the attack. This is due to the truncation.
The different initial value provides domain separation. With domain separation  $$\operatorname{SHA384}(m) \neq \operatorname{SHA512}(m)|_{384}$$ where $|_{384}$ is the truncation.
In the case of pre-image, secondary pre-image, and collision resistance in generic attacks we have;
\begin{array}{|c|c|c|c|}\hline
& \text{pre-image resistance} & \text{2. pre-image resistance} & \text{collision resistance} \\\hline
\operatorname{SHA-384} & \mathcal{O}(2^{384}) & \mathcal{O}(2^{384}) & \mathcal{O}(2^{192}) \\\hline
\operatorname{SHA-512} & \mathcal{O}(2^{512}) & \mathcal{O}(2^{512}) & \mathcal{O}(2^{256}) \\\hline
\end{array}
The collision resistance is $\mathcal{O}(\sqrt{2^{n}}) = \mathcal{O}(2^{n/2}) $ due to the generic birthday attacks.
Therefore; SHA-512 is better in the case of pre-image, secondary pre-image, and collision resistance.  SHA-512's only weakness is that it is prone to length extension attacks.


Encrypt HDD with keyfile and password and allow backing up the keyfile with secret sharing

Is /dev/urandom fine for my use-case or should I use /dev/random?

Theoretically, there is no security difference as both are regarded to be cryptographically secure RNGs. Practically, you’ll want to use /dev/urandom as that is “non-blocking” since it re-uses it’s entropy-pool whenever it runs out of random data, while /dev/random may make your program “stall” if it runs out of entropy. Simpler said: /dev/random can be a bottleneck, /dev/urandom fixes the issue.

  Some people told me that I should use a key derivation function because otherwise, the effect of the password isn't spread. But do I need the effect of the password to be spread? The way I see it, cryptsetup will already use a key derivation function on my key to increase computation time and try to spread the effect of each bit.

I am not familiar with cryptsetup, and I don’t want to judge its internal workings by just taking a short glimpse at the related website… but if you’re sure it implements its own key derivation function (which I think it does as the site talks about using cryptsetup to generate dedicated key-files), it indeed wouldn’t make much sense to run that through another KDF after that. Yet, if you’re not sure if cryptsetup indeed provides a KDF (again: I am not 100% sure about that), or if you have any doubts about the quality of its KDF, I would certainly advise to opt-in for a dedicated KDF tool.

Oh, and one more thing – in case you don’t know about it…

  … I could use dm-crypt directly …

“Word on the street” has it that there are some weaknesses to watch out for when using dm-crypt. Meaning: whenever you’re thinking about dm-crypt, remember to choose your settings wisely.

(screenshot source)


ISAKMP 'master key' PFS (phase I) vs Ipsec session key PFS (Phase II)

So there is already PFS in phase I by design. Each time someone establishes a new IPsec VPN tunnel, a new DH shared secret g^xy will be used to compute SKEYID_d, right? Hence, the session key in phase II will also be unique. This is PFS right there?

No, you do not recompute a fresh SKEYID_d for every Quick Mode; instead, a value for SKEYID_d is assigned when the IKE Security Association is created (just like all the other SKEYID values), and is thereafter constant for the duration of the SA.

Hence, that wouldn't meet the definition of Perfect Forward Secrecy; the idea behind it is if the adversary captures the device (and learns everything it knows), he would not learn any previous keys (of course, he would learn any current keys).

In this case, the adversary would learn the value SKEYID_d; the IPsec keys are derived in IKEv1 from prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b).  If the attacker captures the device (and so learns the SKEYID_e value, and so is able to decrypt the IKE traffic), he learns the values of protocol, SPI, Ni_b and Nr_b (as they are all sent through the encrypted session).

So, if the PFS option is not used, the attacker can learn the IPsec keying material, and read all the traffic.  If the PFS option is (properly) used, then the attacker cannot learn g(qm)^xy, and so does not get the keying material.

I made these comments in the context of IKEv1; similar reasoning applies to IKEv2 (the current version of IKE)


Is there another resource for Carter-Wegman-style message authentication?

You didn't mention at what level you're hoping for, so I'll provide a few resources, and you can figure out which ones best meet your needs.

UMAC: Fast and secure message authentication. John Black, Shai Halevi, Hugo Krawczyk, Ted Krovetz and Phillip Rogaway, CRYPTO 1999.  (This research paper describes UMAC, a fast Carter-Wegman style hash.  It also gives a lot of good background on the topic.)
Wikipedia's entry on UMAC gives some background on universal hashing and its relevance to message authentication.
On fast and provably secure message authentication based on universal hashing, Victor Shoup, CRYPTO 1996.  (This research paper gives some of the theory behind universal hashing.  It might be a tough slog if you are not a theoretician.)
Stronger security bounds for Wegman-Carter-Shoup authenticators. Dan Bernstein, EUROCRYPT 2005. (Even more of the theory behind universal hashing.  An even tougher slog, if you are not used to theoretical crypto, but good stuff if you are.)
If you want to learn some of the crypto-theory, here are some resources:

You could start with Chapter 7 of Bellare and Rogaway's lecture notes on modern cryptography, which provides an introduction to message authentication from a theoretical perspective.  Read to the end of Section 7.4, then you can skip 7.5, 7.6, and 7.7, and jump straight to 7.8, which describes universal hashing -- but is unfortunately as yet incomplete.
You could read Katz and Lindell's Introduction to Modern Cryptography.  Start with Chapter 1, then Chapter 4 (particularly 4.1-4.4).  Unfortunately, while they have a good treatment of the theoretical foundations of message authentication, they don't cover universal hashing as a method of message authentication.

These days, Carter-Wegman-style message authentication is often mentioned under the name "universal hashing".  That search term may help you find a lot more.


Choosing $\lambda(n)$ rather than $\varphi(n)$ may result in a smaller private exponent.


Are tags longer than 128 bit possible for AES-256-CCM and AES-256-GCM?

No, there is no black-box type way of increasing the security strength of the tags of CCM and GCM. Because in this case you would apply a deterministic function which couldn't bring you any increases in security as a collision on the input would still lead to a collision on the output.

For CCM there is also no non-black box type of way, at least if you want to stick to AES. This is because CCM uses CMAC internally which is close to CBC-MAC which is CBC adapted for authentication. The authentication tag for CMAC is the result of an AES encryption and AES is solely specified for 128-bit blocks (which is the size of the AES in- and output).

GCM is similar in that respect to CCM, in that the output of the polynomial hash function is actually XOR encrypted with the output of an AES block. However if you pick a longer polynomial for GCM (which will instantly break all implementations you may have) and if you maybe make some educated changes to how often the polynomial gets evaluated, you might get a stronger tag as the result. However this would most-likely be a GCM look-a-like, but would needs its own (difficult) security analysis and new implementations.

On a final note, the tags of CCM,  GCM and HMAC are MACs. MACs are not neccesarily designed to be good hashes (for a fixed key), because the threat model is different for them. They are designed so that you can't find a tag for a message for which you haven't seen a tag before. They are absolutely allowed to output two different tags for the same message or the same tag for two different messages (because an adversary could maybe have predicted a collision but not for which message pair).


Construct a random permutation from a random function?

There are so many possible solutions here.  Without giving your requirements more carefully, it's just not possible to tell what would count as a valid solution.  Here are a bunch of schemes that offer better security than simply truncating to $N/2$ bits and applying 4 rounds of Luby-Rackoff:

For instance, one approach is to truncate the random function to $N/2$ bits, then use 6 or more rounds of the Luby-Rackoff construction.  Paterin has a paper at FSE 1998 that apparently proves that 6 rounds gives security for up to $O(2^{3N/8})$ chosen plaintext/ciphertext queries.  He also has a later paper at Crypto 2003 that apparently proves that 10 rounds is enough for security for up to $O(2^{N(1-\epsilon)/2})$ chosen plaintext/ciphertext queries.  Don't ask me to explain the proofs; I don't understand them.  I am not aware of any concrete-security versions of these results, so it's hard to know exactly how much security this gives you in practice.
Another approach is to truncate the random function to 1 bit of output (and $N-1$ input bits), then build a maximally unbalanced Feistel network that uses $4N$ rounds.  Naor and Reingold showed (Journal of Cryptology, Jan 1999) that this will give security for up to $O(2^{N/2})$ chosen plaintext/ciphertext queries.  (Technically speaking, their result assumed that you used a pairwise-independent permutation, then $2N$ rounds of unbalanced Feistel, than another pairwise-independent permutation, so if you really care about provable security, you could use that: but I suspect their results would likely apply to $4N$ rounds of unbalanced Feistel as well.)
Even better yet, if you do enough rounds of maximally unbalanced Feistel network, you can get arbitrarily close to $O(2^N)$ security.  Truncate the random function to one that takes $N-1$ input bits and has 1 output bit, and use it in an unbalanced Feistel network.  Morris, Rogaway, and Stegers proved at Crypto 2009 that, if you do $4RN$ rounds of this, you get security up to $O(2^{N(1-1/R)})$ chosen plaintext/ciphertext queries.  For instance, if you do $40N$ rounds, you get security up to something like $O(2^{0.9N})$ chosen plaintext/ciphertext queries.  That's a very impressive result.  If maximizing security is your goal, this might be your best bet.
Another approach is to truncate the random function to one on $N/2$ bits, then apply a suitable Benes network construction.  Aiello and Venkatesan proved in Eurocrypt 1996 that, with four rounds, this gives you security for up to $O(2^{N/2})$ chosen plaintext/ciphertext queries.

One keyword that may help you find still more results is "Luby-Rackoff beyond the birthday bound".


Is $\operatorname{negl}_1(n)-\operatorname{negl}_2(n) \leq \operatorname{negl}_3(n)$?

$\newcommand{\negl}{\operatorname{negl}}$
\begin{align}
\negl_1(n)-\negl_2(n)&\leq \left|\negl_1(n)-\negl_2(n)\right|\\
&\leq\left|\negl_1(n)+\negl_2(n)\right|\\
&=\negl_1(n)+\negl_2(n)\\
&\leq \negl_3(n)
\end{align}

where the last statement uses the fact that the sum of two negligible functions is negligible and the rest uses the fact that $\negl_1(n)\geq0$ and $\negl_2(n)\geq0$. For a proof of the last inequality, see this lecture on one-way functions and negligble functions (PDF).


Generating two secret keys from a physical analog signal: Crypto HASH analogous to time varying signal

There seem to be multiple problems you try and solve at once. Lets split the problem in at least two sub-problems:

First of all you want to have to extract entropy;
Then you want to create two keys using the entropy or random number generator.

Extracting the entropy

Extracting the entropy from the source involves whitening techniques. In case the amount of entropy is low you may want to use this entropy as input to a DRBG (deterministic random bit generator).

You may also want to include other entropy sources or identifiers, anything that may add randomness if you're using a DRBG.

Lets call the resulting bit string with $K_{master}$. $K_{master}$ does not have to be formatted as a key, it's just a bunch of bits that together hold a minimum amount of entropy.

Creating two separate keys

OK, so now you need two separate keys that are independent on each other. This is easier then you may think; you can simply use a KBKDF such as HKDF, which is based on a hash function: $K_1 = \operatorname{KBKDF}(K_{master}, \text{"1"}, l)$ and $K_2 = \operatorname{KBKDF}(K_{master}, \text{"2"}, l)$ (where $l$ is the amount of bits required for $K_1$ and $K_2$.

HKDF first explicitly extracts ("compresses") the entropy in the key to a fixed size output that depends on the hash algorithm used. It then expands this extracted information into enough key material for $K_1$ and $K_2$. Of course the strength is limited by the entropy in the input key material and the used hash function (however SHA-256 or higher should be enough for any normal usage).

You could include a device specific secret into the IKM by appending or prefixing it to the $K_{master}$ that you got from whitening your entropy source.

Most importantly, revealing either $K_1$ or $K_2$ to an attacker won't give the attacker any information on the other key or the input keying material (given it has enough entropy not to be brute forced).

This way you can focus on the best way to get entropy from your source. Try not to create any data that depend on other data as you seem to suggest.


How to get the same calculation result on an untrusted computer, while withholding some information?

The term you are looking for is homomorphic encryption. This allows you to evaluate a general circuit (so no branches) on encrypted data without knowing the decryption key.

It works in theory, but to my knowledge no practical applications have been developed yet. They are either incomplete (only allowing addition, XOR, or some other operation) or impractically slow (decrypting costs more time than the actual computation).


Re-encrypting a message and proving that the message has not changed

I  think this is not compatible with semantic security (IND-CPA). If such a proof exists,  an adversary that chooses $(m_0,m_1)$ and receives $c_b=E_1(m_b)$ may compute $E_2(m_0)$ and try to prove that $m_b=m_0$. If the proof is correct, then he guesses that $b=0$, else $b=1$. But may be there exist weaker security models that allow to test the equality of two plaintexts.
Your problem seems similar to plaintext checkable encryptions.


$ax^2+bx+c=0$ is the general expression of a quadratic equation in one variable. Here, there are more than one. You may want to look into how the degree of a multivariate polynomial is defined.


Is there an existing AEAD scheme with minimal IV requirements?

Sounds like you might be after deterministic authenticated encryption. Check out SIV mode. This mode doesn't use an IV at all (though it does generate one internally, outside of the attacker's control). Being deterministic, it leaks equality of (header, plaintext) pairs.

The basic idea is to put the (header, plaintext) pair through a PRF, such as HMAC, and use the result as an IV for, e.g., CTR mode. After decryption, you check authenticity by checking to see if you can reproduce the IV's value.

If you want to be able to stream plaintexts, look into "Online ciphers from Tweakable Blockciphers". As you anticipate, these schemes leak shared prefixes but are otherwise secure. But note that this latter paper does not consider authentication, and generic techniques that assume standard IND-CPA security may not work. See "On-Line Ciphers and the Hash-CBC Constructions" for how to get AE in this context.


ZK proof that two short solutions are equal

This paper Improved Zero-Knowledge Proofs of Knowledge for the ISIS Problem, and Applications is a good place to start researching. The paper appeared at PKC 2013 so have been peer-reviewed. In addition, there is an upcoming paper at CRYPTO 2016 which looks very related How to prove knowledge of small secrets.


Elliptic curve trapdoor function without modular arithmetic?

First, as poncho correctly noted in a comment, real-based values don't work well with computers, because they require an infinite series / sequence representation and handling infinite amounts of data with a finite amount of storage usually doesn't end well, especially if you don't want to give away structure like in this case.

Second, picking keys is hard if you consider infinite ranges (even if there's an infinite amount of numbers between any two numbers), because you can't sample from an infinite set uniformly at random (then every element would have probability 0 of being picked).

Third, real-numbers often allow for more structure than we'd like. Take for example the logarithm. Computing $\log_3 b$ is easy in $\mathbb R$ (we know efficient algorithms that will yield a solid approximation) whereas finding this over $\mathbb Z_p$ tends to be hard. The fear is that a similar property can be found for the elliptic curve discrete logarithm problem. Also most problems over $\mathbb R$ are a matter of finding a good enough approximation where you can use intermediate approximations and have helpful navigatory metrics and thelike, whereas with crypto you want "hit-or-miss" and no guidance in the right direction.


How is injective, inverse, surjective & oneway related to cryptography?

In mathematics these terms have very specific meanings. In cryptography these meanings do not really change, however the terms used to describe them have more specific meanings or examples.

One way function

A one way function is a function that processes the input in such a way that there is not an easy way to get back to to the input using only the output and knowledge of the function. When I say easy, I mean less than the expected security provided by the function to be practical, which may still be quite hard. It may take $2^{-10}$ seconds to compute, but require at least $2^{54}$ to "uncompute" using the same hardware.

For example, a cryptographic hash function is a one way function, and to get an input from an output, you can either brute force it, or try to attack the hash function and find a preimage, which may or may not match the input you are looking for.

Bijective function

A bijective function is one which is a 1 to 1 mapping of inputs to outputs. These would include block ciphers such as DES, AES, and Twofish, as well as standard cryptographic s-boxes with the same number of outputs as inputs, such as 8-bit in by 8-bit out like the one used in AES.

A bijective function is an injective surjective function. The codomain of a function is the set of possible outputs due to the size of the set. The image of a function is the subset of the codomain in which the output of the function may exist. In a bijective function, the image and the codomain are the same set.

Surjective function

A surjective function is one which has an image equal to its codomain, this means that if the set of inputs is larger than the set of outputs, there must be more inputs than outputs. These may include the general cryptographic hash functions.

In the case of SHA-1, we have $2^{160}$ possible outputs of a 160-bit function, but it is not proven that all outputs of SHA-1 are possible. Out of the real set of possible SHA-1 outputs, there are substantially more than $2^{160}$ possible inputs. Therefore SHA-1, IF computing all $2^{160}$ outputs for all possible inputs is possible, is a surjective function. If all outputs are not possible, it is not surjective.

Injective function

An injective function is kind of the opposite of a surjective function. Injective functions are one to one, even if the codomain is not the same size of the input.

An example of an injective function with a larger codomain than the image is an 8-bit by 32-bit s-box, such as the ones used in Blowfish (at least I think they are injective). These have 256 inputs, a codomain of $2^{32}$, and an image set size of 256.

Inverse Function

This is exactly like it sounds, the inverse of another function. This would be the decryption function to an encryption function. An inverse of a function may or may not have the same computational requirement as the forward function, and if keyed, may or may not use the same key. A keyed encryption algorithm that uses the same key for its inverse is a symmetric algorithm, whereas one that needs a different key is an asymmetric algorithm.

I would not consider an algorithm that returns multiple possible inputs of function $f()$ for a given output to be the inverse function of $f()$, but others may disagree. This would include hash function preimages, where the algorithm may continue processing and return multiple preimages, resulting in a set of possible inputs to $f()$ that generate the desired output. Only when the algorithm could return the entire set of preimages would I consider it the inverse.


What you want to do is establish a shared, authenticity guaranteeing channel assuming both sides know a fixed public key (either RSA or ECDH based) of each other.

Transport Layer Security (TLS) can do that and really should be used if possible, given that it also takes care of things like state management and replay-prevention for you. If you need a list of embedded-friendly TLS libraries have a look here and also note that TLS does offer cipher suites which only perform authentication and no encryption if the cost of encryption is unbearable to you (though many implementations don't actually have them).

Alternatively if TLS is really not an option and you have the replay-protection figured out, you can also just use RSA signatures (not to be confused with the integrity guarantees provided by RSA encryption!). This can be done either by using RSA-PSS (preferred these days) or by using RSA-PKCSv15 signatures, both of which are supported by LibTomCrypt (your currently preferred library) and guarantee that the signed message actually came from the owner of the associated public / private key and was not altered and can be verified just using the public key.

But now to the question you asked (but probably didn't mean to ask):

  There is a well defined scheme based on RSA to obtain a shared secret
  or the aforementioned goals?

The standard way to do this (and the way TLS does it) is that one side of the exchange picks a random number (e.g. 64 bytes long) and then encrypts it with the other side's public RSA key (and e.g. RSA-OAEP).

If you also want to ensure that the sender is actually who they claim to be, simply sign the resulting ciphertext and enforce signature-checking on the receiver-side.

  In addition to this how can I avoid reply attacks?

If there is a a relieable clock on the devices one could e.g. send nonce+timestamp pairs and clean nonces from the cache after e.g. an hour (assuming the nonces are covered in the signed data). Alternatively one could have the recipient send a fresh nonce and the next message must use that nonce so that only one nonce needs to be stored.

That means the first approach would mean this message format:

$$\text{Timestamp}\parallel \text{SenderNonce}\parallel M\parallel \operatorname{Sign}(\text{Timestamp}\parallel \text{FreshSenderChosenNonce}\parallel M)$$

and discard nonces from memory after one hour. Or alternatively

$$\text{ReceiverNonce}\parallel \text{SenderNonce}\parallel M\parallel \operatorname{Sign}(\text{ReceiverNonce}\parallel \text{SenderNonce}\parallel M)$$

where ReceiverNonce was transmitted as the nonce to be used on the next transmission from the receiver to the sender.


What is 'key agility' in relation to symmetric-key encryption?

Here's what I can say about the general meaning of it:

It means that the amount of preprocessing of a key is small. So the amount of time from generating/importing a new key to actually starting encrypting is neglegible.
It means that the amount of state a cipher uses is small. The state of a cipher generally is the key or preprocessed key schedule plus the actual block. If this is small it means that you can potentially fit many keys in the CPU cache.

Note that if you have either an extreme of 1 or 2 you can live with just one. If preprocessing takes a long time but the generated key schedule is small you can simply do it once and store it with the key. If preprocessing is very cheap but the state is very large you can do it on-the-fly.

To give an example of the key agility of my own cipher (broken link to pdf), here's why:

The key schedule only consists of permutations of the key - this means it's just memory loads and can be done on the fly.
The full state is only twice the block size - so 128 bytes.

As for why it's important, an example would be a busy HTTPS server. It has to handle many connections at once, and (if everything is done right) each connection has it's own associated keys. Being able to use many keys at once, and preferably to generate and use keys on the fly (ephemeral keys) is a huge bonus in performance and security.


Symmetric key as proof of ownership of a session?

Because all requests are encrypted with the session key, can that act as a form of proof that the client is the real owner of the session ID? e.g. If the session ID somehow is stolen, it can still not be used to communicate to the backend as you still would need to have ownership over the shared secret.

That depends. I don't see any explicit check for this defined. I also don't see any specific mention of defusing replay attacks (in both ways, as there is only one encryption key, it seems). Also, 32 bit isn't much to avoid either integer overruns or collisions, so an attacker with another valid TLS key may retry until such an ID is created.

How much added security does this setup give if for some reason the TLS connection is broken into? (e.g. due to MITM, or because the TLS-level encryption is broken)

None, as you don't perform any authentication of or after the key exchange.

Does this setup aid in API obfuscation? E.g. client-side you can install software that - prior to TLS encryption occurring - can inspect all incoming and outgoing traffic. For my application, they would only see requests that are already encrypted. Is it easy to work around this?

No, it won't aid in API obfuscation, and yes, it is easy to work around this because of 2. And if you have an unencrypted part then an attacker can do an MITM there.
Better to just rely on TLS.


How is a fake private key used in CloudHSM?

While we ( / I) don't know exactly what the fake private key is, there are two sensible (standard?) guesses we can make here. For a confirmation we probably would need access to the CloudHSM OpenSSL engine implementation.

So first, why do we need a fake private key at all? Well, we need a way to tell the system (a.k.a. AWS' HSMs) about which key we are talking and OpenSSL doesn't support identifiers or handles natively with the CLI interface, so we need a work-around and these fake private keys are exactly that. They are means to designate specific keys within the HSMs.

So what do these files actually contain? There are two sensible options:

They contain a handle, that is an identifier. This means that they essentially just contain a string which says "if you see me, use key X on HSM-cluster Y", but they don't actually contain the private key.
They contain the encrypted private key. This means that the HSMs would (symmetrically?) encrypt the private key and put it in this file, so they don't have to keep it in their own storage. This may be accompanied with an identifier for the symmetric key, similar to (1). Also this would mean that deleting the key is as simple as deleting all copies of the fake private key and no interaction with the HSMs for key deletion is required.


What is keyId in Signal Protocol JavaScript library?

Usually you use these identifiers only for permanent storage. Those keys you will have to look up again, and normally you'd do that using a unique identifier (e.g. a label). Those are generally not random, and if they are random, then they should be 128 bits or higher to avoid collisions (i.e. two keys possibly sharing the same number).
After some advanced Internet searching, I found the following tidbit:

After the account is created, the user can upload the keys to the server. The identity_key and public_keys are both Curve25519 Base64 encoded public keys with a size of 33 bytes. A client will publish 100 pre-keys when registering, see figure 4.2, however, this is not a restriction. Along with these keys, a signed pre-key will be sent with a signature over the public_key. The key_id is an identifier of 3 bytes.

After that there is a code example that clearly shows it is a 24 bit sequential number, presumably unsigned, so you can supply it a non-random number [0, 2^24).


To capture value/position relations, a "sequence polynomial representation" was suggested, in the context of proving properties of DNA. Self-citing: IACR preprint 2008/357. This technique could apply here in case of ElGamal ciphertext, that could be proven with Schnorr-like responses. The major idea remains to re-state "consecutive" as a property of "characteristic polynomial", that (I believe) is doable. Hamiltonicity test (2008/363) could be another example.


DES security if used a SHA3 function instead of Normal DES function?

The question as initially asked essentially considers a 64-bit symmetric Feistel cipher with 16 rounds, a large (128-bit) key, a near-ideal round function, but the same function and key at each round. A slide attack allows at least a distinguisher, I think with in the order of $2^{31}$ queries to an encryption oracle. With some more, it might be possible to construct plaintext/ciphertext pairs that where not queried. This is an interesting exercise. That makes the security lower than that of DES from several standpoints.
If there is a good key schedule (e.g. if the round counter is appended to the input of the hash), then we are back to a Feistel network, which given the block size and ample rounds is extremely secure. I very much doubt there's an attack better than brute force of the 128-bit key. Security is way above that of DES (but performance in native code is much lower).
With a key schedule based on rotation as in comment, things depend on the rotation count. But if it's by an odd number of bits, nothing disastrous will happen for overwhelmingly most key values.
If there was a security difference between SHA-2 and SHA-3, that would imply a break of one of these (against a random oracle model for constant input length). On top of that it would be with the attacked hash embedded in a setup extremely hostile to attacks. I discount that.


Are there any "cumulative signatures" for decentralized networks?

You can have a look at Collective Signatures for example, which is, in a nutshell, the addition of multiple schnorr signatures resulting into a unique aggregated signature. The verifier needs to know only of one public key in order to verify such as signature, which is the aggregate public key of all participants.
Have a look also at MuSig for a more recent work applying this concept for Bitcoin with a twist.

Here it is important to note that you did not specify you threat model. If you assume all participants are present and honest during the signature generation, everything is so easy. When you start introducing some malicious adversaries, then things will get a bit more messy ;)


How resistant are stream ciphers like Salsa20 or ChaCha in a post-quantum world?

There is no known quantum attack better than the generic Grover attack on Salsa20 and ChaCha, which is inconsequential because it would take $2^{128}$ sequential steps.  Even if parallelized $p$ ways to run in marginally less time, a factor of $\sqrt p$ improvement, it would cost more, also by a factor of $\sqrt p$, than the cost to run a quantum computer for $2^{128}$ steps.  Even if you were satisfied with breaking the first of $t$ targets for $t \ll p$, you would get only a $\sqrt[4] t$ cost reduction in the best known multi-target attack.

The same is true for AES key recovery, SHA-256 preimage search, etc.  More on quantum attacks on various kinds of hash functions.


State of the art techniques for Anonymous Authentication?

Take a look at the ECDAA protocols. They are implemented in the Trusted Platform Module (TPM 2.0). ECDAA is based on pairings over elliptic curves. In contrast to Idemix, they have the benefit of being far more efficient. In contrast to U-Prove, they have the benefit to be multi-show unlinkable.


What is the relationship between entropy conditioning and final output bias in a TRNG?

The notation is a little confusing because it uses the same letter $n$ for two purposes, so let's change it to be a bit clearer:

  An entropy source output string containing $2t$ bits of entropy can be conditioned into a string of $t$ bits that contains full entropy output using an approved conditioning function, where $t$ is the length of the output block of the approved derivation function (see SP 800-90B).

(Replaced $n$ by $t$.)

In other words, if we have a physical device that produces a string $\sigma$ with $2t$ bits of entropy, which is necessarily at least $2t$ bits long, and we can pick a conditioning function $C\colon \{0,1\}^* \to \{0,1\}^t$, then the string $C(\sigma)$ is $t$ bits long and has nearly $t$ bits of entropy—in particular, $(1 - \varepsilon) t$, where $\varepsilon < 2^{-64}$.

This is a statement of an assumption (in §4.2 ‘Assumptions’) about the entropy source, having at least $2t$ bits of entropy where $t$ is the length of the output block.

  The derivation functions in SP 800-90A distribute the entropy provided by the input string is $n$ bits (so that the length of the input string is $r$ bits for some $r \geq n$), and the length of the output string is $t$ bits, then the following is true:

  If $t \leq n/2$, then the output string has full entropy output (i.e., the output string has $(1 - \varepsilon) t$ bits of entropy, for some $\varepsilon \leq 2^{-64}$).

($t$ is the same as above now.)

In other words, if we have a string $\sigma$ with $n$ bits of entropy, which is necessarily at least $n$ bits long ($r \geq n$), then for any choice of derivation function $C\colon \{0,1\}^* \to \{0,1\}^t$ in SP 800-90A with $t \leq n/2$, the $t$-bit string $C(\sigma)$ has nearly $t$ bits of entropy—in particular, $(1 - \varepsilon) t$, where $\varepsilon < 2^{-64}$.

This is a statement of an assumption about the derivation function, like Hash_df, used as a conditioning function.  An example of a function that would fail to satisfy this property is one that, say, just gives the first $t$ bits of the input string.

Why should these relations hold?  See an earlier answer for some details.  The quick summary is that a rough approximation for expected entropy of the output $F(\sigma)$ of a uniform random function $F\colon \{0,1\}^* \to \{0,1\}^t$ on a string $\sigma$ with $t + k$ bits of entropy is $\lg 2^t (1 - e^{-2^k}) = t + \lg (1 - e^{-2^k}) \approx t - e^{-2^k}/\log 2$, so as long as $k$ is reasonably large we easily attain ‘full entropy’ in this model with $\varepsilon \approx e^{-2^k}/(t\log 2)$.

Picking $k \geq 64$ is plenty—and we are required to do that because the block size of every approved derivation function is at least 64.  We don't have a uniform random function in the real world, but the derivation functions of SP 800-90A don't seem to have any interesting properties that let us distinguish them from one, so it's a pretty good model.

What if you chose a string $\sigma$ with $n = 256$ bits of entropy, and a 3DES-based derivation function with an output block of $t = 64 = n/4$ bits?  Then $k = 192$, so $\varepsilon$ is really quite tiny, and we get ‘full entropy’ in a 64-bit string—although that's only just under 64 bits of entropy.

What if you chose a string $\sigma$ with $n = 130$ bits of entropy, and an AES-based derivation function with an output block of $t = 128$ bits?  The margin is smaller in this case: since $k = 2$, the approximation above (a) is not a very good approximation and (b) gives an $\varepsilon$ nowhere near $2^{-64}$.  Maybe we get more than 64 bits of entropy in the end, but that's not ‘full entropy’ for a 128-bit string.

At what $k$ do we draw the line?  To give a comfortable margin without having to think hard about it, we just say that you should use twice as much the entropy in the input as the ${\geq}64$-bit output is long, in order to reliably get ‘full entropy’ in the output.


Yes, you are correct. For padding - there's no way to fix it at step 5, you need to make correct padding at step 1.


There is OpenBSD, where you can use S/KEY for login-purposes.

Check the OpenBSD – Frequently Asked Questions:

  8.10 - S/Key

  S/Key is a ``one-time password'' authentication system. It can be useful for people who don't have the ability to use an encrypted channel which protects their authentication credentials in transit, as can be established using ssh(1).

  WARNING: One-time password systems only protect authentication information. They do not prevent network eavesdroppers from gaining access to private information. Furthermore, if you are accessing a secure system A, it is recommended that you do this from another trusted system B, to ensure nobody is gaining access to system A by logging your keystrokes or by capturing and/or forging input and output on your terminal devices.

  The S/Key system generates a sequence of one-time (single use) passwords from a user's secret passphrase along with a challenge received from the server, by means of a secure hash function. The system is only secure if the secret passphrase is never transferred over the network. Therefore initializing or changing your secret passphrase MUST be done over a secure channel, such as ssh(1) or the console.

  OpenBSD's S/Key implementation can use a variety of algorithms as the one-way hash function. The following algorithms are available:

  md4
  md5
  sha1
  rmd160.

  …


need to develop CSPRNG. can i use ANSI X9.31 generator

Yes, you can use any generator from NIST SP 800-90A rev.1 (PDF) as SEJPM indicated in the initial comment above.

Adding entropy is called seeding a random number generator. Seeding a PRNG with just date/time is sinful at best. Using a nano-second precision clock is only somewhat better; generally anybody can guess the value of the time so date / time itself is not random enough for secure random number generators.

Yes, you can seed using /dev/urandom which itself is a PRNG, seeded by the operating system. You could also use /dev/random (without the u) to retrieve a seed more directly from the entropy pool of the operating system. However, using /dev/random may cause performance issues and /dev/random may block as well. In general using /dev/urandom should be preferred.

If you use at least 128 bits of randomness from the /dev/urandom then your qualified PRNG should be at least as secure as using /dev/urandom directly. The security of /dev/urandom of course relies on the implementation, configuration and indeed the quality of the entropy it relies on. You may also seed the date / time in addition to the 128 bits of entropy, but date / time brings so little benefit that you might as well skip that part.


One would certainly hope not; if he can, then we would consider the encryption method "broken".

One of the things we expect from any encryption method is the resistance to a "known plaintext attack" (of which your question is an example); that is, even if he is given a number of plaintext/ciphertext pairs, he still is unable to decrypt another ciphertext that is encrypted with the same key.

Actually, we go father than that; we also ask encryption methods to be resistant to "chosen plaintext attacks"; that is, even if the attacker can ask that messages of his choosing be encrypted (and he then gets the resulting ciphertext), he still is unable to decrypt a target ciphertext.


Using the a multiple of the x coordinate as a private key

What if the private key instead is set to the x-coordinate of the EC
  point $r\cdot G$

Then your "private" key is the x-coordinate of your public key and thus public, unless you also want to redefine how the public key is constructed.

Additionally, the idea of ECDSA / Schnorr signatures is to prove knowledge of a solution to the discrete logarithm problem at the example of a message hash and if your private key is the x-coordinate of a point, you don't know said discrete logarithm and thus also need to come up with a new signature scheme.


Proof by reduction for for digital signature scheme $S_2((sk_0,sk_1), m):=(S(sk_0,m), S(sk_1,m))$

So this is a solution I came up with based on this chat with @Maeher.
We use proof by reduction to show if there exists an attacker $A$ with non-negligible advantage for $S_2$ we can use it to construct an attacker $B$ for $S$ with non-negligible advantage. If
$$\Pr[vrfy(pk_0,m,\sigma_0)  \;\; and \;\; vrfy(pk_1,m,\sigma_1)]$$
be non-negligible then easily we can construct $B$ to give us a forgery for $S$. So we assume this probability is negligible and without loss of generality assumes the above probability is equal to $0$. now suppose the non-negligible advantage of $A$ is
$$ adv2 = \Pr[vrfy(pk_0,m,\sigma_0)] + \Pr[vrfy(pk_1,m,\sigma_1)] = p_0 + p_1 $$.
attacker $B$ take as input public key $pk$ and call $Gen$ algorithm to have $(pk_1,sk_1) ,( pk_0,sk_0) $ then it uniformly choose bit $b$ form $\{0,1\}$ and pass $(pk,pk_b)$ to the $A$. then $A$ return $(m,(\sigma,\sigma_b))$ and $B$ choose $(m,\sigma)$
as it's forgery. advantage of $B$ will be equal to $adv$ which
$$adv \geq \frac{1}{2}(adv2 - p_0) + \frac{1}{2}(adv2 - p_1) = \frac{1}{2} adv2 $$
so $adv$ is non-negligible.


Is there any implementation of scrypt that allows a specific limit on memory?

Deﬁnition 4: The key derivation function scrypt is deﬁned as
  scrypt(P, S, N, r, p, dkLen) = MFcryptHMAC SHA256,SMixr(P, S, N, p, dkLen)

  The limits on the size of p and dkLen exist as a result of a corresponding limit on the length of key produced by PBKDF.

  Users of scrypt can tune the parameters N, r, and p according to the amount
  of memory and computing power available, the latency-bandwidth product of the
  memory subsystem, and the amount of parallelism desired; at the current time,
  taking r = 8 and p = 1 appears to yield good results, but as memory latency
  and CPU parallelism increase it is likely that the optimum values for both r and
  p will increase. Note also that since the computations of SMix are independent, a
  large value of p can be used to increase the computational cost of scrypt without
  increasing the memory usage; so we can expect scrypt to remain useful even if the
  growth rates of CPU power and memory capacity diverge.

Source.

This SO answer elaborates on the factors more clearly.

  $N$: General work factor, iteration count.
  $r$: blocksize in use for underlying hash; fine-tunes the relative memory-cost.
  $p$: parallelization factor; fine-tunes the relative cpu-cost.

Source.

If you want to increase memory hardness, raise r. This will also raise execution time, so you might want to lower N at the same time.


There are many types of weak keys, some of them make it vulnerable to chosen plaintext attack, some of them may leak some statistical properties through the plaintext, some keys generate same subkeys for multiple rounds of an algorithm etc. See https://en.wikipedia.org/wiki/Weak_key .

Keys are usualy generated randomly. The randomness is tightly connected with unpredicability, which is of course very desired property of key generation. It would be probably rather hard (and error-prone) to skip all the weak keys. (The hardness, however, depends on the algorithm.) Just identifying the weak keys and restarting the key generation is probably much simpler. Since there are usually few weak keys, it is usually rare to generate one and probability of repeated random choosing a weak key is negligible, so it is very improbable to get stuck for a long time in a loop because of weak keys.


Using public-key signature instead of having API key

Using public key cryptography instead of a long-term shared secret is slightly more complicated but has major advantages. One of them being that the server doesn't learn the secret key. This protects against accidental leaks, but also insider threats.

If this is an option, you can use client TLS certificates. Most HTTP client libraries support this, but web server often have limited support for this. Namely, they support ACLs based on the presence (or not) of a certificate, but that's pretty much all they do. And it's not always possible to retrieve client information from web applications.

The scheme you describe (the server sends something that the client has to sign) works. However, you shouldn't use a time stamp, which would be vulnerable to replay attacks, but a nonce.


Proofs that NM-CPA implies IND-Cpa and $\text{IND-CCA} \leftrightarrow \text{NM-CCA}$

This paper, AFAICT: https://www.cs.ucdavis.edu/~rogaway/papers/relations.pdf
It is about the security of public-key encryption, but the proofs about the relations between security definitions are applicable to symmetric encryption.


The format is not an official standard, but it is pretty straight forward. There are indeed 4 fields, in order $p$, $q$, $d$ and $u$ (I'm not quite sure what the function of the $u$ is?, it's not the CRT representation that is common in standards).

First decode the base64: it starts with 0x04 0x00 0x8b 0x91 0xff 0x6a 0x8f 0x5c..

Every number is encoded as a big-endian 2 byte number that denotes the number of bits
(So here 0x400 = 1024), so we then know the number of bytes (so here 0x80 bytes) that then follows and this is just a bigendian number ($p$). After these bytes we get the second length field (0x400 again) followed by 0x80 bytes (for $q$), a length 0x7fe = 2046 bits so 0x100 bytes that encode $d$ (it makes sense that this should be roughly twice the number of bits of $p$ and $q$, as it is of order $(p-1)(q-1)$) and the last $u$ is again 0x400 = 1024 bits, and after this number we get 0x2d = '-' characters as padding.

Normally these private keys are ASN.1-encoded (e.g. PEM format), and Microsoft has its own format in Windows, etc. Many such encodings are just a decorated version of the length followed by data of that length format, so this is pretty easy to figure out.

Take a bignum library (I use GMP, normally) and try to convert the bytes to numbers and check primality etc etc. to try to verify this.


Is there a cryptographic solution for this “dating protocol”?

You can use a protocol solving the Socialist millionaires problem for this. Socialist millionaires compares two integers for equality. There are relatively simple implementations of this protocol, similar to Diffie-Hellman, which are used to implement PAKE (password authenticated key-exchange).

Agree a fixed integer to denote true. A party chooses that value if they want to signal true and a random other value (say 256-bits) if they want to signal false. This clearly works for the case where at least one party chooses true. If both parties choose false it will almost certainly produce a not-equal result from SM, since the chance of two random values being equal is negligible.

Thus you can securely implement the AND function using a Socialist millionaires protocol.


Secret Sharing Scheme, with joining players, no central entity

This is a classic problem that can be solved with secure multiparty computation. When a new player joins, the $K$ parties who approve them joining run a secure computation protocol to generate their share. Concretely, if Shamir sharing is used, then the function computed is "reconstruct the polynomial $p$ from the $K$ shares input, and output the share $p(\alpha_{N+1})$, where $\alpha_1,\ldots,\alpha_{N+1}$ are field elements and $\alpha_i$ is associated with party $P_i$.


Schnorr Identification Scheme under active adversary

It is important to consider the model in which security is proved. In this case, the attack proceeds in two phases: first a phase where the adversary as a verifier interacts with the honest prover, then a phase where the adversary as a prover interacts with an honest verifier. The adversary wins if the honest prover accepts. The paper proves, under reasonable assumptions, that the adversary cannot win in this model.

However (see the comment at the end of Section 2), this model is very restricted and not so useful. In more useful models where the adversary interacts with the honest prover and the honest verifier at the same time, the Schnorr identification protocol is absolutely hopeless, which isn't surprising since it wasn't designed with those models in mind.


For an encryption scheme to satisfy the standard notion of security (IND-CPA), its encryption algorithm must be randomised. Therefore $\textsf{Encrypt}$ has access to random coins, denoted here by $\theta$. It is usually implicit in the syntax of $\textsf{Encrypt}$
$$c\leftarrow\textsf{Encrypt}(pk,m),$$ but it can be made explicit as
$$c=\textsf{Encrypt}(pk,m;\theta).$$
For example, the encryption algorithm in El Gamal (which is IND-CPA secure under the DDH assumption) with public key $pk=(G,g,h,q)$ and message $m\in G$ can be described as
$$(c_1=g^r,c_2=h^r\cdot m)=\mathsf{Encrypt}(pk,m;\theta),$$
where the random coin $\theta$ (interpreted as a string) is used to sample $r\in[1,q-1]$.


Active S-boxes for AES with 8x8 MDS matrix

It seems that using an 8x8 MDS will have 27 Active Sboxes after 4 Rounds(There may exist a trail shorter than 27). The image below shows the counting of active Sboxes.

The Active and non-Active byte is shown as 1 and 0 respectively.
The 8 bytes of state which become input to the 8x8 MDS matrix are
colored in similar color (pink or blue).
The shift rows step shows new byte position in pink and white color.
The calculation is done under the assumption that 8x8 MDS matrix has
optimal branch number of 9 i.e change in one byte will change all
the 8 output bytes.
If 8x8 Matrix similar to Camellia is used which
has branch number of 5, then count of active Sbox may be reduced.


How to backup a secret encrypted by multi parties without revealing the secret?

If the goal is to store the secret on two servers and Alice so that, if Alice had access to both servers, you can recover the secret, but neither server by itself could (even if you could recover Alice's stored value).

If so, this problem is essentially secret sharing.  In this case, it can be done fairly easily:

Alice generates two random strings $P, Q$ as long as the secret $S$
Alice gives the value $P$ to server 1
Alice gives the value $Q$ to server 2
Alice stores the value $P \oplus Q \oplus S$ (that is, the strings $P$, $Q$ and $S$ exclusive-or'ed together) in her storage

It should be obvious that neither server (even with Alice's stored value) can recover the secret $S$; however if Alice can recover the secret if she has access to both.

And, secret sharing can do more than that (using somewhat more sophisticated mechanisms); Alice can share her secret among 5 servers, so that if she has access to any 3 (perhaps two of them crashed), then she could still recover the secret (but all the server's without Alice's stored value could).


The real-life meaning of proving over a group that doesn't support the oracle?

One might imagine that the object of a security proof is to know that if someone breaks your system, that means they have (essentially) found a way to do some computation that you couldn't do before. Sort of a consolation prize.

However, it is better to consider it as a statement of beliefs and consequences of those beliefs. We believe factoring is hard. If a practical attacker against a cryptosystem leads to easy factoring, we must believe that such a practical attacker cannot exist. We must believe that our cryptosystem is secure.

And from this point of view Gap Diffie-Hellman makes sense. We do not believe that CDH reduces to DDH, ergo we must also believe that cryptosystems based on GDH are sound.


What happens if I remove client certificate from TLS

As SEJPM already has indicated, if you loose the client certificates the server loses client authentication and thus all the data authenticity and even confidentiality under active (man-in -the-middle) attacks.

On the internet this is usually not a big problem for e-commerce. The client can still authenticate the server and have a secure connection. The server doesn't care too much - it simply authenticates the payment transaction.

On the other hand, for e.g. B2B connections the lack of authentication on one side can be catastrophic.

Note: the client certificates is required for client authentication. If you leave it out you'll end up with regular server authenticated TLS.


LFSR as such isn't a CSPRNG. There are diverse CSPRNGs, see crypto textbooks, also A. Menezes et al., Handbook of Applied Cryptography (freely available online). I have a code for a CSPRNG based on RSA, see Ex. 5 in s13.zetaboards.com/Crypto/topic/7234475/1/


When extending the domain of a fixed-length MAC, why do we have to include the message length in each block?

I suspect it is because you can still do a truncation attack under specific circumstances. Say an adversary obtains the tag of another message m' that is shorter than the original message m. Then the adversary can replace the first block from m (the one containing the length) with the first block from m', and also replace the first element in the tag for m with the first element from the tag for m'.

Similary, if the message m' is larger, then a message extension attack becomes possible...


Paillier's Cryptosystem - Secure Key Size

You should be using a 2048-bit modulus, as with RSA. Personally I feel comfortable with 1536, but 2048 is considered the minimum standard.


GOST R 34.11-2012 hash function works from the end, is this convenient in practice?

I understand, that this approach is more secure and eliminate length extension attack

Actually, just be processing the blocks backwards doesn't actually eliminate any attacks.  Instead of 'length extension' attacks, we have 'prepend attacks' (where we add the extra blocks to the beginning rather than the end), which yield the same vulnerability.

Now, this 'prepend attack' does not appear to apply to the GOST hash function, but that's because they perform some final block processing involving g_0 (which is distinct from their hash compression function g_N in that they don't xor in the bit counter).  However, this defense has nothing to do with the order of processing blocks.

  but it is very unpractical.

Depends on their use case; if they always have the message in front of them in memory, it would appear to work just fine.

However, they don't appear to gain anything from making the hash function not computable online (which is the term for the property you're asking about); I have no idea why they did so...


There exist methods which allow to switch between a multiplicatively homomorphic encryption scheme - such as ElGamal - and an additively homomorphic encryption scheme - such as Paillier. By switch, I mean securely converting an encryption of a plaintext under one scheme into an encryption of the same plaintext under the other scheme. This is precisely what we described in this paper (see also the follow up). In these works, no proxy knows the full secret key of either scheme: the server and the proxy only have to know shares of the private keys of the scheme (hence, neither the server nor the proxy can decrypt any ciphertext alone).
Several important remarks, however:

In your question, you seem to completely ignore one of the most crucial aspects: the additive and multiplicative schemes must be compatible, in the sense that they must (essentially) operate over the same structure. By default, RSA is multiplicative over $\mathbb{Z}_n^*$ and Paillier is additive over $\mathbb{Z}_n$. These rings do not even have the same order, and this is extremely problematic - it can be easily used by an attacker to completely destroy security. Solving this issue is actually one of the main hard steps in our paper.
RSA is not secure for your application. It is only one-way; you cannot hide a money amount with a one-way scheme, since there are not so many possible values. An attacker could try to encrypt all possible amounts to learn which one was encrypted.
Is "tax" supposed to remain secret? I do not see why it should be a secret value in your application, since tax is typically public. If tax is public, you do not need any multiplicative scheme whatsoever: Paillier already allows to compute operations of the form $\sum_i \alpha_i \cdot m_i$ given encrypted plaintexts $m_i$ and arbitrary public coefficients $\alpha_i$.
In any case, if you need to do a single multiplication (or several "single multiplications" in parallel), like $\sum_i \alpha_i \cdot m_i$ (and not e.g. $\prod_{i=1}^n m_i$ for a large $n$), I would advise against using any technique for switching between encryption schemes. It will considerably complexify the construction, make it very hard to analyze and error prone, and it seems completely unnecessary. There are secure two-party protocols to securely compute, given Paillier encryptions of $x$ and $y$ respectively, a Paillier encryption of $x\cdot y$, where the two parties have shares of the secret Paillier ket (i.e. no one holds the full key). Roughly, it goes as follows: Alice picks a random mask $r$ and computes $E(x+r)$ ($E$ is Paillier encryption), the parties jointly decrypt such that Bob gets the plaintext $x+r$, and computes $E(y\cdot (x+r))$ from $x+r$ and $E(y)$. Bob sends back this ciphertext to Alice, who can herself compute $E(y\cdot r)$ (since she has $r$), and homomorphically substract the ciphertexts, getting $E(x\cdot y)$. This is a simple standard protocol to interactively multiply Paillier encrypted values.


The last 2 numbers are the ecdsa signature, it is two unsigned integers, when the highest byte happens to be larger than 127, the asn.1 BER encoding adds an extra zero.


There's no cryptographic way to keep users from faking their location without trusted hardware. There's also no good way to keep users from running multiple copies of whatever algorithm verifies a location guess in parallel, again without trusted hardware.

The best that can be done for an offline system is to make the is_coordinate_close() function expensive to compute. Still a user can then either bring a powerful portable computer or connect to remote computing capacity to brute force the data set you provide. Additionally, increasing the cost of the function increases the power consumption of your app.

There are two options that get rid of this tradeoff:

cryptographic secrets at the locations (EG:QR codes)
DRM capable hardware (Phone as trusted third party)


Answering question 1:
I see the following flaws in your model:

flaw 1: Any currently known data storage device is prone to accrue errors and data degradation no matter what you do. They also have an expected lifetime, with a different failure rate. USB devices have less durability (on average) than hard-drives, for instance. This means that you may lose both drives at the same time, and probability for this to happen increases dramatically over time, no matter how good you conserve the drives.

Solution:
replace unreliable USB technology with hard drives or tape, which are more appropriate for long term storage (although they also are not invulnerable).

flaw 2: Having only two devices means that you will have a RAID-1 equivalent. With that approach, if you lose a drive, you need to replace it and resilver from the surviving one. That puts a lot of stress on the surviving drive, and in case of failure during the process, you lose data.

Solution: You need to add more drives to reduce the probability to have a single source of data.

flaw 3: Copying the data on a yearly basis means that any silently corrupted data in drive A will be copied into drive B, so you are unwitingly damaging your data.

Solution: Use a hashing tool like ‘hashdeep’ to bulk create checksums of your files in both drives, and use a comparisson script to check and compare both drives individually on a regular basis. Your full-checksum-test will evaluate any damaged data in a drive and you can copy and replace from the other drive.

flaw 4: If you use a single large file as container with VeraCrypt, the above flaw 3 is harder to resolve. A failure in a portion of your large container file means you will need to fully resilver the entire dataset.

Solution: You may prefer to use LUKS encryption, or file based encryption like gpg for your full dataset, so that the 'hashdeep' process is executed over individual data files and isolate errors won't affect the full encrypted container. This way you can individually isolate damages and replace files from any of the surviving disks after your regular (monthly or yearly) full-checksum.
As a side note, for that long storage time, a separate set of replicas in RAID1 in a remote location is convenient. Also mixing drive technologies so that you don't hit a controller bug that will affect all your drives.
Answering question 2:
Nobody can for sure ensure you 100% that any current encryption algorithm or its implementations is free of bugs, flaws or vulnerabilities. Considering that long time, your best option is always to mitigate the physical access to the drives, on top of the encryption applied, keeping them stored safely in locations where you and only you will be able to access them during this time.
Obviously your threat model must be studied further depending on whether you are storing only personal love letters to be protected from ex-girlfriends or whether you are storing valuable trade secrets that a Court may seize.
Good luck.


If you have or just want to have just the email address for authentication then you could store a password hash as value in the public JS file. You could for instance use PBKDF2 with salt and relatively high iteration value. Basically, if you do that, you treat the email address as a passphrase.

However, please keep in mind that an email address is really easy to guess, and therefore an adversary could just try email addresses and try to get to the same hash in an offline attack. It's unlikely that the iteration count / work factor will be a prohibitive measure. However, your friends could use a complex mail address if they would wish (e.g. Google allows to use address+something@google.com as alias for address@google.com) and be more secure.

MD5 - or any other cryptographically secure hash - is not secure for password hashing by itself.

Another issue is that adversary can change the code in the client and skip any verification that takes place in there. So your security should at least be partially implemented at a different place than the page anyway.
Generally you'd try and secure your system starting at the server. For that however you do need code execution on the server. If the server can e.g. store the hash, and limit the amount of tries, then you're already much more secure.

If the system is for sending messages then you could also put some verification / security at the receiver of the messages if the server is unavailable to you.


You might consider using TEA or its successor, XTEA.  Here's the complete C source code for XTEA, taken from the Wikipedia article:

#include <stdint.h>

/* take 64 bits of data in v[0] and v[1] and 128 bits of key[0] - key[3] */

void encipher(unsigned int num_rounds, uint32_t v[2], uint32_t const key[4]) {
    unsigned int i;
    uint32_t v0=v[0], v1=v[1], sum=0, delta=0x9E3779B9;
    for (i=0; i < num_rounds; i++) {
        v0 += (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + key[sum & 3]);
        sum += delta;
        v1 += (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + key[(sum>>11) & 3]);
    }
    v[0]=v0; v[1]=v1;
}

void decipher(unsigned int num_rounds, uint32_t v[2], uint32_t const key[4]) {
    unsigned int i;
    uint32_t v0=v[0], v1=v[1], delta=0x9E3779B9, sum=delta*num_rounds;
    for (i=0; i < num_rounds; i++) {
        v1 -= (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + key[(sum>>11) & 3]);
        sum -= delta;
        v0 -= (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + key[sum & 3]);
    }
    v[0]=v0; v[1]=v1;
}

This code is simple enough that your students should be able to easily integrate it into their programs, and even modify it if necessary.  You might even want to consider reusing it for other exercises, too.  Notably, it also involves no special pre-processing of the key — the "key schedule", such as it is, is very simple and done directly within the encryption loop.

One feature of (X)TEA that (while generally a good thing) may not be ideal for your purposes is that it has a 128-bit keyspace, which is too large for a practical brute force search.  For your exercise, you could artificially restrict the keyspace to just, say, 32 bits by setting the remaining 96 bits of the key to some fixed value.  Then compositing two such encryptions with different keys should give you a 64-bit keyspace, which is still rather large to just exhaustively search by brute force, whereas the meet-in-the-middle attack needs only up to 233 operations, which should be easily doable.

By the way, the general property you're asking for is called key agility.  You may find other suitable ciphers by Googling for "key-agile cipher".