# Tag Info

2

As can be seen by RFC 5280 (X.509), this structure is the SubjectPublicKeyInfo. This field is formatted as follows: SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } The AlgorithmIdentifier is defined as follows: AlgorithmIdentifier ::= SEQUENCE { algorithm ...

0

Since your problem is the signature size, I recommend you consider elliptic curve signatures instead of trying to roll your own RSASSA implementation. With RSA a 512-bit signature requires you to use a 512-bit modulus, which has been considered insecure for more than a decade. It's equivalent to something like 50-80 bit security at best. These days the ...

0

While I can confirm that your “feeling“ is indeed correct, the rest of your question is not that easy to answer. I’ll try to give you some insight nevertheless. Generally… The number of rounds depends on the design and security parameters of the individual ciphers. This makes it rather impossible to generalize things in form of “structure $A$ should use ...

1

References Related to your reference request: SHA512withRSA points to the RSA Signature Scheme with Appendix based on PKCS #1 v1.5 with SHA-512 hash function. This means you’re looking for reference documentation describing RSA PKCS1 v1.5 (see: RFC2313) signatures with SHA512 (see: RFC6234) hash and X.509 encoding format. Removing “overhead” from code As ...

0

The main difference is that secp256r1 is a prime field curve, while secp256k1 is a Koblitz curve. Koblitz curves are known to be a few bits weaker than prime field curves, but since we are talking about 256-bit curves, neither is broken in "5-10 years" unless there's a breakthrough. The other difference is how the parameters have been chosen. In secp256r1 ...

2

First secp256r1 is a random and secp256k1 is a Koblitz curve. So according to this article: Koblitz curves should be avoided, [...] as they does not have enough warranty on crypto analytic activity and effectively they are: Not part of NSA Suite-B cryptography selection Not part of ECC Brainpool selection Not part of ANSI X9.62 selection ...

2

I will start with an example and then comment on a natural general way to achieve re-randomization: ElGamal: Let’s say we have a multiplicative written group $G$ (suitable for ElGamal) with public key $h=g^x$ and $g$ generates $G$ (or some prime order subgroup of $G$). Any library that implements ElGamal encryption can do the following, although there may ...

0

I'm going to assume you are using binary Goppa codes. That means, that you take a support $\mathbf{L} \in \mathbb{F}_{2^m}$, a Goppa polynomial $\Gamma$ of degree t with coefficients in $\mathbb{F}_{2^m}$ and build all codewords of a GRS code, and then intersect these with $\mathbb{F}_2^n$, resulting in a code that is actually a subset of $\mathbb{F}_2^n$ ...

1

Wrapping my (now deleted) comments into an answer… OMAC, as described in the OMAC spec and its addendum, is what Rogaway et al provide security proofs for in their EAX paper. If you take a quick look at RFC 4493, you’ll notice that it states: The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message ...

1

I read about the AEZ encryption scheme as presented at the CAESAR competition. To me it seems like a construction of an arbitrary length block cipher from a smaller one. The construction is only used in the v1.x of AEZ, because it requires appriximately 1.8 AES calls per block of plaintext, while the one used in v2.0 requires only 1 AES per block ...

1

All of them can be used to deal with unreliable, unordered datagrams; as long as you can derive an IV for the UDP packet then a cipher mode of operation should succeed. You need some kind of unique method of identifying the packet of course. Note that (the information used to generate the) IV may be public. Usually you need some way of identifying the ...

4

You basically want a full disk encryption mode for a block cipher; XTS mode seems to be the current standard. In your case each "disk block" is actually a file offset. Note that using a stream cipher or counter mode is NOT secure if the data is ever modified in the file, as it would violate the cardinal sin of using the same key and initialization vector to ...

4

The Secure Hash Standard and corresponding FIPS-180/202 do not specify any hash to meet a security requirement above 256-bits (using a 512-bit hash). This is unlikely to change. SHA-2 was built with state and word sizes to meet the security requirements on commodity computers (x86 and Alpha), which use 32 and 64-bit maximum CPU word sizes for general ...

Top 50 recent answers are included