Tag Info

New answers tagged

0

By definition, "custom extensions" are custom: they are understood only by implementations which have been made aware of them; all other implementations consider such extensions as "unknown" and ignore them (unless the extension is marked "critical", in which case the implementations which do not recognize the extension must reject the complete certificate). ...


1

To detect tampering, you first have to define tampering. You are receiving a message; what would make it a "tampered" message and not the "genuine" message ? The usual definition of tampered/genuine uses the message source: at one point in space-time, the message was assembled or verified by an entity S, who declares it correct. This is the definition of ...


1

No The recipient must know something about the sender to detect tampering. Otherwise, there is nothing to distinguish the legitimate sender from someone who is tampering. There are a few choices for what the recipient knows: Shared secret key - to produce a MAC Sender's public key - to verify a signature Trusted third party's public key - to verify a ...


1

File name "extensions" are immaterial. There is no real standard for these few letters, only loosely maintained traditions. The PKCS#7 standard (now called CMS) describes how to encode and decode signed and/or encrypted and/or authenticated "messages" into sequences of bytes. How these sequences of bytes are stored or exchanged is completely out of scope; in ...


0

A simple Google search on "django client certificate" reveals this, and this, and this, which all answer to your question as: yes, Django can work with certificate-based client authentication. People don't do that often in practice, because client certificates work only if you can arrange for clients to have certificates, basically meaning that you must ...


4

They are two different services, that are not related. PK Signing service These keys use the CA's crown jewels. They are protected as much as they can. If they are lost, they will be Out of Business So they use network segmentation, firewalling, HSM's, armed guards, whatever it takes to secure them. Normal SSL website using a signed key (possibly but ...


0

To keep it short and simple. Is there a need for external trust? If what you wish to protect is for internal use only, there is no need for an external CA like GoDaddy or Symantec. With a deployment service you can provision the affected nodes with the CA cert used to create trust in the 'network'


1

A certificate is basically a binding between an identity and a public key, but there are details: The notion of "identity" which is most adequate for your situation is not necessarily the same as the notion of identity for a SSL server certificate (i.e. a server DNS name...). The lifecycle of the private key matters: who generates it, where it is stored, ...


2

Yes, this is from what i can tell, possible. In X509 you can use the SAN (Subject alternative name) value to specify free metadata for instance, if it's a username, a passphrase, you name it. This is used widely in enterprise solutions for personal authentication, it can be integrated with a SCEP server for more ease of use.


0

Basically, any CA does exactly what it wishes to do. However, OS and browser vendors won't accept just any CA as a "trusted root". E.g. Microsoft runs a root certificate program which defines the contractual conditions that a CA must fulfil in order to get its root CA public key included in the "trusted store" of all Windows systems. These conditions include ...


5

You are trying to do authorization with a physical device meant for authentication. This rarely works well. A smart card is used to authenticate the user, in that it contains a private key which remains under exclusive use of the owner. The certificate is a method by which the link between the public key and the owner's identity are distributed; it is ...


1

I wonder if I'm missing something, but why does the text file have to reside on the smart card? If your objective is to provide proof of user authority in the form of a signed document, whoever is "authorizing" the user should sign the file with their cert. (Sure, their private key can reside on a smart card if that is how it's issued, but the smart card ...


1

You are right encryption is mandatory for all WebRTC communications. All the communications are encrypted using Datagram Transport layer Security (DTLS), which is a derivative of SSL. DTLS is build in to all browsers that support WebRTC. In short the the keys for the peer-to-peer SSL connection are generated by the peers and exchanged over the signalling ...


1

Schneier's blog has a couple of clarifying statements: It is more likely that the NSA has some fundamental mathematical advance in breaking public-key algorithms than symmetric algorithms. and I personally am concerned about any constant whose origins I don't personally trust. The justification of the former statement of course is very ...


1

Yes, theoretically speaking, asymmetric cryptoalogorithms require the public key to be made public. However, depending on the algorithm in use, and the strength of the algorithm (no. of bits used, etc) some of these public keys can be broken to yield the private key. For example, if RSA cryptosystem is being used, it is generally advised to use atleast 1024 ...


16

Just to expand on a couple bits of info alluded to above, there are basically two risks to consider, neither of them relating to the algorithms (those are safe). First, is incidental data leakage. Do you run slaterockandgravel.com as Mr. Slate but have your key signed fflintstone@slaterockandgravel.com? Did Betty sign your key and you don't want the world ...


1

Generally speaking, in encryption there are two types of information: secret information and public information. Keeping secret information secret is like putting it in the big vault with a big door in a big bank like you see in the movies. Keeping public information secret is like putting a sign on the door that says "don't steal my stuff". Better to ...


4

The only risk to publishing your public key if your public key is signed by other people and you do not wish to reveal who signed your key (since that can be used to figure out who you have made connections with, casually or intimately).


1

PGP, GPG, SSH, and most public key systems already use symmetric algorithms internally. Internally, when you encrypt with a public key, the software/hardware first generates a symmetric key and encrypts your data with the symmetric algorithm. And then it encrypts that symmetric key with the public key (using an asymmetric algorithm) and stores the encrypted ...


2

This is not a question of size. The raw asymmetric encryption algorithm known as RSA can do asymmetric encryption for a "message" in a rather limited space; namely, with a 2048-bit RSA key and PKCS#1 v1.5 RSA encryption, the algorithm can process a sequence of bytes up to 245 bytes at most. But you never use the raw algorithm. You use a protocol, in this ...


52

None, that's why it is called a public key. It can not be used to access anything encrypted for you without solving math problems that are currently prohibitively difficult to solve. It is possible that in the future it may be possible to solve these problems and that would cause the public key to allow messages to be decoded, but there is no current known ...


0

I'm currently using GPG RSA keys to encrypt binary files. Many people recommend using symmetric keys to encrypt large files, and then encrypt the symmetric key with a public key. This is known as hybrid cryptosystem and is the way it is usually done, especially when the data sizes get bigger. Symmetric encryption by its very nature is always going to be ...


1

Any file size really. Symmetric cryptography provides a much, MUCH higher level of security. This is why we can use 128 bit symmetric algorithms but have to use 1024 or 2048 bit asymmetric algorithms. There are also a few attacks that make it easier to figure out certain asymmetric algorithms if you have a larger amount of structured data encrypted with ...


9

But, you have to publish your public key in order for people to encrypt messages that are intended for you. That is why you must publish your public key and have it signed by people you know (preferably personally). For more information: Web of Trust and Key signing Parties


6

The risks are of trust. Non-intuitively, if you don't publish your key, it's easy for someone to publish their own key and claim it's yours. A public key should be very public. Your best defense is to ensure your key is properly signed.


5

In general, self-signed certificates offer no security benefit over raw public keys (there can be convoluted situations where the self-signature provides a "proof of possession" of the corresponding private key, but this very rarely matters). Self-signed certificates can offer a usability benefit, though, in that it allows the use of certificate-based ...


0

I agree with the sentiments here, that it is very bad practice to send the private key and it would actually be almost impossible to do what you want. Why? Because you generate the private key on a smartcard. It is very difficult to mark private keys as exportable on smart card devices. It requires specific low-level knowledge of the smart card API, which ...


1

I think you are confusing quite a few things here: First of all: There are only very few crypto schemes that are perfectly secure from an information theoretic standpoint. One of these schemes is the One-time pad. One might argue that Quantum cryptography is a field that looks promising in this regard, too. However, none of these are practical and are only ...


1

can't comment, but I agree with @Tom's answer, with a few points to add: SSL/TLS server authentication depends on the "strength" of the server key -- both its size, which you can see, and that it was sufficiently random, unlike for example the Debian openssl packages a few years ago that used a crippled RNG or the thousands of apparently unattended devices ...


1

Your Web browser will always try to authenticate the server's certificate; it will complain loudly when it cannot. The point about optional authentication is for the "DH_anon" cipher suites in which there is no authentication at all. Such cipher suites are, by definition, insecure against active attackers, and thus should not be used. Web browsers don't ...


1

The setup you described is not ideal. It would be better to implement a certificate authority and setup everyone with their own private-public keypairs. There are schemes where you would then grant access to a shared resource using ACLs at the application level or by having a symmetric key which is used for access and encrypted with each person's public key. ...


0

There is no way to distribute the key to everyone and at the same time being able to withdraw access to anybody of the team. Possible solutions for encryption: The sender encrypts to all members of your team, each having his private key. If you need to have a single key, have a central "decryption service" where all team members can put stuff to decrypt ...


2

PFS usually involves ephemeral keys, i.e. keys that exist for the duration of the conversation but are thrown away later. One way to do this is to create an ephemeral RSA keypair for the duration of the conversation: Alice and Bob both have long-term RSA keys, and both know each others' public keys. Alice generates a 768-bit RSA keypair. This is her ...


1

I'm seeking to understand how Perfect Forward Secrecy (PFS) works for non SSL applications. Well, let's reiterate shortly what PFS is about: You want to prevent anyone getting your master key to be able to decrypt messages he has captured beforehand. For example, let's assume the case of SSL/TLS where the private key of the server certificate gets ...



Top 50 recent answers are included