# Tag Info

176

These types of cryptographic primitive can be distinguished by the security goals they fulfill (in the simple protocol of "appending to a message"): Integrity: Can the recipient be confident that the message has not been accidentally modified? Authentication: Can the recipient be confident that the message originates from the sender? Non-repudiation: If the ...

85

An ASN.1-encoded SSH private key contains the following integers in order: The public modulus $n$ and exponent $e$; The private exponent $d$; The prime factors $p$ and $q$ of $n$; The "reduced" private exponents $d_p=d\bmod(p-1)$ and $d_q=d\bmod(q-1)$; The "CRT coefficient" $q_{\text{inv}}=q^{-1}\bmod p$. The observation that the value of $d$ in such a key ...

39

I'm considering switching to ECDSA, would this require less space with the same level of encryption? The answer to that question is yes, both ECDSA signatures and public keys are much smaller than RSA signatures and public keys of similar security levels. If you compare a 192-bit ECDSA curve compared to a 1k RSA key (which are roughly the same security ...

32

Mathematically it work just fine. "Encrypt" with the private key, "decrypt" with the public key. Typically, however, we say sign with the private key and verify with the public key. As stated in the comments, it isn't just a straight forward signing of the message $m$. Typically a hash function and padding is involved. Also, often one has a separate key ...

23

A few observations: RC4 suffers from related key attacks. This means your idea of concatenating a 224 bit key and a 32 bit IV is not a good idea. You should rather use $\operatorname{SHA-256}(Key\mathbin\|IV)$ Remember that a (Key, IV) pair must not be reused, ever. A 32 bit IV can work if it's a counter, but IMO such a scheme is unnecessarily fragile. I'd ...

22

Asymmetric encryption and signing are entirely distinct concepts. The security and construction requirements are completely different. (Encryption for instance, needs to be an injection, whereas signature verification needs to be a surjection towards the verified message space. As a further hint of how they are intrinsically different, note that it lasted ...

21

Can someone explain why is that the case? Cryptosystems based on finite sets have two very nice properties: There is an upper bound to the size of all involved mathematical objects. This also allows one to predict things like memory usage rather well. This also means that the precision / memory you need can't grow arbitrarily / infinitely. You can actually ...

20

The two keys $(e,m)$ and $(d,m)$ in the RSA key pair are fully equivalent, in that $e$ and $d$ can be arbitrarily chosen integers (in the interval $0..m-1$) as long as they fulfill the well-known congruence $ed \equiv 1 \mod \phi(m)$. You can swap them and nothing will change. A key becomes public the moment you (as the key generator) decide to disclose it, ...

20

What happens if the sender is at another point in the sequence? ... the key is pressed while out of range to the car. In a rolling code (code hopping) system, the keyfob transmitter maintains a synchronization counter C, incremented every time a button is pushed. The car receiver stores the most recent validated synchronization counter it has received N. ...

19

Secure communication doesn't need blockchains. We have AES and digital signatures for that. Correct, though we also require tools other than block ciphers and digital signatures. But that is besides the point, as "blockchain" is not on that list. Blockchains are only useful for documentation. Not for securing anything. Blockchain is a ...

18

TL;DR No, the approach is not secure. Use a standard like CMAC instead. Or even better, check your AES accelerator module to see if it supports any AEAD modes of encryption like GCM, CCM, EAX. Long Version In order for a message authentication code (MAC) to be secure, an adversary with oracle access to the MAC (basically this means the adversary can send ...

17

Would it not be easier simply to send $E(m||s,k)$ where s is a salt shared across the system? Yes, that would be simpler; however, that would not (in general) be secure. The assumption you are making is that if someone modifies the ciphertext in any way, then the last few bits of the resulting plaintext must also be modified. This is often not the case: ...

16

Short version: SPKI links not only names, but authorizations to keys. Also, it uses a better syntax (S-expressions) than X.509 certificates. Long version: What problem does it solve? Both the traditional CA-based public-key infrastructure (PKI) and PGP's web of trust (and other similar systems) do mainly one thing: Linking names to public keys. The idea ...

16

Authentication and probabilistic encryption are two desirable features which each take up a small amount of extra space. And you are absolutely right that the percentage of space consumed is of no concern in most scenarios. But as the other answers also point out that means you can no longer fit a logical sector inside a physical sector of the same size. ...

16

Mostly, I would say that finite groups get used in crypto because they're a good way to describe things that naturally appear in many crypto schemes. For example, going way back to the early days of cryptography, consider the simple Caesar cipher, where you replace every letter with the one $n$ positions after it in the alphabet, wrapping around from Z back ...

15

If k is a constant, such as 3, it becomes possible to select a pair (N,g) such that the discrete log of k to the base g is known, which would enable the two-for-one guessing attack again.

14

This is an active area of research. There have been attempts at creating usable security tools and lots of user studies of existing tools (typically with critical results). A good anthology for work in this area (a few years old now) is Security and Usability edited by Lorrie Cranor and Simson Garfinkel. There is also a workshop every year called Symposium ...

14

There's an obvious solution using DH: Alice has a private key $a$ and a public key $g^a$; Bob has a private key $b$ and a public key $g^b$. When Bob sends a message, he computes the shared secret value $(g^a)^b$, converts that into a MAC key (possibly using a nonce to prevent key reuse), computes the MAC of the message, and sends the message and the MAC (...

14

The usual answer is that a salt can be make public; if that was a problem, then the salt would not be called a "salt" but a "key". In some protocols, unauthenticated obtention of the salt is the norm, and is not considered to be a problem. E.g. with SRP, a password-authenticated key exchange, where any salting and hashing must necessarily occur client-side. ...

14

Answering the question in your title (and not addressing your proposed alternative which I don't quite understand) there is a zero knowledge proof of password protocol "SRP" which is fast and effective. SRP does not seem to have been given as wide publicity as it should get. Having implemented it, and being an advocate of its use, I don't really understand ...

14

So, are there reasons for not using authentication that I'm missing? I believe that the real reason is not actually space, but time. As you said, storing the tags would not require that much space. However, the tags need to be stored somewhere, and whenever you read the sector, you also need to read the sector containing the tags as well. So, unless you ...

13

I've been suggested to digitally sign it, thus, I have my private key, and I ship my application with a public key, and the application then uses the public key to check the QR code As long as you can live with the requirements for RSA (signature size, computation), that sounds like an excellent idea. Am I encrypting the whole message using the private ...

12

You could encrypt them using some key derived from the user's password (to your site). Of course, this assumes that you get your user's passwords in plain text (or in any form which is always the same) - thus you need to have an encrypted connection to your user. Do not allow any non-SSL login. You can use some key derivation function like PBKDF or bcrypt ...

12

With 4096-byte sectors, space is a complete non-issue, less than 1 % Problem 1: 10GB per TB is not a "complete non-issue" for many people. Problem 2: If the checksums are inside of their data blocks, there is a huge compatibility problem. The data per block is less than 512/4096, but many (really many) programs and kernel parts of pretty much all ...

11

The authentication tag is defined as an output parameter in GCM (see section 7, step 7 of NIST SP 800-38D). In all the API's I've encountered it's appended to the ciphertext. Where it is actually placed is up to the protocol designer. The protocol designer may well consider the place behind the ciphertext as ad hoc default though. The name "tag" of course ...

10

Cryptography is being a lot of places already and people might just know about it. For example, whenever you access an HTTPS page, that's cryptography protecting you. For desktop applications, many people use the Truecrypt application to protect their files. You also see a similar application in Windows BitLocker. As for why more people aren't using ...

10

No, RC4 is not completely broken. It is possible to use it properly. It's just not very likely that an average developer will do so. RC4 is not a good choice for new systems. It is tricky to use properly. There are some serious pitfalls which, if you're not an expert cryptographer, can bite you in the butt. In fact, if you take a quick look in the ...

10

An OCB like mode seems impossible with stream-ciphers. It's coupled tightly to the concept of a keyed permutation i.e. a (tweakable) block-cipher. Many authenticated encryption actually combine two distinct primitives. It's just that the specification and API only expose the combination. Essentially these xor a key-stream into the message to encrypt it (i....

10

For P2P authentication, you can go for web of trust concept. Simply this means, if someone is trusted by people you can trust, you can also trust that unknown person. In OpenPGP, a certificate can be signed by other users who trust the association of that public key with the person or entity listed in the certificate. So trust relationships can be propagated....

10

It is not secure, because an attacker can "mix and match" the output blocks from different authentication tags on different input messages, or repeat output blocks for repeated input blocks. For example, if the attacker knows the tag $F_k(m)$ for a one-block message $m$, then it can forge the correct tag $F_k(m) \mid F_k(m)$ for the two-block message \$m \...

Only top voted, non community-wiki answers of a minimum length are eligible