Why shouldn't I use ECB encryption? I'm using Java to generate encrypted strings, and I get this warning at build time:

  ECB encryption mode should not be used

So I'm wondering why I shouldn't use ECB and what I can use instead?

Why shouldn't I use ECB encryption?

The main reason not to use ECB mode encryption is that it's not semantically secure — that is, merely observing ECB-encrypted ciphertext can leak information about the plaintext (even beyond its length, which all encryption schemes accepting arbitrarily long plaintexts will leak to some extent).

Specifically, the problem with ECB mode is that encrypting the same block (of 8 or 16 bytes, or however large the block size of the underlying cipher is) of plaintext using ECB mode always yields the same block of ciphertext.  This can allow an attacker to:

detect whether two ECB-encrypted messages are identical;
detect whether two ECB-encrypted messages share a common prefix;
detect whether two ECB-encrypted messages share other common substrings, as long as those substrings are aligned at block boundaries; or
detect whether (and where) a single ECB-encrypted message contains repetitive data (such as long runs of spaces or null bytes, repeated header fields or coincidentally repeated phrases in text).

There's a nice graphical demonstration of this weakness on Wikipedia, where the same (raw, uncompressed) image is encrypted using both ECB mode and a semantically secure cipher mode (such as CBC, CTR, CFB or OFB):

While this scenario is somewhat artificial (one would not usually encrypt raw images like this), it nicely demonstrates the problem with ECB mode: repetitive areas in the input image result in repetitive patterns in the encrypted output, so that many large-scale features of the image remain recognizable despite the encryption.  In the real world, a cryptanalyst attacking an ECB-based encryption scheme would be more likely to look for such patterns in a hex dump of the ciphertext, but the principle is the same.

An actual case of this weakness of ECB encryption contributing to a real-world data compromise is given by the 2013 Adobe password database leak, as described in this answer.  Here, one element contributing to the severity of the leak was that, instead of hashing them properly, Adobe had encrypted the passwords using ECB mode.  This allowed the attackers to quickly locate passwords shared by multiple accounts, or sharing a common prefix with other passwords (like password1 and password2), and also revealed the approximate length of each password.

The ECB encryption mode also has other weaknesses, such as the fact that it's highly malleable: as each block of plaintext is separately encrypted, an attacker can easily generate new valid ciphertexts by piecing together blocks from previously observed ciphertexts.

However, the malleability is only an issue if ECB encryption is used without a message authentication code, and, in this situation, is shared (to some extent) by all other non-authenticated encryption modes, like the aforementioned CBC, CTR, CFB and OFB.  Thus, it cannot really be considered a specific weakness of ECB mode, even though it does tend to be an additional issue whenever ECB mode is used.

What should I use instead?

You should use any authenticated encryption mode, such as GCM, EAX or OCB.

Personally, for short messages, I'm rather fond of SIV mode (RFC 5279), which provides an extra layer of misuse-resistance.  (Many other encryption modes will break rather badly if the same IV / nonce is accidentally used to encrypt multiple messages.  SIV mode retains all its security properties in this situation, except for leaking whether the encrypted messages are identical.)

You can also use any traditional semantically secure encryption mode (such as CBC or CTR), combined with a message authentication code (such as HMAC) using the Encrypt-then-MAC construction.  (That is, you should first encrypt the message, then compute a MAC of the ciphertext, and append it to the ciphertext.)  As long as you make sure to verify the MAC before attempting to decrypt the message, this construction will protect you from the various vulnerabilities of these modes to active (chosen-ciphertext) attacks.

For disk encryption or similar applications that require the ability modify parts of the ciphertext without re-encrypting all the data, you should use a cipher mode designed for that purpose, such as XTS.  Note that such modes generally lack resistance to active attacks, and may have other weaknesses that should be understood before using them.  If possible, they should be combined with some form of integrity protection, such as a MAC on a hash tree.

As @Guut Boy mentioned it, ECB isn't semantically secure, in the sense that if a message with identical blocks is encrypted, then an attacker get a certain advantage to have information on plaintext, by only observing CipherText.

Use preferably CBC mode to encrypt long message. This mode introduce an additional parameter called the IV (Initial Value), you initialise with the session number to prevent attacks in the case of encrypting the same message twice.


Finding flaw in cryptographic protocol If you find a flaw or bug for example in Linux kernel you can create an issue in GitHub, or if you can solve it you can contribute.
How about Finding a flaw in cryptographic protocol?!

How can you report it or flag an issue?
If you can fix it, is it possible to contribute?

If you find a flaw or bug for example in Linux kernel you can create an issue in GitHub, or if you can solve it you can contribute.
  How about Finding a flaw in cryptographic protocol?!

A protocol is slightly different than a concrete implementation of a piece of software like the linux kernel on GitHub. It is closer to a specification that may be followed by many different implementations.

  How can you report it or flag an issue?
  If you can fix it, is it possible to contribute?

This depends on whether the protocol is something that is deployed and in use, e.g. TLS, or is a protocol that has merely been proposed academically.

If it is a theoretical academic protocol, you would create a paper discussing the attack or relevant shortcomings of the protocol and publish it as appropriate.

If the protocol in question is actually in use in the real world, then you would find who the authors of the protocol are and email them privately. Exactly who you email might vary depending on circumstances: Companies, individual implementors, and standards bodies might all be relevant. Try looking for white papers/RFCs/working groups/etc to locate the appropriate people to contact.

Be sure to include the email:

A thorough description of exactly what the problem is
Who is affected
How serious the problem is
How long the problem has been present
An implementation of the attack (a.k.a proof of concept)
Recommendations for how to fix the problem

Vulnerability reporting and disclosure can have multiple, orthogonal approaches and vendor responses may vary. If it is a widely used protocol like TLS your approach and response may very well be different from some random individuals project on GitHub.

Oh, and apparently it's trendy to create a branding campaign for the vulnerability, including a name, logo, and website. Whether or not this is a good practice is debated.

Or, you try to cash in on it.

If you're any good at finding flaws, there is a lucrative (and legal) yet very grey market in vulnerabilities and zero day exploits.  The New York Times have listed some prices and companies that resell these. Outfits like Zerodium in Washington; Netragard in Acton, Mass.; Exodus Intelligence in Austin, Tex.; and ReVuln, and a Virginia start-up named Endgame. Typical exploits sell for 35,000 to 160,000 dollars, but you can get up to 500,000 dollars for Apple’s iOS.

All of the security agencies pay to get these, presumably under some form of non disclosure agreements/secrecy legislation. The NSA seems to be the largest client, but the FBI also buys exploits such as for back dooring Firefox/Tor. If you're really good, you should be able to sell the same exploit to multiple buyers.  It depends on your contacts as to whether you  are able to access this market though.

In the war on terror, it could    literally be catastrophic   to not exploit such flaws.  Hawks would argue that it's your patriotic duty to     pass such information onto the security agencies.  Stuxnet, Flame and Duqu have all capitalised on zero day exploits with great success at disrupting Iran's nuclear program. It's to protect the children too. Or so the ideology goes.  As the whether it's moral/ethical, those issues have been formalised by Obama's Special Assistant to the President and Cybersecurity Coordinator, Michael Daniel:-

How much is the vulnerable system used in the core internet infrastructure, in other critical infrastructure systems, in the U.S. economy, and/or in national security systems?
Does the vulnerability, if left unpatched, impose significant risk?
How much harm could an adversary nation or criminal group do with knowledge of this vulnerability?
How likely is it that we would know if someone else was exploiting it?
How badly do we need the intelligence we think we can get from exploiting the vulnerability?
Are there other ways we can get it?
Could we utilize the vulnerability for a short period of time before we disclose it?
How likely is it that someone else will discover the vulnerability?
Can the vulnerability be patched or otherwise mitigated?

This policy is called NOBUS in the US and is for "investing in groundbreaking cryptanalytic capabilities to defeat adversarial
cryptography and exploit internet traffic." Examples of it are Dual_EC_DRBG,  cracking Diffie-Hellman  and EternalBlue in Windows. Quoting, "as a general rule, tries to focus on exploiting vulnerabilities used in its targets’ software".

In summary, there's lots of money to be made. And you'd be contributing to your country's security as JFK asked of us all.

Update:

Latest (March 2019) NY Times estimate  of this market now puts it at \$12B. Salaries >> \$200,000 working for companies like Darkmatter or NSO Group breaking WhatsApp and Skype traffic.


What are the properties of secure Elliptic Curves? I have heard about the standard elliptic curves called NIST curves. What are the properties of such cryptographically secure elliptic curves?
Are they standardized according to certain protocols? Also, does the attacker get any huge benefits from knowing which curve was used?

For typical protocols like Diffie–Hellman key agreement and Schnorr-type signature,* SafeCurves surveys the modern security criteria for elliptic curve choice.  In these protocols, the adversary is assumed to know the choice of curve; the security comes from criteria of the curve, not of secrecy of the curve.†

The basic criterion is that computing ‘discrete logs’—that is, given a scalar multiple $[n]P = P + \dots + P$ of a known point $P$ on the curve by a secret integer $n$, computing $n$—costs well above $2^{100}$ curve additions.  But there are many other criteria, like twist security, that are not as obvious to an untrained observer, and were not considered in the design of historical standard curves like NIST P-224.

Certain criteria are not about secure vs. insecure curves per se, but rather about fast and secure vs. fast or secure implementations: for example, NIST P-256 does not admit the Montgomery ladder, which is a fast way to compute $x$-restricted scalar multiplication in constant time.  In NIST P-256, you can compute scalar multiplication fast, or in constant time, but not both—so it is tempting to sacrifice security in pursuit of performance when implementing NIST P-256 or choosing an implementation of it, whereas with Curve25519 you can attain both simultaneously using the Montgomery ladder and there is no temptation to sacrifice security that way.

Some of the criteria are relevant to some protocols but not others, for instance because DH key agreement is subject to active attacks that are not relevant in the security model of signatures.  Fortunately, some curves satisfy all the criteria, such as Curve25519, Ed448-Goldilocks, and E-521.  The first two of those are standardized in RFC 7748, which also prescribes a rigid procedure for selecting a curve for a given prime field satisfying all the security criteria and optimizing performance by certain easy heuristics—a procedure which, incidentally, also generates E-521.‡

* SafeCurves does not address more exotic applications like pairing-based cryptography, which necessarily use a different class of curves.

† In the various proposed post-quantum isogeny-based cryptosystems, choices of curves are secret positions in an isogeny graph of curves, but this is a rather different scenario from what is usually known as elliptic curve cryptography today, and as such seems unlikely to be relevant to your question.

‡ The IETF chose to endorse Ed448-Goldilocks rather than E-521 because Ed448-Goldilocks performs better, and even though the theoretical attack costs on E-521 are higher than on Ed448-Goldilocks, the two both have a meaninglessly high ‘security level’ that only serves as a hedge against minor cryptanalytic advances, not to raise actual costs on what is an impossibly expensive attack to begin with.

1, there are websites/tools to check the curves you select, but highly recommend
that you use "mature" curves such as secp256k1

2, crypto protocols have nothing to do with the curve selection, such as the authentication protocol.

3, yes, only if you secretly select some insecure curve.


Can we prove possession of an AES-256 key without showing it? Imagine this situation:

Alice has an AES256GCM key $K$, a plaintext $X$, and $Y$ which is the ciphertext of $X$ encrypted by $K$
Bob has $X$ and $Y$
Alice and Bob can communicate with each other
Bob wants to know whether Alice holds the key which encrypts $X$ into $Y$

In this situation, Can Alice prove that she has $K$ without showing $K$?
and if so, how to do it?

Yes she can. She would do so by relying on a boolean circuit that takes $K$ as input, uses it to encrypt the plaintext $X$, compares it to $Y$, and outputs $1$ if and only if the comparison succeeds. Given such a boolean circuit $C$ (that both parties can construct), Alice must prove that she knows an input $K$ to $C$ so that $C(K) = 1$.

The task of proving knowledge of a witness for a relation described by a boolean circuit (in zero-knowledge, hence without leaking any information about the witness) has been studied a lot in the cryptographic community. Several protocols exist for this task, Zkboo is one example. It has three moves, and is based on the MPC-in-the-head technique introduced in this seminal paper.

Other solutions (see also this paper and the related but somewhat different solution presented in this paper) achieve a comparable efficiency, and are based on garbled circuits: Alice will hand Bob a "garbling" of $C$, which takes as input an encoding of her witness $K$, and evaluates the circuit on $K$ in a hidden way, and outputs $C(K)$ (the details are quite technical, so I'll stick to this high level explanation unless you want a deeper overview of how it works).

EDIT: corrected the statement that Zkboo was based on garbled circuit, I had confused it with another paper, thanks to redplum for pointing this out.

The Socialist Millionaire Protocol was designed to do do just this. It is also very commonly used in OTR messaging to do a question based authentication of the person you are communicating with (e.g. ask the person the question and validate that you both give the same answer based, without revealing what the answers were to each other).


Extend OTP on random data? If Alice and Bob both start with a shared OTP $P_0$, which is 256-bytes long, and Alice wants to send a 512-byte message, would it be secure to send the first 256 bytes with standard OTP ((a+b)%256 or the like), then generate another 256 bytes of true randomness ($P_1$), run that through the OTP and send the encrypted form of that. Repeat for the second block of 256 bytes and $P_1$, etc. Bob then decrypts the first 256 bytes with $P_0$ and gets $P_1$ from the second 256 bytes. Rinse and repeat, etc.

Is this secure from a passive Eve? If not, why not?

No, that doesn't work. OTP is secure because knowledge of the plaintext doesn't give you any useful information about the key. This is because the bits of the key (e.g. $P_0$) are never used to encrypt anything else.

If you would somehow reuse the key then leakage of the plaintext would cause leakage of $P_0$. Leakage of $P_0$ directly leaks $P_1$. I.e. instead of perfect security the information encrypted by $P_1$ is now directly dependent on the security of the plaintext and $P_0$.

OTP is only perfectly secure as long as the bits in the key stream are independent of each other. OTP doesn't allow for shortcuts in that respect.

If you use the OTP it has been used since its invention you will not get away with it. But there is a way that you can beat an attacker (Eve).
For the purpose of sending only text we will add a comma, full stop and a space character into an alphabet and randomise it. This will be the initial key that Alice and Bob share.
The possible permutations for the randomisation are P29 = 29! = 29 x 28 x…..2 x 1.
(Alphabet: P26 = 26! = 26 • 25 …….. 3 • 2 • 1 =  403,291,461,126,605,635,584,000,000)
This initial key needs to stay secret and only shared by Alice and Bob.
Below the image shows one of the possible permutations(P29); two messages we encrypted with two ciphers that displays the hex and decimal values we used to replace our text, a full stop and space characters.

Before Alice starts to encrypt her message she creates a pin number (we used 3 digits) that will be used to create the cipher. The first step she does is moving the starting point of her first permutation by using the first number of the pin.

STEP = EFWHAIJZK.LONPRQD GSTUVYXBMC,       Position moved by 4 (T = 21)
Moving to the end of the string looking for the next character. When reaching the end she returns to the start
of the string and moving again the position according to the next pin number.

STEP = FWHAIJZK.LONPRQD GSTUVYXBMC,E       Position moved by 1 (H = 3, E = 26)

STEP = K.LONPRQD GSTUVYXBMC,EFWHAIJZ       Position moved by 7 (space character = 10)

STEP = NPRQD GSTUVYXBMC,EFWHAIJZK.LO       Position moved by 4

STEP = PRQD GSTUVYXBMC,EFWHAIJZK.LON       Position moved by 1

STEP = TUVYXBMC,EFWHAIJZK.LONPRQD GS       Position moved by 7

STEP = XBMC,EFWHAIJZK.LONPRQD GSTUVY       Position moved by 4

STEP = BMC,EFWHAIJZK.LONPRQD GSTUVYX       Position moved by 1

STEP = HAIJZK.LONPRQD GSTUVYXBMC,EFW      Position moved by 7

Step    = ZK.LONPRQD GSTUVYXBMC,EFWHAIJ       Position moved by 4 (full stop = 1)

What Alice did is creating a string of random numbers which are as random as characters picked by an operator. Each number can represent any of the 29 characters in our randomised extended alphabet (1/29). Linguists too will have a problem to identify pattern that language holds since the randomization of our extended alphabet has destroyed them; and recording differences between characters doesn’t give anything away about the frequency of characters.
Now Alice can email her message and the pin code (of no use to an attacker without the correct permutation) and Bob can reverse it by using the pin code.
For a system that can encrypt text (no restrictions on languages), images, media files etc use a randomized ASCII (extended 256).


Does cryptographically-secure pseudo random generators require a secure seed? For any cryptographically-secure pseudo random generators, do we need a secure random seed for those?
If the seed is predictable, then everything is broken due to the deterministic propetry of the algorithms.

Actually, your second sentence itself is the answer. A pseudo random number generator(cryptographically secure or not) is a deterministic algorithm which produce random looking numbers. Every time you provide the same seed it produces the same random looking numbers. Now, if your seed value is predictable and algorithm is public then the output of the deterministic algorithm is also predictable. So, the seed of a cryptographically secure pseudo random number generator must be secret, so that the output you get is unpredictable.

Yes a CSPRNG does require a secret random seed.

Keeping cryptographic requirements in mind OS developers have given multiple sources for fetching a good enough seed from sources of high entropy, and they may be available in the form of APIs . For example arc4random() family of functions in BSD type operating systems. If the APIs are not available, then we ourselves have to , implement drivers/software to capture randomness, treating the user itself as a source (mouse movements, sensor pulses (if smartphone)), although this may not be reliable*. Then that data can be fed to some kind of hash function like SHA-2 / SHA-3 to generate the pseudo random output required. arc4random uses ChaCha20 to generate Pseudo randomness from the raw data, which is excellent,  given the fact that ChaCha20 using an incremented 64 bit counter internally can output 1 Zettabyte of pseudo random data with good diffusion . I'm mentioning these algorithms because they have stood the test of time and extensively subject to both linear and differential cryptanalysis.

As a side note:
When using other algorithms, you have to be careful though as CSPRNG's are notorious for being backdoored themselves, for example, the Dual_EC_DRBG 's kleptographic backdoors (that compromise the security of the random seed used), which made headlines .

But if the need for randomness is for generation of SSL certificates and thinks like that then it's better to rely on natural sources of entropy like radioactive decay. You can also use something simple like an army of lava lamps  https://youtu.be/1cUUfMeOijg  .

On further research on your question, I found this interesting :

  In particular, data that is very random always has a high level of entropy, but data that has high entropy is not necessarily very random.
  https://www.google.com/amp/s/techbeacon.com/security/how-really-random-numbers-will-bolster-your-encryption%3famp

*In Linux we have /dev/urandom or  /dev/random.  But reading from it every time (like reading a file) is not recommended as the OS can run out of entropy and hence it can affect the performance of your application.


Why gcd(r,(p-1)/r) needs to be 1 in benaloh cryptosystem I recently discovered the benaloh cryptosystem.
I am working with the system as it is discribed in the following link:
https://en.wikipedia.org/wiki/Benaloh_cryptosystem

However I need some help in order to understand why we need
\begin{equation}
{gcd(r,(p-1)/r)}
\end{equation}

As far as I understand the condition
\begin{equation}
r \mid (p-1)
\end{equation}
guarantees the existence of the subgroup of order (p-1)/r which contains the r-residues.

The third condition

\begin{equation}
{gcd(r,(q-1))}
\end{equation}

allows us to say that there are

\begin{equation}
\mid \mathbb{Z}_n^* \mid /r
\end{equation}
r-residues mod n.

what does the other condition add?

$gcd(r,(p-1)/r)$ needs to be $1$ in Benaloh cryptosystem that mean that $(r)$ and $(p-1)$ are preliminary among them.


Searching over encrypted data Is there any library/tool available which can allow me to search over encrypted data?
I would like to encrypt data on client side, send it to cloud and perform search in cloud.

I've been reading about homomorphic encryption and though there is CryptDb available which makes it possible to run encrypted DB in cloud, but my use case is slightly different- in my case I want to let users send me encrypted data and I want to be able to do a keyword search (as opposed to user performing search).

I don't think there is an existing library that can satisfy your needs.
Homomorphic encryption is powerful and requires lots of computations. However, in your case which allows user-defined keywords, I suggest you to take a look at Searchable Encryption.
Searchable Encryption is the algorithm that should be of interest. It allows cloud server to search 'blindly' on client's encrypted data, based on a 'trapdoor' - a token that contains keywords to be searched for - sent by the client. Of course, client must also encrypt the keywords along the encrypted data before uploading them, which will surely increase the overhead. For 'blindly' it means the cloud server doesn't acquire any unnecessary knowledge about the searched keywords and the encrypted data, during the entire query process.
Some of the searchable encryption algorithms are based on pairing-based cryptography. In that case, you can build your application based on PBC library.

In your requirement ,

if the users trust you , they may share their key's as well with you to perform search operations on their behalf and you act as proxy to send the queries and receive results
If the users don't trust you, then you would just be a relay agent for the cloud , instead users can search directly over the cloud to reduce the latency.

Apart from the search over encryption links suggested above in the comments, you may
want to look at CP-ABE schemes as well ,  Cipher Text Policy Attribute Based Encryption library.


Is it possible that a SHA256 hash has the same hex character over and over again? In theory, there are infinite inputs, that you can hash with SHA-256. So theoretically it would be possible that one hash string would read 0xaaaaaaaa...
But would that also be possible practically, or do the algorithms check that this is not happening?

First of all, the output of SHA-256 is binary and consists of 32 bytes (256 denotes the output size in bits). What you are talking about is apparently the hexadecimal encoding of these bytes.
The possibility that you are talking about is called (1st) pre-image resistance (Wikipedia):

Given a hash value $h$, it should be difficult to find any message $m$ such that $h = \text{H}(m)$.

("difficult" is a non-technical term here, generally we use "computationally infeasible", obviously there will be messages that map to any hash value, the difficulty is finding them for a one-way hash)
No, the algorithms do not check this explicitly, because the algorithm by itself needs to be resistant against it. Furthermore, the repetition of certain bits is not that special all by itself. It would be unclear what you would need to test for.
"But would that also be possible practically" well, no, unless SHA-2 gets broken. Generally it is collision resistance that gets broken first. That means finding a hash where $\text{H}(m) = \text{H}(m')$ for any $m$ and $m'$. This is easier to attack because an attacker can try and find weaknesses in the algorithm that create an internal collision while controlling both $m$ and $m'$. SHA-256 is still considered secure in this regard.

It is possible. However, hashes are suppose to be random and 0xaaaaaa... doesn't seem random at all. Ensure that the algorithm, software, code, etc. is working properly because it looks like a security bug.


Decrypting files with an unknown method but a known result I am assuming there is a very simple way of working this out by brute force, but I am not sure if there is a better way.

I have a file of data that I wish to get (my data, generated by a machine). This file is encrypted by some method that I have no details of (and the company has folded).
However, as well as the encrypted file I have an unencrypted file by the same machine for a different date range. Looking at the file it is easy to see that the encryption is in blocks of 8 bytes, as most of the header is zeros, so where the new file says 00 00 00 00 00 00 00 00 the old file says B5 B4 24 EF 45 BC 68 C5.

So I know what 8 0s are like, and 8 ffs and a few other items. I also know it is a block as a an area that is 7 0s and one digit is completely different.

Do I just assume it is RSA or something and make a brute force on the password?

No, don't assume it is RSA as it likely isn't based on the information.

You already have a possible block length. 64 bit block length could mean DES (or one of its variants such as 3DES) or blowfish. Another possibilty is that there was an 8 byte pad used in repeated XOR fashion. I'm sure there are other possible block ciphers with 8 byte block size.

Next I would look for repeated blocks. Anywhere in the plaintext file where the data is the same, see if the ciphertext data is the same. This would suggest either repeated XOR or ECB mode. If this is not the case, other modes (CBC, etc) are likely. The absence of repeated cipher blocks (where there are duplicate plaintext blocks) would seem to eliminate repeated XOR.

If that is all the information you have, your next step would be to brute force. If repeated XOR is a possibility, and since you know the header is 00 00 ..., the ciphertext would be your XOR pad. So try that and see if the decrypted file looks as you would expect.

Otherwise, I'd start with DES as it is probably the more popular of the two ciphers.

The 0s suggest counter mode. I'd guess AES for no particular reason other than it's popular. If that's the case, you won't be able to the brute force the key.


RNG failing Restart Tests by NIST SP800-22? I have data sample of 1,000,000 bytes generated by a hardware RNG. The device is certified by ENT test suite, NIST SP800-22, DIE HARDER and TestU01.

I have tested my sample by SP800-90B_EntropyAssessment (github.com/usnistgov/SP800-90B_EntropyAssessment). Minimum Entropy Estimate is 7.88237 after which I run Restart Tests.

My sample fails at Restart Testing and the program displays

  Validation Failed, No Entropy Estimate Awarded.

“Analysis and Improvement of Entropy Estimators in NIST SP 800-90B“ (PDF) says

  Randomness has three features: unpredictability, unbiasedness and non-repeatability and and the non-repeatability is validated by restart tests.

I want to know if my RNG is failing Restart Tests, does it mean it offers no entropy at all?

The test that fails seems to be the one in 3.1.4 (Restart Tests) of NIST SP 800-90B (2nd Draft), specifically 3.1.4.3 (Sanity Check - Most Common Value in the Rows and Columns), failing at

  546     If F is greater than U, the test fails.

It can not be concluded that a generator that fails this has no entropy at all. It could well be that it has some imperfection, but still outputs a fair amount of entropy, leaving it perfectly usable to seed a CSPRNG.

CAUTION: this test requires 1000 samples obtained by re-starting the source and collecting 1000 symbols. If the question's 106 bytes are generated by the hardware RNG without restarting it, then the test is abused (if it had succeeded that would be meaningless). But such abuse can not be why the test fails.

It is a common event that Output of RNG fails some Randomness Rest. That can occur for any combination of four causes:

Goof in use of Randomness Rest (or collecting Output of RNG, but here that's unlikely given that other tests have passed); like, the format, size.. of Output of RNG is not as expected by Randomness Rest with the parameters used. The possibilities are endless. This is diagnosed as for 3.
Bad luck. All useful randomness tests are expected to have some rate of false alarm, with a certain probability: the P-value, which any good test documents. Here my reading is that it is 1%. Assuming this, and if possible, re-run Randomness Rest with the same parameters, and a few fresh Output of RNG. If the next two tests fail, we can exclude bad luck with high confidence. Otherwise (that is, if some succeed), we can suspect bad luck (or 1.), and we should use a form sequential analysis to decide. As a rough approximation: run another 997 tests, compute the number of tests out of 1000 that failed (which should be in the order of 10), reject bad luck with high confidence if that's more than 27 (still suspect some issue and investigate thoroughly if that's more than 15).
Goof in Randomness Test (either it's implementation, or definition if that's a draft or has otherwise has not stood intense scrutiny). The general method to detect this is to run randomness test against files generated by a simple (thus hopefully correct and acceptably fast) CSPRNG (one is given below). The proportion that fails should be about the documented P-value.
Defective RNG. Conclude this after having eliminated all the rest.

Here is a simple generator of pseudo-random sequence:

// Simple generator of cryptographically secure pseudorandom sequence.
// The 64-bit block cipher TEA is used in CFB mode to encipher
// plaintext consisting of the block number.
#include <stdint.h>
#include <inttypes.h>
#include <stdio.h>

// For a different sequence, change these arbitrary 32-bit constants,
// used as key for the TEA block cipher.
// Note: in David Wheeler and Roger Needham's TEA, each key has 3 other
// equivalents, as the high-order bits of K0/K1 and K2/K3 cancel out.
#define K0 0x7638d4f2
#define K1 0xabe32749
#define K2 0x56b81d0e
#define K3 0x4ed51d62

// output size, multiple of 8
#define OUTPUT_SIZE 1000000

int main(void) {
    uint32_t j, n, s, y=0, z=0;
    for( j=0; j < (OUTPUT_SIZE+7)>>3; ++j ) {
        s = 0;
        n = 32; do { // 32 pairs of rounds
            s += 0x9e3779b9;
            y += ((z<<4)+K0) ^ (z+s) ^ ((z>>5)+K1);
            z += ((y<<4)+K2) ^ (y+s) ^ ((y>>5)+K3);
        } while (--n);
        z ^= j; // CFB; makes short cycles virtually impossible
        // portably format in lowercase hexadecimal
        printf("%08"PRIx32"%08"PRIx32, y, z);
    }
    return 0;
}

// Generates one million octets expressed as two million characters
// in lower-case hexadecimal on standard output; when expressed in
// ASCII as two million octets, their hash per SHA-256 is
// d5b727ef6a9177c897b68085d60a7660f6f6b1dbf09cb7e91fe59da3a66d4e2d

It's easy to test the restart test. As I commented earlier, generate 1MB from /dev/urandom using disc destroyer (dd) or download a binary version of pi from the internet. 1000 concatenated blocks of 1000 random bytes should be indistinguishable from a single 1MB random sequence.  Use that as the restart test file.  If it fails, then it's definitely your test methodology.

Assuming that your methodology is sound, it's probably that your device just doesn't generate good entropy from power up.  I would not be surprised as electronics take some time to warm up and settle. Capacitors need to be charged and voltage spikes have to diminish.  A good device should wait for a period for this to happen prior to commencing output.  But it might not, especially if it's a small USB thing made in a garage (as many appear to be).  Take for example the SG100.  It's a pile of rubbish with technical documentation that's full of errors and a schematic that looks as if my 11 year old drew it. The reason I mention this one, it that it runs casinos like Gala.

I wouldn't worry too much about the restart tests.  If you look at governmental testing of large consumers of random numbers ie. casinos and lotteries, it's only the long run randomness that's enforced.  If you look at the RNG certification for some casinos, they use custom statistics and DIEHARD anyway.  They don't use NIST testing as it's not relevant for return to player ratios.  The most important thing is that you know how your device behaves.  If it takes 2 mins to warm up, so be it.

Test the test with pi and see...


Can ECDSA signatures be safely made "deterministic"? Using the terminology of the ECDSA Wikipedia page, ECDSA (and DSA) signatures require a random k value for each signature which ensures that the signature is different each time even if the message and key are the same. For some applications, a "constant" signature may be desirable.

It seems to me that there would be no harm in implementing "constant" ECDSA by setting the "random" k value to be the x-coordinate of the message hash z (converted to a curve point in some arbitrary fashion) multiplied by the private key. Obviously the method translates back to DSA.

This scheme might be useful for implementations that do not have access to a source of random numbers.

Are there any problems with this?
Is there a faster way of generating a suitable k than a point multiplication?

There is a draft RFC which describes a way to implement deterministic (EC)DSA (with test vectors). In this draft, both $h(m)$ (the hash of the message) and $x$ are used as input to a deterministic PRNG which uses HMAC (that's HMAC-DRBG as specified by NIST); the PRNG output is used to yield $k$. I am not sure your simple multiplication with $x$ would be enough to guarantee security; ideally, a random oracle should be used, and HMAC-DRBG is the closest to a practical random oracle that I could find.

Note that $k$ must be generated uniformly in the $[1, q-1]$ range (where $q$ is the subgroup order). Any information on $k$, even partial (such as: values between $1$ and $2^{160}-q$ are twice as probable than values between $2^{160}-q$ and $q$), can be exploited by the attacker.

(There will be a new draft version with a few text changes in the draft -- but the same test vectors -- as soon as I find the time to do it.)

Edit: the RFC is now published as RFC 6979.

This certainly creates the opportunity to mount a birthday attack.
Oscar creates two Messages hashing to the same value - certainly doable at least with sha1 or MD5 and succeeds in making you sign both of them. He can then reconstruct your private key from the signatures.

I would certainly avoid deterministic ECDSA Signatures and regard the very act of securely creating the random number for signing as a core security feature.

In an ECDSA setting the (P)RNG is a prime target for attack. Tampering with this part is dangerous in my opinion, regardless whether it may mathematically be sound in principle.


Can a digital signature scheme also be an encryption scheme? Using Schnorr signatures, one could devise a system where a single public key can represent multiple signers. Do signature schemes like that represent crypto systems usable for encryption?

In that case, could you say that a signature scheme and an encryption scheme represent the same thing?

In that case, could you say that a signature scheme and an encryption scheme represent the same thing?

I don't see how.  With a signature scheme, the public operation can return just a single bit (either "the signature verified" or "it didn't").  It's not at all clear how you could efficiently use a function that returns a single bit as a part of an encryption operation.

Now, there are certainly cryptographical primitives - such as modular exponentiation within RSA - that can be used as a primitive within either a public key encryption or a signature scheme; however there are also signature schemes that cannot be used to do encryption, and so generically, the two classes of schemes cannot be identical.

I think the current public/private key systems have many parallels with encryption/decryption functions.

For example, the generator point (which relies on the underlying curve) is the shared key, upon which all private keys are calculated with - in order to compute/derive the corresponding public keys (not including hashing/pre-address formatting).

So if one wanted to encrypt some plain-text message of a length less than the length of the key, it could easily be done with the private key as the one-time pad (OTP) to xor a message for example, and then at some point in the future decrypt that same ciphertext message by xor'ing it again with the original private key (then discard that address/key-pair, as the OTP shouldn't be reused). [Just to be clear I am not implying this is how private keys should be used from a public/private key-pair, but just pointing out that a private key "could" be used to encrypt, and not just to "sign" to prove ownership.]

However, to send that ciphertext to someone else, would require their knowledge of the original private key if they wanted to decrypt it. For longer messages, some key stretching function could also work for keys that aren't long enough, although caution would be needed that the method doesn't leak anything information about the key.


Is there any existing cipher capable of scaling from a 1 bit key up to a one-time-pad? We have ciphers that handle small amounts of entropy, such as a 256 bit key for AES; and we have one time pads for enciphering 1:1 entropy, such as a 1GB key for a 1GB file if you could ever harvest enough decent random noise.

Now in theory you would imagine that there is a universal class or model of cipher that can scale smoothly from a single bit of entropy all the way upto a 1:1 one time pad.

If such an algorithm or cipher already exists - what is it called?

a one time pad ia very different from other fixed key ciphers.
A one time pad is just a xor(or modular addition) It does not miz anything or extend key and even a tiny bit of key reuse is very problematic.
We have stream ciphers which take a key and produce an infinite stream of pseudo random bits.
Perhaps what you are asking for is for a cipher with arbitrary key size with guranteed perfect security for total message length less than key size and reasonable security for reasonable key sizes.
I can suggest the following construct. take the key and duplicate it by concatenation to produce naive infinite key.
Use Each key block to encrypt a counter like in CTR mode.
This by itself doesn't give perfect secrecy. You could then xor each block with the following key block. That would give  perfect secrecy when message is at least one block less than key. It might be possible to do better. But this construct will give at least the security AES CTR.

I call an algorithm meeting this spec "rolling xor". It's only strong at the one-time-pad level though.


Let F be a PRF, how to prove F3 is PRF? Let $\operatorname{F}$ be a $\operatorname{PRF}$, how to prove $\operatorname{F^3_{k_1,k_2}}(x) = \operatorname{F_{k_1}}(x) \oplus \operatorname{F_{k_2}}(x) $ is aslo a $\operatorname{PRF}$?

This cannot be a PRF in all cases, because in the edge case where K1 = K2, the output of F3 will be 0 for all x.


Digital signatures with one-way function, can messages be longer than the signature? Ethereum and Bitcoin both use 512 bit signatures, can the message that is being signed be longer than 512 bit?

Yes.

Signature length is generally unrelated to the length of the message and the length of the key.  Some signature schemes have very short signatures and long public keys, like CFS; some have short keys and very long signatures, like SPHINCS; some are more balanced in size, like Ed25519 or RSA-2048-FDH.  Only exotic signature schemes for very special purposes are limited to short messages—the vast majority are designed to handle messages of arbitrary length.

Pretty much every signature scheme is designed with a random function from messages to elements of some mathematical structure for the public-key cryptosystem.  This serves to destroy any relations in structured messages.  If we didn't do that, e.g. if we used RSA with the stupid verification equation $s^3 \equiv m \pmod n$ for a signature $s$ on a message $m$ under public key $n$, then you could trivially forge the signature $s = 1$ on the message $m = 1$ under any modulus $n$ because $1^3 \equiv 1 \pmod n$.  Instead, serious practitioners use a sensible verification equation like $s^3 \equiv H(m) \pmod n$ where $H$ is a random function from messages to $\mathbb Z/n\mathbb Z$ so you have no hope of finding an $m$ such that $H(m) = 1$.

Practical signature schemes are usually instantiated with a fixed hash function $H$ accepting arbitrary bit strings as inputs, like SHAKE256.  This is not simply ‘hashing a message, and then signing a hash’—the hash is an integral part of the signature scheme itself, not something you do in addition to signing; the security of the signature scheme relies critically on the hash.

In the signature scheme that Bitcoin uses with the OP_CHECKSIG operation, the message, a transaction, is an arbitrary bit string, mapped with SHA-256d (that is, two iterations of SHA-256, $m \mapsto \operatorname{SHA-256}(\operatorname{SHA-256}(m))$) into a scalar modulo the order of the curve secp256k1.

My answer was not accurate. Please see the other answer.


Password length versus hash length? If a system hashes passwords with a 256-bit long hash, are passwords (which are not necessarily alphanumeric, can be any value per byte (0-255)) longer than 32 bytes useless under the context in which an attacker with a VERY fast machine brute forces passwords?

The entropy of passwords is not universally distributed. So hashing can be used to concentrate the input of a hash.

The concentration of entropy from another source is called extraction by HKDF, which is a key based key derivation function (which should not be used for passwords). This is from the introduction of RFC 5869, which defined HKDF:

  Thus, the goal of the "extract"
     stage is to "concentrate" the possibly dispersed entropy of the input
     keying material into a short, but cryptographically strong,
     pseudorandom key.

Now the problem with passwords it that they usually does not contain enough entropy or randomness. The size of a password is an important part of estimating the strength of a password. If a password has enough entropy then you could even use a KBKDF such as HKDF or a hash directly. But the table on the same Wikipedia page shows that you would need 20 fully random printable ASCII characters to accomplish a 128 bit security level.

Instead what is used is a Password Based Key Derivation Function or PBKDF. The usage of such a function is often called password hashing to distinguish it from directly applying a hash over the password. Common implementations are PBKDF2, bcrypt and scrypt. The PBKDF uses password stretching to accomplish password strengthening. It adds at least two input variables besides the password: a salt and a work factor.

So to get back to your question:

don't use a normal hash for password hashing, use a password hash/PBKDF;
the more randomness in the password, the better - this usually means longer hashes not shorter ones;
the size of the password is not in any way limited by the (password) hash function.

A human will never - in real life scenarios - remember a password or care to type in a password that contains enough randomness to reach the security level provided by even the least of the hash functions (MD5).

In the end it doesn't really make sense to limit the size of passwords unless for backwards compatibility reasons. The minimum size should be controlled however, and as many possible additional measures should be taken to protect the password as passwords are inherently weak.

I did not quite understand the question. Specially the part that says under the context.

The answer is no. because,

The output of a hash is a fixed value, for any given input of any length (If the length of the input is shorter than the block size, depending on the HASH algorithm being used, an appropriate padding scheme is present).

So whether the passwords were 32 bytes, or more, or even less. It makes no difference. Although it is much better to use longer passwords as the short and common ones can be retrieved using a pre-calculated look-up hash table.

One point worth mentioning is, as long as a developer is storing passwords in the database as the hashes of the passwords rather than the plain passwords themselves, it is of no value to limit the maximum length of the password. In fact, the longer, the better. BUT, in the end, they all wind up (in your case) to a 256 bit chunk.


Is it possible to determine or estimate the period for Blum-Micali PRG? The Blum-Micali is a cryptographically secure pseudorandom number generator.

The construction (from wikipedia):

Let $p$ be an odd prime, and let $g$ be a primitive root modulo $p$.
Let $x_0$ be a seed, and let $x_{i+1} = g^{x_i}\ \bmod{\ p}$.
The $i$-th output of the algorithm is 1 if
$x_i < \frac{p-1}{2}$. Otherwise the output is 0.

I have toyed with small values of $p$ and have noticed that cycles occur if there's a fixed point, that is $x_{i+1} = x_i = g^{x_i}$.

For example when $g=3$ and $p=7$ (from wikipedia primitive root example), there are two fixed points where $3^4 = 4 \bmod 7$ and $3^5 = 5 \bmod 7$. This would be problematic for Blum-Micali generator since it would cycle and repeatedly output the same bit.

Is there a relationship with the size of $p$ and the period which is based on the likelihood of a fixed point?

Under the question's hypothesis, $x\mapsto g^x\bmod p$ is a permutation of $\mathbb Z_p^*$, that has some characteristics of being random.

If we take a random permutation of a set of size $s$, the length of the cycle iterating that permutation from a random point has length $l$ with probability exactly $1/s$, independent of integer $l$ with $1\le l\le s$. It follows that the cycle has length $l$ or less with probability exactly $l/s$.

This forms an heuristic argument (obvious, as pointed by Thomas in comment) that perhaps it is $\epsilon$-rare that the cycle length of the question's generator is much less than $\epsilon\,p$.

This is however very far from a proof or even a convincing argument. In particular, because $x\mapsto g^x\bmod p$ belongs to a very small and special subset of the permutations of $\mathbb Z_p^*$, with that subset having $(p-1)/2$ elements out of $(p-1)!$ permutations.

By contrast, D.W.'s argument is a valid proof that the cycle length is too large to be found when $p$ is such that the discrete logarithm problem is hard. However that gives a considerably looser safe estimate of the cycle length; perhaps likely at least $2^{100}$ for $2048$-bit randomly-seeded $p$, when the above heuristic argument suggests likely at least $2^{2040}$.

What is often recommended is to make sure that your value of g is a "generator" mod p. I don't know if this term is often used, but I've had it defined as cycling through the entirety of a set {0, 1, ..., p - 1} by raising it to consecutive powers mod p. If you use a number with this property, you will never have any short cycles and will in fact generate every value available mod p.


Low entropy - how does it compromise the crypto One of the often pointed out mistake in dealing with crypto is not having enough entropy in the system. Without enough entropy the random numbers generated are not random enough.

But what I am not able to piece together is how exactly the lack of randomness can lead to less secure systems. In what does a key generation on a low entropy system make it vulnerable for attacks ?

If the adversary can guess the key, then they can do all the things that a legitimate user can do: decrypt secret messages, sign statements transferring money to their accounts, etc.  The min-entropy of the process used to generate keys must be high enough that the adversary has no hope of guessing the generated keys by chance.

By example, consider these two passwords/keys:-

"secret"

"6D 9F 8F 5F 6B A6 03 21 8E C3 FB 68 1F 1C 9D 51 84 E5 6D 62 4C 0F 6F 63 42 42 8E 88 07 B1 E2 23 34 07 20 C2 93 1B C0 21 F1 8C 56 95 BC 51 55 54 4F 20 47 66 82 16 2A B7 EB 1C CA EF A4 81 5B A1 11 4D 3D CD 9A F5 09 90 26 61 0A BC 91 F5 2D 98 E2 0C 28 C3 06 CD A7 C5 4C E3 8B D1 78 36 C8 57 6F 83 51 1A 62 42 64 B4 4D 9F BC FD B6 6D 1D F6 66 5E 15 9C 03 E2 C9 63 79 9F B2 76 A6 B3 6D EB"

The former was pulled out of my head. Password entropy calculations are notoriously difficult, but you can see that it's a bit short.  It's also a common word and can be found in hackers' dictionaries.  The latter is 1024 bits of entropy pulled from a   true random number generator (TRNG). There are $2^{1024}$ or $10^{308}$ possible values of this length. Clearly that's much harder to guess.

But the latter was also much harder to generate. It took a device, investment £s and consumes space and electricity.  These are often in short supply with many internet of things devices built to a price point and running on batteries. This causes entropy starvation. The cheapest of these do not have any form of embedded entropy source. And that can lead to weak keys like "secret" simply being hard coded into the firmware.

Eg.: simply spending £K's on kit without entropy is not always adequate either.  This is a technical guide to stealing Tesla Model S cars by exploiting 40/24 bit fixed keys with a Time-Memory Trade-Off attack using a kiddies Raspberry Pi. A low entropy car, and quite ironic given that the £30 Pi has a good TRNG inside it.


What does trust mean in cryptography? Terms like "trustless protocol", "trusted third party", "trusted platform", "trusted server", etc. require a notion of trust. I already wrote

  The term trust when used in the context of cryptography does not refer to personal confidence in whether a person is reliable or has good intentions but instead describes whether an entity can be assumed to always behave according to protocol within the given model.

and went looking for a source to back this claim up. Unfortunately, I wasn't able to find one, nor was I able to find one to say that my notion of what "trust" means in cryptography is wrong.

So what does this term refer to formally?

A most common use of "trusted" in cryptography is to state that what's qualified as "trusted", by hypothesis, behaves/works/performs per a certain precise set of rules (which depends on context), and will perform no less and no more. That's the case in trusted third party, and trusted server.

A special case is "trusted" applied to data, e.g. trusted key. There, trusted means that the data is assumed to possess some property, which depends on context. Typically, having been generated by a certain party in a certain way and not having been altered by any adversary; or/and being unknown to any adversary. Data can become trusted after having passed a cryptographic check, e.g. a digital signature or Message Authentication Code verification; or be initially trusted (e.g. a Root Certification Authority public key).

In marketing talk like trusted platform module or trusted computing, "trusted" means intended for implementation of something trusted in the above cryptographic sense. Experience often shows otherwise, but confusion between intent and fact is the lesser of the many kinds of lies in marketing (which also has plain lies, damned lies, and statistics).

"Trustless" means not requiring something "trusted". For a protocol, that's not requiring a trusted arbitrator, typically replacing that with users that still are expected to largely play by some rule, because they have no long-term interest in doing otherwise (perhaps, unless enough users band together to rip the others).

In this context, trust can be understood as secure or reliability.


What does "Worst-case hardness" mean in lattice-based cryptography? In the wiki page of Lattice-based Cryptography the "Worst-case hardness" is defined as below:

  Worst-case hardness of lattice problems means that breaking the cryptographic construction (even with some small non-negligible probability) is provably at least as hard as solving several lattice problems (approximately, within polynomial factors) in the worst case. In other words, breaking the cryptographic construction implies an efficient algorithm for solving any instance of some underlying lattice problem.

But what is the difference between "worst case hardness" in lattice-based cryptography and "average case hardness" in standard cryptography based on discrete logarithm, say ElGamal Encryption?

It's seems to be confusing. For instance, breaking into ElGamal Encryption also leads to breaking several other cryptographic constructions and solving well-known number theoretic hard problem:  computational Diffie-Hellman. However, that one does not considered a "worst case hardness".

One line: worst means any and average means random.

Lattice-based cryptosystem

Let me restate.
Fix security parameter $n$.
What the reduction shows is the existence of a solver for the lattice problem on input any $n$-dimensional lattice using the adversary breaking a lattice-based cryptosystem with the security parameter $n$ on the average case.

Since we can solve any instance, we can solve the hardest one of dimension $n$.

ElGamal encryption - average-case

We have a reduction that converts a random instance of the CDH/DDH problem into a random problem of one-wayness/indistinguishability game. This means that the security is based on the average-case hardness of the problem.

ElGamal encryption - worst-case

Correctly speaking, the security of the El Gamal encryption scheme can be based on the worst-case hardness of the DL-like problems over the group instead of the security parameter.

Fix a prime-order group. We can convert any instance of the DL/CDH/DDH problem on the group to a random instance of the problem on the same group.
( This property is as known as the random self reducibility.)
Combining it with the previous reduction, we can say the security is based on the worst-case hardness of the problem over the fixed group.

Worst case hardness means that the whatever problem you use and is based in lattice base problems then it is hard in worst case (means it is verrrry hard to solve by polynomial and quantum(exists?) computing. In contrast RSA (prime factoring) and discrete log cryptosystems are not in all instances  hard in worst case but in average that means that if for instance i give you an instance of the problem ($N=21$) you know the solution ($p=7$,$q=3$ or $p=21$ and $p=1$). Thus the problems are "hard" under certain circumstances (big prime number factors, and appropriate groups where discrete log is hard to be solves) and not every time as in lattice based problems


What is the largest performed/possible bruteforce attack to date? I've read that cracking 128-bit key is currently out of reach of all humanity. However, I can't seem to find any information on what scope of brute force attacks have been performed or are possible at the current time. Can someone provide some information on this subject with quotable reference?

The last major effort I know of for cracking keys was the Distributed.net effort.

You can find the project page at http://www.distributed.net/RC5/en. In 2002, they cracked a 64-bit RC5 key using at total of 331,252 computers over 1,757 days. Their maximum throughput was "equivalent to 32,504 800MHz Apple PowerBook G4 laptops or 45,998 2GHz AMD Athlon XP machines or (to use some rc5-56 numbers) nearly a half million Pentium Pro 200s." as it said in their press release.

At the time, they moved on to doing a 72-bit key, which would be 256 times harder.

If we do some Moore-Law-type hand waving, we'd see a $2^7$ (128×) increase in compute power in ten years. That means that if you started today, it would only be twice as hard as breaking 64-bits was a decade ago. Doable, but not many people would actually want to bother.

Even if you're a government, buying a zero-day exploit and tailoring your own malware would be cheaper.

For RSA, the factoring challenge for 768 bit RSA modulus was met in December 2009. Authors published their procedure here. What this means is that if you have a RSA private key of 768 bit, you are potentially vulnerable to practical factoring attack with hardware available today.


Is the Vernam (One Time Pad) cipher useful? By profession I’m a programmer. I don’t know a lot about how cryptographic algorithms are implemented, or even where I’d start, and I don’t know about cryptanalysis, but as I work in Blockchain technology, I know how to consume cryptographic algorithms. One might say I have a passing interest.

One thing that has piqued my curiosity, as it probably does many novices in cryptography is the Vernam, or One Time Pad cipher; supposedly 100% mathematically impossible to crack and incredibly simple to implement.

The problem seems to be around the keys used. Specifically:

Keys shouldn’t be reused
Key sequences shouldn’t be repeated
Keys need to be shared somehow

Other encryption algorithms solve (or don’t suffer from) these problems, but, if we can find a suitable, secure way to generate and share unique keys, does the Vernam cipher become useful?

Is there anything else that needs consideration in this respect?

As you know, if a thing is useful or not depends upon context.  If you are hungry, will a 4096-bit RSA key with a CAMELLIA256 subkey be useful?  Not really, except perhaps as food for thought.

One-time pads are being used at this very moment by serious and perhaps dangerous people all over the world.  OTPs work.  Ciphertext encrypted with a one-time pad can be heard on HF radio all the time.  Is it useful?  Certainly.  The question is: "for whom?"

Why are one-time-pads useful?  You don't have carry around a lot of equipment.  Paper does not leave an electronic trail.  Paper burns.  Little pads are easy to hide. It's hard to get a kleptotrojan into a pencil.  Paper is cheap.  Vernam cipher is the perfect cipher if the key is truly random, the key was protected, and the key is as long as the message.  When your equipment stops working you can pull out the little book and figure out a way to deliver your message--and its content will remain private.  You can actually see the key destroyed. When you destroy it, it's really gone.  Everything about using a one-time-pad is easy to understand. A one-time pad does not require electricity. If you lose your pad, that might be bad, but you don't have to revoke it in front of everyone.  All of that sounds very useful, right?

So, to answer your question directly, "if we can find a suitable, secure way to generate and share unique keys, does the Vernam cipher become useful?"--yes, it already is very useful to certain people all over the globe, but they are not talking about it.

"Is there anything else that needs consideration in this respect?"

Yes.

It isn't that the key "should not" be used again, as if it were an option.  It must only be used once.
The key must be at least as long as the plaintext.
The key must be truly random in order to be perfect.
The key must have been protected against damage or compromise.
The key must have been shared via a secure means.

Many talk about OTP in theoretical terms, but I'll point out some obvious practical considerations that make operating OTP encryption challenging:

OTP pads cannot ever be left out of your sight out custody:  Are you going to leave your pads in a hotel room while you move around?  Erm, no. They have to be carried on your person and the mere possession of these can identify you as a person of interest. Maybe the security services who intercept you pull out a pair of tin-snips and start cutting your fingers off to elicit "cooperation". So you can't leave the key material out of your sight, but carrying it on your person incurs risks.
Key Distribution: the act of transferring the keys leaves you vulnerable. If either party is already being watched, and you meet them to exchange key material, now your identity is compromised.  Dead-drops won't mitigate this risk.
Timely Destruction of Key Material: As long as you hold onto that key material it's at-risk of compromise.  People talk about just "burning" it, but is that possible in a hotel room with smoke detectors? ;-). So there's a window where the secure channel could be compromised.

Those are the (3) obvious practical issues that come to mind; probably loads of others. None of this is to say OTP encryption is bad- it's actually the gold standard of secure communications, but operating the system can be challenging to say the least.


Dice rolls as entropy source? I would like to generate a 128 bit random number with dices, but I have heard that dices are pretty biased, especially low quality (non casino dices).

Would it make sense to generate a higher bit number, like a 1000 bit number? Would that "absorb" the flaws and biases exhibited in the dices. In the sense that the overall bias diminishes, the more bits you add to it?
What is the best method to make the bias go away?

Concatenating the individual numbers thrown into a  128 bit string
Multiplying the individual numbers thrown
A combination of both, for example with 2 dices: (R1+R2)x(R3+R4)x(R5+R6)…

…
  What is the best method to make the bias go away?
  …

No matter if we’re talking about the bias coming from manufacturing flaws, or the bias we know from casino-quality dice, you can use the Von Neumann skew-correction algorithm to generate uniformly random data from skewed input.

The Von Neumann skew-correction algorithm was published in “Various techniques used in connection with random digits.” (NIST journal, Applied Math Series, 12:36-38, 1951). Since the paper is hard to find online due to its age and publication date, I‘ve put a copy in my Google Drive account (PDF) for reference purposes.

The general idea behind Von Neumann’s skew correction is to consider sequences of rolls/coin-tosses/whatever instead of isolate ones while picking a sequence length long enough that an even number of possible outcomes has equal probabilities.

Explaining the Von Neumann skew-correction algorithm:

For dice, pick a sequence length where $n>2$. The reason for picking a sequence length of $n>2$ is that no subset of possible outcomes of equal probability for $n=1$ or $n=2$ has a cardinal divisible by $6$.

So, for this example, let’s simply take $n=3$. Doing so, the outcomes of any dice can be partitioned into 6 categories of equal probability according to the relative ordering of the successive numbers rolled – provided these numbers are all different.

We need this, so that sequences can be grouped according to whether the second number is greater – 1 – or smaller – 0 – than the first, and whether the 3rd number is greater 111,011 or smaller 100,000 than both the first and the second, or between them 110,001.

All 6 possible orderings will occur with equal probability because each of the sequences belonging to any of these orderings matches exactly one sequence of equal probability in every other ordering. Meaning: 1,2,4,1,2,4 matches the ordering 111, while 2,1,4,2,1,4 (which is equally likely to be rolled) matches 011.

EDIT

@fgrieu describes a different, yet equally practical implementation in his comment below.

Yes, die can be noticeably biased but i would be very surprised if the output of die from different manufacturers were to be bad enough to lead to any practical attack whatsoever of even something with requirements as stringent as that of a one-time pad (unless the dice were deliberately sabotaged).

Personally, if you are not allowed to use a computer i would do the following: get d6 dice from different manufacturers (at least 2 dice, look for die without rounded edges), build a 6x6 table (example below, but there could be many variations of this) and choose your characters from the intersection of 2 die rolls. If you want to determine if a letter is upper or lower case you could do something like a coin flip.

Keep building your key via this method until you have the desired output amount.

\|1|2|3|4|5|6|
1|a|b|c|d|e|f|
2|g|h|i|j|k|l|
3|m|n|o|p|q|r|
4|s|t|u|v|w|x|
5|y|z|0|1|2|3|
6|4|5|6|7|8|9|

Update:
I just noticed you said you needed to generate numbers only. here's a different table (but 16.67% of your rolls will be invalid):

\|1|2|3|4|5|6
1|0|1|2|3|4|5
2|6|7|8|9|0|1
3|2|3|4|5|6|7
4|8|9|0|1|2|3
5|4|5|6|7|8|9
6|R|E|R|O|L|L

6x6 table with 86.11% odds of only 2 dice rolls (with 2.77% odds of invalid roll) and 13.89% odds of 2 dice rolls + 1 coin flip:

\|1  |2  |3  |4  |5   |6
1|0  |1  |2  |3  |4   |5
2|6  |7  |8  |9  |0   |1
3|2  |3  |4  |5  |6   |7
4|8  |9  |0  |1  |2   |3
5|4  |5  |6  |7  |8   |9
6|0/1|2/3|4/5|6/7|8/9 |REROLL


Certificate public key keyexchange, Which key exchange is used in browsers? I have a question regarding the keyexchange happening in web browsers. If you check the certificate here on crypto.stackexchange you can go under details and see that the public key is type RSA (2048 Bits). Does this mean that StackExchange is generating a private key via RSA between them and me to encrypt my messages?

The RSA encryption algorithm implies two types of keys: a public key and a private key. The public key is composed from the public exponent $e$ and modulus $n$. The private key is composed from the private exponent $d$ and modulus $n$. The relationship between them is $(e,d)\ ≡\ 1\ (mod\ φ(n))$. To encrypt, you rise the plaintext to the power $e$ and to decrypt you rise the ciphertext to the power $d$ (both operations are done modulo $n$). More detalis here. The traffic between you and StackExchange is encrypted under the TLS protocol. The TLS protocol uses a hybrid encryption scheme. That is, you first generate a random key, say K, that you'll encrypt with RSA using the public key of StackExchange. The StackExchange will decrypt the key K using its private key.
From now on you will both use a symmetric algorithm (AES 256) to encrypt your data. The encryption key for this symmetric algorithm will be the K key, which you previously encrypted using RSA. More detils about TLS here.


Is this method of speeding up a symmetrical algorithm secure? (AES output joining) I was trying to find out a way of speeding up a given symmetrical algorithm the reason and programing launguage in this case are unimportant. I have came up with the following thing:

Divide data into n parts
Run n threads
Each thread encrypts its part of the data
Take the output of all of the threads and concatenate (join) all of them together

And for the decryption:

Divide the cipher text into the same parts that where joined
If feasible Run the same amount of threads as parts If not decrypt one after another
Join the outputs

Things that i can not do with my enviorment:

Change the algorithm code (I can only use encrypt and decrypt)

I am aware that i can use Electronic Code Book (ecb) for this goal but i would like it work for all modes.

My question is does the above method compromise security in any way?
If it does. To what extend?

Sorry for making any mistakes this is my first question

The issues here are not so much security wise (that's downstream of this topic) but pragmatism.  The penguin problem rules out ECB mode for most cipher use, so lets look at your requirements:-

  Divide data into n parts

The easy bit

  Run n threads

Not as easy as it sounds.  This is very language dependent.  For example Python doesn't do well with parallel tasks due to it's global interpreter locking system. Java threads can be cumbersome.  And then there is the inter-thread communication - more overhead and slowdown.  Even C/C++ threads will have to talk amongst themselves.  Will you write a thread pool yourself?  I guess there must be an extant library you could use as mitigation.

  Each thread encrypts its part of the data

The crux of the cryptography.  Have a close look through the wiki entry on cipher modes. You cannot hope to achieve parallel operation on all modes as that's fundamentally impossible for some as they're sequential.  CBC mode is a simple example of one ciphertext passing into another subsequent block operation. Yes it can be run with multiple threads, but each thread will be paused waiting for the previous one in the chain to complete. That said, CTR mode seems to be a mode that's suitable for your scheme.

  Take the output of all of the threads and concatenate (join) all of them together

Even in CTR mode the chunks have to come out in the correct order, requiring more thread collaboration. And again inter process communication has to be addressed which will siphon off   speed gains.

So in conclusion, and without even dealing with  specific security problems, this scheme is troublesome.  Since only a few modes are possible in this scenario, and their security issues are mode dependent, it is quite difficult to give more detail.  But just to mention a generic one, clones of the key and plaintexts will be floating around the machine that might open an attack vector.  And the time of complete thread destruction can be uncertain under a garbage collector.

This   falls into the realm of writing your own crypto, with key management, inter process communication and a large case of debugging. With modern CPUs featuring hardware AES circuity, that is clearly the way forward.  I cannot think of any circumstance that warrants this level of cryptographic development, testing (heartache) and security risk.  Remember that time is money if this is a commercial venture, and in that case does dubitable and possibly  marginal performance gains offset just getting a faster CPU?


Finding strong primes Wikipedia lists the following conditions for a prime to be strong:

$p-1$ has large prime factors. That is, $p = a_1 q_1 + 1$ for some integer $a_1$ and large prime $q_1$.

$q_1-1$ has large prime factors. That is, $q_1 = a_2 q_2 + 1$ for some integer $a_2$ and large prime $q_2$.

$p+1$ has large prime factors. That is, $p = a_3 q_3 - 1$ for some integer $a_3$ and large prime $q_3$.

This seems pretty vague to me. What does "large prime" mean? How large should $p_1$ be compared to $p$?

And, most important, what is the standard way to generate large strong primes, or to check if a large prime is strong? Also, is using safe primes (of the form $p = 2*q + 1$, where $q$ is a prime) safe and/or efficient?

All the properties discussed in the question are for strong primes $p$ in the context of using $p$ as a secret factor of a large composite $n$ which factorization should be intractable; these properties are given in the landmark RSA paper (1978), without justification. Properties thought for (often public) primes used in other cryptosystems can be different.

The first property

  $p-1$ has large prime factors. That is, $p = a_1 q_1 + 1$ for some integer $a_1$ and large prime $q_1$.

is intended to make factorization of $n$ using Polard's p-1 algorithm hard; this is relevant to some degree because this algorithm has a component of its cost proportional to the highest factor of $p-1$, where $p$ is the factor of $n$ exhibited by the algorithm.

Similarly, the third property

  $p+1$ has large prime factors. That is, $p = a_3 q_3 - 1$ for some integer $a_3$ and large prime $q_3$.

is intended to make factorization of $n$ using Williams' p+1 algorithm hard; this is relevant to some degree because this algorithm has a component of its cost proportional to the highest factor of $p+1$, where $p$ is the factor of $n$ exhibited by the algorithm.

One standard that considers the above is FIPS 186-4 (appendix B.3), with $q_1$ and $q_3$ required to be larger than 100 bits when $p$ is 512 bits (and optionally: $q_1$ and $q_3$ larger than 140 or 170 bits when $p$ is 1024 or 1536 bits). It is hard to tell quantitatively when it makes actual sense taking precautions regarding such properties  (beyond conformance to standards): it is pointless when generating a few two-factors RSA keys of at least 1024 bits; it might be useful when extremely many RSA moduli with relatively small factors (e.g. in multi-prime RSA) are generated, and an adversary would benefit finding the factorization of any modulus (rather than of a particular modulus); see this question and its answers.

The second property

  $q_1-1$ has large prime factors. That is, $q_1 = a_2 q_2 + 1$ for some integer $a_2$ and large prime $q_2$.

has to do with reducing the odds that an RSA cycling attack succeeds; see this answer. I fail to find a quantitative assessment of how big $q_2$ should be, or any modern standard with this requirement. I accept the consensus that RSA cycling attacks have negligible success odds for practical key sizes (but would very much appreciate a quantitative argument!).

The standard ways to generate a large strong prime $p$ with the first and third properties (perhaps the second if required) is to choose the auxiliary primes $q_2$ (if required) then $q_1$, and $q_3$, then generate $p$; rather than choosing $p$, then trying to exhibit $q_1$ (then $q_2$ if required) and $q_3$. The later approach would be very computationally intensive: if $p$ is a random 512-bit prime, it requires the factorization of a $(p-1)/2$ and $(p+1)/2$, which are mostly random 511-bit integers, and that's typically a hard job. The former approach (used in practice) introduce significant complexity, but relatively little computational burden; several such methods are detailed in the aforementioned FIPS 186-4 appendix B.3.

p−1 has large prime factors. That is, p=a1*q1+1 for some integer a1 and large prime q1.
p+1 has large prime factors. That is, p=a3*q3-1 for some integer a3 and large prime q3.
as said above.
To a length, if q1 and q3 are too big, there will be no primes between q1*q3 and 2^(length+1); or there are only few primes so that to be factored easily.


How can I encrypt a plain text of length l to a ciphertext of a different length I'm trying to encrypt a plain text (of length l) and output a ciphertext of length t, where t does not equal to l.
How do i get a ciphertext that is shorter than the plaintext input?
How about if I want a ciphertext that is longer than the plaintext?

Also, assume if I already have a encryption function E, such that E takes l bit plain text as input, and outputs a l bit ciphertext. How can I use E to create a new encryption G, such that G solves the above problem?

It is impossible to have a ciphertext shorter than the plaintext, while still being able to decrypt it. This is quite obvious: an $\ell$-bit ciphertext contains at most $\ell$-bit of information, so as long as the messages have more than $\ell$ bits of entropy, some information is lost (and if it is longer than $\ell$ bit but has very little entropy, then you can compress the message before sending it).

In the case of public key encryption, in fact, if your message is $\ell$ bit long, you cannot even have a ciphertext of length $\ell$ if you want some important security properties: encryptions schemes are usually required to satisfy semantic security, which states that if a ciphertext encrypts one of two messages, it is infeasible to determine which one it encrypts (even knowing the plaintexts). But this implies that many ciphertexts must correspond to a same plaintext: if a plaintext is associated to a single ciphertext, one can break this property just by encrypting the two messages and checking equality with the ciphertext. Therefore, to get a probability, say, at most $1/2^{80}$ for the encryption scheme to be broken, a ciphertext will be at least 80 bits longer than the maximum size of a plaintext.

If you want a longer ciphertext, just pad with zeroes. You can make the ciphertext as long as you want that way.

In TLS you would use an optional compression method. This is signaled in an implementation defined connection state which contains the null compression by default along with other things like current cipher sweet and is negotiated in the handshake. This would enable what you ask.

In TLS compression comes before encryption.


Operation which needs much computing power to be created, but just a little to be solved? Does somebody know a cryptographic/mathematic operation, that needs much computing power to be "encrypted"/"created" but doesn't need much power to be "decrypted"/"solved"?

Lots of problems are hard to solve but easy to check. For example:

finding hash pre-images of particular values such as 0
calculating discrete logs of small numbers modulo a prime
finding the factors of a large composite of a special form like $2^p-1$

I don't think there's an essential difference between solving and checking they're just arbitrary descriptions of the operations.

I imagine an unstated requirement of your question is that it should not be possible to pretend to have solved hard problems by generating random solutions and then saying that you arrived at the solution by solving the hard reverse problem.
This is a bit like shooting arrows randomly into a wood and then painting targets round the arrows wherever they have stuck in the trees.

Play with SBOX in AES. The encryption using the standard one is faster than the decryption. If you search you can find one with your specifications.


Is this an effective obfuscation technique? Long ago I created a simple program which obfuscated a file by taking the first byte, then XORing it with the second, taking the (original) 2nd byte and X-ORing with the 3rd, etc, down the line. The file size is unchanged, and I could invoke the same program to undo the obfuscation. No key or password was required. It was just a simple way to hide the contents of a file from casual view.

My Question Is: Does this result in a uniform distribution of byte values such that it appears to be encrypted, and the usual analysis would not turn up anything?

I know that this is not encryption. Also that the first byte is plaintext, but one could simply stick a random value in the source file, use a space or some other harmless byte there.

It sound like you're using something like an XOR cipher to obfuscate your code.  It will appear to be encrypted, but this can still be broken by frequency analysis since the use of a constant shift means that the encryption effectively has no key.  An example of how to break a similar XOR cipher can be found here.  As @iismathwizard mentioned, decryption requires no more knowledge than the fact that XOR is in use, in the same way as as ROT13 cipher might be broken

I would agree with @Biv regarding the strength of XOR encryptions are generally linked to the key. i.e. they are only as strong as the key stream.Conventionally, XOR encryption, relies on bitwise exclusive OR operation to generate the ciphertext since it is hardware efficient.

In LTE, ciphering of user data takes place in the Packet Data Convergence Protocol (PDCP) sublayer where IP packets are encrypted after their header is compressed.It relies on a 128-bit Advanced Encryption Standard (AES) modeXOR encryption before the digital modulation (QAM/QPSK) and OFDM pulse shaping procedures.

Generally, if XOR encryption is combined with additional means of randomizing the data, security might be increased. Alternatively, substitution, shifting of rows, mixing of columns or an XOR operation with a key shuffling will also improve the security.


How much would it cost in U.S. dollars to brute force a 256 bit key in a year? I am often told that any key can be broken and that it is only a matter of time and resources for any key to be broken. I know that this is technically true. However, I think that there is probably a point where it makes sense to say a key is uncrackable (for example, if it would cost 100 times the world GDP to crack it, it is essentially uncrackable without the help of an advanced alien civilization, etc.).

How much would it cost in U.S. dollars to brute force a 256-bit key using a strong algorithm such as AES or Twofish in a year?

I would also be curious to know what it would cost to crack a 128 bit key in a year.

I am asking this mostly out of curiosity. I do not know very much about cryptography, so please feel free to pick the algorithm of your choice if that matters. I am interested in how one would project the cost (assume you have to buy the hardware but you get to choose what hardware you buy).

The average cost of electricity in the US is $\$0.12$ per kWh. For a single server, I'll use 3741 kWh annually as an estimate. That would be about $\$450$ per year for one machine.

Let's say you can do $10^{14}$ decryptions per second. That is $3.15\times 10^{21}$ decrypts per year for one machine. You need to do (on average) $2^{255}$ decryptions in a year, so you would need $\frac{2^{255}}{3.15\times 10^{21}} \approx 1.84\times 10^{55}$ machines. To figure your cost you would multiply that by $\$450$ and get about $\$8\times 10^{57}$ or 8 octodecillion dollars. Gross world product, or GWP, is about $63\times 10^{12}$, so brute-forcing a 256-bit key would cost about $10^{44}$ times the GWP.

You can follow similar math to get the cost of brute forcing a 128-bit key.

Note:

I am completely ignoring hardware costs, maintenance, etc. The estimate above is for electricity only. We can take a hint from the NSA on this. You'd be a lot better off hiring a few thousand mathematicians and have them work on breaking the cipher as opposed to trying to brute-force it.

Anything is crackable if you take one part of the whole. The key is made up of "parts" and if you treat it as such it can solve your problem faster. Table the data then move forward simultaneously. 128 bits at 8 bits with 16 threads with 1.3 flops a minute with a true 2.67 ghz cpu can crack 128 bits in 11.67 hours...obviously you need to write the code to process the decryption based on the type of encryption.


Optimal way to bind two hashes Currently I have:

H1 = SHA256

H2 = SHA1

Both H1 and H2 have fixed length. What's the most efficient way to bind H1 and H2 together into H3? The goal is to maximize protection in case when one of them leaks.

For example:

H3 = H1+H2
H3 = SHA512(H1+H2)
H3 = ???

Length preserving is not needed. This should be calculated instantly so no KDF.

Thanks for your help.

EDIT: I plan to use it as password creation scheme. H1 and H2 should not be changed.

If H1 becomes known then the first part of H3 becomes known if you just concatenate, so that's not a good option.

A simple XOR could work as long as H2 remains secret to an attacker. However, if info about H3 can be retrieved by an attacker and H1 can be changed then the attacker can force H3 to a certain value. But XOR doesn't expand the hash value as you seem to require.

If H1 and H2 are hashed together, e.g. with a larger output hash then all the attacker can do is to try and change H1 until some kind of structure appears in H3. This is the best thing to do if you just rely on hash functions.

You state that you don't require a KDF because you're not dealing with passwords. This is however not a good argument; there are also KBKDF's that derive output key material from input key material (and do not deal with passwords).

HKDF is a KDF that does this: it takes input key material, extracts the entropy from H1 and H2 into a certain intermediate key material, and finally expands the key material to the requested size. So the most fireproof way of creating H3 is: H3 = HKDF(enc(H1, H2), "H3", outsize). Optionally you can also supply a salt or change the label ("H3") to create different output values. enc is an encoding of the values H1 and H2, it can be just concatenation if the size of H1 and H2 can never change.

HKDF just relies on HMAC, and HMAC just relies on a secure hash function. So it can generally be implemented even if it is not directly available.

But just SHA-512 will also work.

I would do the following to hide the output of either hash function (and prevent a flaw in one algorithm from compromising everything):

$H_1$ = SHA2-256( $secret_1$ )

$H_2$ = SHA3-256( $secret_2$ )

$H_3$ = $H_1$ $\oplus$ $H_2$

If you don't have access to SHA3-256 then using SHA2-256 on $secret_2$ should still be reasonable.


What is the purpose of update() in popular hash APIs? E.g., in Python's hashlib, update() basically merges in string buffer functionality into the object. Several other digest APIs I've seen have this pattern.

Considering this adds functionality that arguably doesn't belong here, why is this pattern popular?

Being able to generate hashes incrementally (by presenting parts of the string being hashed) is there for basically two reasons:

It's commonly useful in practice.  Quite often, we don't have the entire string in one contiguous segment; instead, we often have parts laying around separately.  For one simple example of this, consider the
HMAC
function; the inner hash is some preprocessed keying material, followed by the message being MAC'ed.  We could create a temporary buffer consisting of the HMAC inner key ("ipad") and the message, but why?
It's actually easy to do with our current hash function (including SHA-1, all the SHA-2 versions and SHA-3).  You appear to think that the Python hashlib library copies the parts of the message being hashed into a buffer, and then runs the hash on the entire buffer.  That's extremely unlikely to be how they implement it; instead, it is easy (with a small amount of side memory) to have the hash process the message in pieces.

So, the answer is: they provide this functionality because people find it useful, and its easy for the library to do.

I would argue that hash APIs wrap string buffer creation because leaving buffer creation up to the developer is a flaw waiting to happen. Consider hashing a set of words without inserting the word lengths in between - this construction could be exploited by an attacker to find collisions.


"Double Encryption" using the same cipher? When it comes to the words "double encryption", I cringe.  What I see is the following scenario play out.

Someone has plain text and they encrypt it with the AES cipher using the 14 round variant, so AES256.  Then they run that encrypted information, through again another 14 rounds thinking it is double encrypted.

In my mind, I think of it differently.  When I think of encryption and doubling it, I believe the strength of encryption, in the case of AES, as being tied to the number of rounds through the algorithm. So in this scenario, I think of double encryption as 28 rounds through the AES cipher.

In short - AES(28 round) > AES(14 round) + AES(14 round)

I have read some whitepapers on cascading encryption, but they referred to using two different ciphers, not the same cipher twice.

Is there anyone able to shed some light on this for me?

When I think of encryption and doubling it, I believe the strength of encryption, in the case of AES, as being tied to the number of rounds through the algorithm.

I don't believe that's the best way to think of things.
The strength of the encryption really is 'how much work does an attacker need to do to perform the attack'.
For a cipher, there are two strategies:

We can just go through all possible key values, and see which one 'works'

We can rely on cryptographical weaknesses within the cipher itself

Increasing the number of rounds can plausibly (not always, but in practice, appears to) make the cryptographical weaknesses within the cipher harder to exploit, but (unless increasing the number of rounds also increases the number of key bits), doesn't do anything to slow down brute force attacks (apart from a constant factor).
As far as we know, there are no known cryptographical weaknesses in
AES-256 (apart from some related key attacks, typically not applicable), and so adding more rounds doesn't increase security in any meaningful sense.
Now, it would look like running the text through two separately keyed AES-256 would double the number of key bits, and so significantly increase security.  However, it turns out that there is a better-than-bruce force attack; this involves encrypting the plaintext with all possible AES-256 keys, decrypting the ciphertext with all possible AES-256 keys, and then searching for a match.
Of course, the amount of work involved is ridiculous; it will never be the case that anything involving $2^{256}$ operations will be feasible; this can be shown by thermodynamics and the minimal amount of energy needed to perform any operation.
This implies that, barring a cryptographical advance that allows us to break AES-256 with significantly less than $2^{256}$ operations, it'll be safe.
Which leads us directly to the next topic:

I have read some whitepapers on cascading encryption, but they referred to using two different ciphers, not the same cipher twice.

This potential cryptographical weakness is precisely why people use distinct ciphers.  There might be a weakness in AES-256 that makes the cipher significantly weaker than our current understanding; however, if we perform AES-256 encryption, and then (say) Camellia-256 encryption, then the resulting cipher is strong unless both AES-256 and Camellia-256 are weak.  It is possible that there is a weakness in one of the two ciphers; it is considered far less likely that both contain weaknesses.

The method you laid out to double encrypt something isn't so good. Sometimes ciphers will interact strangely and could actually make that type of double encryption less secure than just using one (especially if independent keys are not used).

Here is a quote about a sneaky thing to watch out for if you are cascading algorithms, from Applied Cryptography, Second Edition 15.8 Combining Multiple Block Algorithms:

  If the second algorithm is vulnerable to a chosen-plaintext attack,
  then the first algorithm might facilitate that attack and make the
  second algorithm vulnerable to a known-plaintext attack when used in a
  cascade. This potential attack is not limited to encryption
  algorithms: If you let someone else specify any algorithm which is
  used on your message before encryption, then you had better be sure
  that your encryption will withstand a chosen-plaintext attack.

The safer way to go is to create a one time pad and encrypt that, and the cipher text (OTP XOR message) and encrypt that as well. Now your encrypted message is twice as long but decoding 1/2 of your double encryption tells you nothing about the other half.

This has some implications on the equivalent number of rounds but also on the equivalent key strength. Its over my head what those implications are but I think Wikipedia's final note is wrong about them (I believe using one weak encryption does not help at all with the second). The story of 3DES is good to show why sometimes cascading the same encryption algorithm does not increase the security in the way you think it should.