What is the difference between encrypting and signing in asymmetric encryption? [closed]

Question

What is the difference between encrypting some data vs signing some data (using RSA)?

Does it simply reverse the role of the public-private keys?

For example, I want to use my private key to generate messages so only I can possibly be the sender. I want my public key to be used to read the messages and I do not care who reads them. I want to be able to encrypt certain information and use it as a product-key for my software. I only care that I am the only one who can generate these. I would like to include my public key in my software to decrypt/read the signature of the key. I do not care who can read the data in the key, I only care that I am the only verifiable one who can generate them.

Is signing useful in this scenario?

Gilliland

I’m voting to close this question because it is not about programming as defined in the help center. Probably more suitable at Cryptography – Augean

@Tomerikoo, what's more important: following the letter of the rules in the help center, or their spirit - noticing that this question has been upvoted and bookmarked by hundreds (and valued by tens of thousands) of users, and left alone since 2009? – Colucci

@DanDascalescu I didn't claim that this question is not helpful or should be deleted. It was posted long ago when the rules were a bit different and therefore it was found useful by many. To be honest, leaving it open is more likely to attract repeated/low-quality answers that will just lower its value. Of course, I might be completely wrong. You are free to vote to reopen the question or raise a Meta about it. I will stand corrected if the community thinks such questions should stay open – Augean

@Tomerikoo: what makes you think it will attract low-quality answers, instead of new answers that have become available in the meantime? Has this-now-offtopic question attracted low-quality answers? Why not let the mechanisms for dealing with low-quality answers (votes, flags) work? – Colucci

Answer 1

When encrypting, you use their public key to write a message and they use their private key to read it.

When signing, you use your private key to write message's signature, and they use your public key to check if it's really yours.

I want to use my private key to generate messages so only I can possibly be the sender.

I want my public key to be used to read the messages and I do not care who reads them

This is signing, it is done with your private key.

I want to be able to encrypt certain information and use it as a product key for my software.

I only care that I am the only one who can generate these.

If you only need to know it to yourself, you don't need to mess with keys to do this. You may just generate random data and keep it in a database.

But if you want people to know that the keys are really yours, you need to generate random data, keep in it a database AND sign it with your key.

I would like to include my public key in my software to decrypt/read the signature of the key.

You'll probably need to purchase a certificate for your public key from a commercial provider like Verisign or Thawte, so that people may check that no one had forged your software and replaced your public key with theirs.

Woods

Technically speaking, when you say the private key is used to write the message's signature, you're saying that the hash of the message is being encrypted with my private key? – Cageling

@AndyIbanez: what is encrypted (the digest) may also include timestamp and some random salt, but yes, that's the gist of it. – Woods

@Woods In fact when we say 'sign with the private key', it means not 'encrypt' but instead means 'decrypt'. Sign the message roughly speaking is the same as decrypt with the private key and in the receiver encrypt with public key, this way the hash will became the same and could be compared. – Obstetric

@JohnnyWiller: actually its makes little sense to speak of "encrypting" or "decrypting" the digest: by itself, it's equally cryptic both before and after. It's better to say "apply the public key to the digest, hash function to the message and see if the results match". – Woods

@Woods yes, the sign function is different from encrypt or decrypt functions, the are other things involved in the sign process. But the mathematical core is the same as decrypt function. As you said, it's better to say apply the keys to the digest :) – Obstetric

@JohnnyWiller: as @slim mentioned below, the mathematical core is the same for both encrypt and decrypt functions. They are not separate functions, they are the same function f(key, message), such that f(private, f(public, message)) === f(public, f(private, message)) === message – Woods

@Woods you are, I have made a big misunderstood, sorry – Obstetric

The last paragraph mentionning the use of certification authorities to check the integrity of your key embeded with your app only make sense if the application is web based as the public keys of all of the major certificate authorities are embedded in the browser). Outside a web browser (in an downloaded app for ex.), it doesn't make sense to rely on certification authorities as you'll have the same pb to verify that those public keys were not replaced by fraudulent ones too. Back to square one... – Dillon

If companyA has publicKeyA, and privateKeyA && companyB has publicKeyB and privateKeyB also publicKeyB = publicKeyA. Then why can't both companies decrypt each other's file? Even though they both have the exact same encryption? What is the barrier in between them? – Doug

@asma22: they can. In your setup, privateA == privateB as well, which means the companies have the same key pairs. – Woods

@Woods You mean for every public key there is only 1 possible private key? – Doug

So if you were to get a certificate from Verisign...you would go to them and say hey my public key is 2xC87SomeOtherCharacters and in theory they could “We're sorry some other company has already created this exact public key, try getting another one”. But chances for this to happen are SUPER slim. Am I understanding this right? – Doug

@asma22: they would never say that because that would put that another company at risk and allow you to decrypt their data. This happening would mean that either you are reusing your own private key or have somehow managed to steal theirs (in which case the certificate in question should be revoked immediately). Chances of this happening accidentally for all practical purposes are zero. – Woods

Let us continue this discussion in chat. – Doug

@Honey Nobody has any procedure for handling that because there is no known means of detecting it. Every known mechanism has a failure rate higher than the probability of the event occurring. (It's like if there's a one in a million chance you have a disease and you take a test that has a one in a hundred chance of a false positive. Even if it says you have the disease, it's still more likely that you don't.) – Scull

@DavidSchwartz not sure what comment you were addressing...Where you addressing this comment? : "If me and you create 10^50000000 public-private keys, isn't there any mathematical chance that the generated public private keys of me and you one would have at least 1 common pair?" – Doug

@Honey Yes. That one. Whatever algorithm you use to detect a common pair, it will have some failure rate if implemented on an actual, physical computer. That failure rate will be higher than the probability of a collision in any realistic scenario. Thus, if you did think you detected such a collision, it's more likely a bug in your code or a physical failure in your hardware than an actual collision. So what do you do? – Scull

@JohnnyWiller Actually I really would like to understand what you mentioned "sign with private key is actually a decryption process". Why it is decryption process instead of encryption ? – Telemann

@Dreaminthewind as pointed in the comments above, I've made a terrible mistake. Actually decryption and encryption are the same thing in RSA – Obstetric

@DavidSchwartz is it correct to say if you're just encrypting something then you can generate your own public/private key without any cost, but if you're signing then you need a certificate authority involved hence there is a cost? – Doug

@Honey no it's not. Generating the key pair is free. The cost is involved in making the others believe the signature is really yours. To do that, you have your public key itself, which you have earlier generated for free, signed by an authority which might or might not charge you money for that. – Woods

Thanks. one more question: when I sign my iOS app of 100000 lines of code, is the hashing/signing done to all my 100000 lines of code? or something else? – Doug

@Honey your code gets hashed first (mapped into a short string using a well-known algorithm) and then the hash is "encrypted" with Apple's private key. For a good hashing algorithm, there is no known way to alter your code so that the hash would remain intact. But yes, all your lines of code do contribute to the hash, so if you change but a single byte in any of those lines, the hashing algorithm would produce a different result. – Woods

1. "your code gets hashed first (mapped into a short string using a well-known algorithm) and then the hash is "encrypted" with Apple's private key. " <-- so far there is no signature of mine that is part of this. So do I sign that which was encrypted with Apple's private key with my own private key? 2. Curious, does that well-known algorithm have a name? – Doug

@Honey: I'm sorry, I misread your question. I don't know how do iOS signatures work in detail, honestly. On their page it says "it must be signed with a certificate issued by Apple", which supposedly means that it's you who is signing your code using your private key, and your public key is signed by Apple with their private key. – Woods

probably a stupid question of me but, when you say in the end : "You'll probably need to purchase a certificate for your public key from a commercial provider like Verisign or Thawte, so that people may check that no one had forged your software and replaced your public key with theirs." could this not be done by SIGNING this public key, by a second private key of yours ? or is this a dumb thing to say and am i completely misunderstanding the whole thing ...? thx in advance – Geezer

@SamJanssens: of course you can sign your public key with your own private key, but then how would people know this second private key (and the corresponding public key) are really yours and not someone's pretending to be you? Well-known security providers' public keys come bundled with OS distributions. If you use them, your customer's crypto library would trace the chain of keys to a root certificate that came with their OS and which the OS manufacturer hopefully has checked. If you use a self-signed certificate, there is no way for the customer to know if it's really yours. – Woods

Answer 2

In RSA crypto, when you generate a key pair, it's completely arbitrary which one you choose to be the public key, and which is the private key. If you encrypt with one, you can decrypt with the other - it works in both directions.

So, it's fairly simple to see how you can encrypt a message with the receiver's public key, so that the receiver can decrypt it with their private key.

A signature is proof that the signer has the private key that matches some public key. To do this, it would be enough to encrypt the message with that sender's private key, and include the encrypted version alongside the plaintext version. To verify the sender, decrypt the encrypted version, and check that it is the same as the plaintext.

Of course, this means that your message is not secret. Anyone can decrypt it, because the public key is well known. But when they do so, they have proved that the creator of the ciphertext has the corresponding private key.

However, this means doubling the size of your transmission - plaintext and ciphertext together (assuming you want people who aren't interested in verifying the signature, to read the message). So instead, typically a signature is created by creating a hash of the plaintext. It's important that fake hashes can't be created, so cryptographic hash algorithms such as SHA-2 are used.

So:

• To generate a signature, make a hash from the plaintext, encrypt it with your private key, include it alongside the plaintext.
• To verify a signature, make a hash from the plaintext, decrypt the signature with the sender's public key, check that both hashes are the same.

Lerma

Why do you even need to make a hash of the plaintext in that scenario? Is it only for saving bytes when the plaintext is long? – Postrider

For those from Google, I answered my own question with information from Wikipedia. – Postrider

Your first paragraph does not apply to asymmetric keys. – Ginni

@headcode it only applies to asymmetric keys. Symmetric keys don't come in pairs. – Lerma

In fact, it only applies to RSA keys. With ECDSA keys, for example, you can trivially generate the public key from the private key, and the private key is a scalar while the public key is a coordinate. – Scull

How can you decrypt messages with PUBLIC keys? Aren't messages only decrypted with private keys? – Ovular

@Ovular It depends which encryption scheme you are using. In the case of RSA, you can encrypt with either and decrypt with the other. – Brockie

Wont there be any scenario that sender uses his private key to encrypt the message( other than using it for producing the signature.)? is public key cryptography only used for sending encrypted messages to someone using his public key , and NOT the other way around? – Wordbook

@Wordbook if you encrypt with a private key, then anyone with the public key can decrypt. Since the public key is not a secret, there's little point in doing that, except to produce a signature. – Lerma

5 sources contradicting this answer 1, 2, 3, 4, 5 – Allene

First source in above comment is last (at the moment of writing) comment on the question. It starts with bold "Warning". In second source read the first sentence of second paragraph. 3rd, 4th , and 5th sources explain confusion that surrounds comparison of signing to "encrypting with private key". – Allene

@Lerma Please examine sources in the comment above and edit your answer to be more correct and/or specific to avoid confusion. (PS: I find source #4 to be the most throughout and most well explained). – Allene

@alex you'll have to tell me specifically which part you think is wrong. I've re-read and it all seems accurate and precise to me. – Lerma

@Lerma thanks for reply. actually, I decided to do a bit more research. maybe I will delete my comments. hold on... :) – Allene

It's not arbitrary which one you call public and private. You can generate the public key from the private key, but you cannot generate the private key from the public key. Isn't that a big difference? – Whiteness

What is usually used as the plaint-text? Email addresses or names? – Fachini

@Fachini a plaintext is anything you want to encrypt. For example a single message in a chat, or a whole document. – Lerma

Does this mean that if there is both data encryption and digital signing involved there are 4 keys (2 different key pairs) involved? – Quinine

@Quinine Yes. The sender uses their own private key to sign, and the recipient's public key to encrypt. The recipient uses their own private key to decrypt, and the sender's public key to validate the signature. – Lerma

Answer 3

There are two distinct but closely related problems in establishing a secure communication

1. Encrypt data so that only authorized persons can decrypt and read it.
2. Verify the identity/authentication of sender.

Both of these problems can be elegantly solved using public key cryptography.

I. Encryption and decryption of data

Alice wants to send a message to Bob which no one should be able to read.

• Alice encrypts the message with Bob's public key and sends it over.
• Bob receives the message and decrypts it using his private Key.

Note that if A wants to send a message to B, A needs to use the Public key of B (which is publicly available to anyone) and neither public nor private key of A comes into picture here.

So if you want to send a message to me you should know and use my public key which I provide to you and only I will be able to decrypt the message since I am the only one who has access to the corresponding private key.

II. Verify the identity of sender (Authentication)

Alice wants to send a message to Bob again. The problem of encrypting the data is solved using the above method.

But what if I am sitting between Alice and Bob, introducing myself as 'Alice' to Bob and sending my own message to Bob instead of forwarding the one sent by Alice. Even though I can not decrypt and read the original message sent by Alice(that requires access to Bob's private key) I am hijacking the entire conversation between them.

Is there a way Bob can confirm that the messages he is receiving are actually sent by Alice?

• Alice signs the message with her private key and sends it over. (In practice, what is signed is a hash of the message, e.g. SHA-256 or SHA-512.)
• Bob receives it and verifies it using Alice's public key. Since Alice's public key successfully verified the message, Bob can conclude that the message has been signed by Alice.

Leede

So when you sign the message, do you sign the actual message itself or the encrypted message? – Freud

@Freud You typically sign a hash created FROM the msg, usually referred to as a Message Digest (MD). See the "...in practice, what is signed" portion of sivaprakash answer – Rand

So anyone can read Alice's message by using the shared public key, right ? – Pegeen

@AyoubBoumzebra Anyone who has access to Alice's public key can only confirm if the message is coming from Alice OR NOT. They cannot read the message because Alice encrypted the message using Bob's public key, so only Bob can decrypt the message using his private key and read it successfully. – Bifocals

So both are same - encrypt with one & decrypt with other . just the purpose (perspective) makes the difference, right ?. if i dont share public key to people (either everyone or few) ,they can decrypt using my public key + the fact they decrypt it means msg was generated by ne – Gradey

Yes, technically they are same, but different from the process perspective. In encryption, msg is encrypted using PUBLIC KEY of the receiver and the receiver decrypts it using its PRIVATE KEY of its own. But In Signing, the msg is signed using PRIVATE KEY of the sender and receiver can verify the identity of the sender using the PUBLIC KEY. – Deserve

Answer 4

Yeah think of signing data as giving it your own wax stamp that nobody else has. It is done to achieve integrity and non-repudiation. Encryption is so no-one else can see the data. This is done to achieve confidentiality. See wikipedia http://en.wikipedia.org/wiki/Information_security#Key_concepts

A signature is a hash of your message signed using your private key.

Unfriendly

Answer 5

Signing is producing a "hash" with your private key that can be verified with your public key. The text is sent in the clear.

Encrypting uses the receiver's public key to encrypt the data; decoding is done with their private key.

So, the use of keys is not reversed (otherwise your private key wouldn't be private anymore!).

Slunk

In normal Asymmetric encryption, encryption is done with the recipients public key, not your private key. – Gilliland

Did you miss that this question was specifically about RSA where the use of the keys is reversed and where it does not compromise the private key. – Scull

Answer 6

Functionally, you use public/private key encryption to make certain only the receiver can read your message. The message is encrypted using the public key of the receiver and decrypted using the private key of the receiver.

Signing you can use to let the receiver know you created the message and it has not changed during transfer. Message signing is done using your own private key. The receiver can use your public key to check the message has not been tampered.

As for the algorithm used: that involves a one-way function see for example wikipedia. One of the first of such algorithms use large prime-numbers but more one-way functions have been invented since.

Search for 'Bob', 'Alice' and 'Mallory' to find introduction articles on the internet.

Raouf

Can you comment on my use case? I want to use a private key to encrypt and a public key to allow anyone and everyone to decrypt. – Gilliland

It's not true that all asymmetric encryption is based on prime numbers, it's just the most well-known example (RSA); there are other methods such as elliptic curve cryptography. – Metternich

Answer 7

You are describing exactly how and why signing is used in public key cryptography. Note that it's very dangerous to sign (or encrypt) aritrary messages supplied by others - this allows attacks on the algorithms that could compromise your keys.

Metternich

Don't web browsers encrypt arbitrary data when using SSL? – Bechuana

@IanWarburton: But they don't use asymmetric encryption for that. The actual data transfers use symmetric encryption with a randomly generated session key. – Metternich

Does signing and encrypting a session key or a hash of actual data count as signing or encrypting arbitrary data? – Bechuana

@IanWarburton: no, because neither would be chosen by an attacker. The danger lies in encrypting or signing something directly supplied by an attacker, because that can very deliberately crafted to reveal information about your private key, or even create signatures that appear valid for something you did not intend to sign. A detailed breakdown of how the latter case works for RSA is here: crypto.stackexchange.com/questions/35644/… – Metternich

But if a hacker has a public key they can encrypt things to their heart’s content. – Bechuana

@IanWarburton: that's why RSA requires padding, so you never encrypt only a chose message: en.wikipedia.org/wiki/… - but it's really the operations that involve the private key (like signing) that are especially vulnerable against chosen input. – Metternich

Answer 8

Signing indicates you really are the source or vouch for of the object signed. Everyone can read the object, though.

Encrypting means only those with the corresponding private key can read it, but without signing there is no guarantee you are behind the encrypted object.

Acarpous

If the message gets decrypted by my pubic key then only I could have sent it. (Assuming my private key is not compromised) – Steato

Answer 9

What is the difference between encrypting some data vs signing some data (using RSA)?

Encryption preserves confidentiality of the message ("some data"), while signing provides non-repudiation: i.e. only the entity that signed it could have signed it. There are functional differences as well; read on.

Does it simply reverse the role of the public-private keys?

Absolutely not. The use of the same private keys for signing and decryption (or, likewise, the same public keys for verification and encryption) is frowned upon, as you should not mix purposes. This is not so much a mathematical issue (RSA should still be secure), but a problem with key management, where e.g. the signing key should have a shorter live and contain more protection before it is used.

For the same message, you should use the senders private key for signing and the receivers trusted public key for encryption. Commonly sign-then-encrypt is used otherwise an adversary could replace the signature with his own. Likewise you should use the private key of the receiver for decryption and the trusted public key of the sender for verification.

Furthermore, you should understand that signature generation doesn't use "encryption with the private key". Although all RSA operations are based upon modular exponentiation, the padding scheme is entirely different for signature generation. Furthermore, the public key has entirely different properties than the RSA private key in all practical uses of RSA.

For example, I want to use my private key to generate messages so only I can possibly be the sender.

That's non-repudiation property, which can be achieved by signing.

I want my public key to be used to read the messages and I do not care who reads them.

The public key should be considered known by all. If you want everybody to read the messages, then you simply do not encrypt them.

Signing will generally not influence the content of the message. The message is is considered separate from signatures. Officially such signatures are known as "signatures with appendix" where the appendix is the message. It's a bit weird name as the message is considered more important than the signature over it, but yeah. Only few signatures offer (partial) message recovery; they are not used much anymore and are generally considered deprecated.

Note that signature protocols such as CMS may deploy a container format that includes both the message and the signature. In that case you'd need first get the - still unencrypted - message out of the container, much like unzipping a file from a plain .zip archive. So the message may be hidden from view and cannot be directly used in that case.

I want to be able to encrypt certain information and use it as a product-key for my software. I only care that I am the only one who can generate these.

Encryption is used to achieve confidentiality. In the past RSA signature generation was often thought of as "encryption with the private key". However, the operations are quite different as explained above, and the later standards desperately try and separate encryption and signature generation.

I would like to include my public key in my software to decrypt/read the signature of the key. I do not care who can read the data in the key, I only care that I am the only verifiable one who can generate them.

Yes, this is called establishing trust in the public key. However, protecting your program code is very different from protecting messages. You can perform code signing but then you'd need something to check the signature outside of your code. There are operating systems that offer this.

There is Microsoft Authenticode for instance. Application stores like the iStore and Android app store may or may not use code signing, but they offer some reassurance that your application isn't cloned or at least not cloned within the store. Cryptography is not always the solution after all.

Keeping your code from being cloned / altered at all is much harder, and you'd be solidly in DRM territory if you go that way.

Is signing useful in this scenario?

Yes, absolutely. It can certainly help making sure that the messages were only signed by you, if there is trust in the public key. If it can be helpful for authenticating your application code / integrated public key depends entirely on the environment that you expect to run the code in.

Agustinaah

"In the past RSA signature generation was often thought of as "encryption with the private key". However, the operations are quite different as explained above, and the later standards desperately try and separate encryption and signature generation." - this is not clear to me. Either KeyPair can be the pk or sk and what one encrypts the other can decrypt. If we agree on that, then how can we argue that signing and encrypting are distinct in any meaningful way? Both encrypt and then can only be decrypted with the other key. I've seen references to signing functions, is this related? – Juncture

The only diff I'm aware of in the signing function is the hashing of the message before encryption. – Juncture

Answer 10

In your scenario, you do not encrypt in the meaning of asymmetric encryption; I'd rather call it "encode".

So you encode your data into some binary representation, then you sign with your private key. If you cannot verify the signature via your public key, you know that the signed data is not generated with your private key. ("verification" meaning that the unsigned data is not meaningful)

Larger

Answer 11

Answering this question in the content that the questioners intent was to use the solution for software licensing, the requirements are:

1. No 3rd party can produce a license key from decompiling the app
2. The content of the software key does not need to be secure
3. Software key is not human readable

A Digital Signature will solve this issue as the raw data that makes the key can be signed with a private key which makes it not human readable but could be decoded if reverse engineered. But the private key is safe which means no one will be able to make licenses for your software (which is the point).

Remember you can not prevent a skilled person from removing the software locks on your product. So if they have to hack each version that is released. But you really don't want them to be able to generate new keys for your product that can be shared for all versions.

Python The PyNaCl documentation has an example of 'Digital Signature' which will suite the purpose. http://pynacl.readthedocs.org/en/latest/signing/

and of cause NaCl project to C examples

Rocketeer

Answer 12

What is the difference between encrypting some data vs signing some data (using RSA)?

RSA is merely the only public-key cryptosystem that naively supports both public-key encryption and digital signatures.

This usually confuses beginners since various sources/lecturers say

• RSA decryption is the RSA signature.
  • No, it is not!

The confusion comes from the textbook RSA

• the textbook RSA encryption;

  message m and calculates c = m^e mod n for encryption and m = c^d mod n for the decryption.

• the textbook RSA signatures;

  message m and calculates sg = m^d mod n for verification and m == sg^e mod n for the signature verification.

Both are not secure and they are not used in the real-life!

Does it simply reverse the role of the public-private keys?

No, it is not!

Encryption

For RSA encryption one must be using either RSASSA-PKCS1-v1_5 padding or Optimal Asymmetric Encryption Padding (OAEP). These paddings have overhead to the message. For example, PKCS1-v1_5 defined as

It has an EM structure as this

EM = 0x00 || 0x02 || PS || 0x00 || M.

so what are they;

• PS is at least eight FFs block
• M is the message
• the first 0x00 guarantees that EM is less than the modulus.
• The rest details like the size of FF block etc. can be found in rfc 8017 section 7.2.1

So it has a special message structure to be secure which is proven to be secure very lately (2018). The padding has at least 11-byte overhead.

Keep in mind that we don't prefer RSA encryption anymore, they are slow. We prefer Hybrid-Encryption.

Signature

The correct term for signature is signing and verification. For secure signing, RSA needs RSA-PSS (Probabilistic signature scheme). The structure is a bit complex, a picture will tell most of it

Once you hash the message and properly pad it, you can use your private key to sign your padded message!

For the verification, use the public key on the signed message and verify using the padding rules.

Prefer OAEP since RSASSA-PKCS1-v1_5 is hard to implement correctly and those incorrect implementations caused many attacks over the year despite that it is proven to be secure.

Let's finish all with the Cornell University page;

• RSA Signing is Not RSA Decryption

---

Notes

1. Never use the same key for different purposes. NIST Key Management Guidelines SP800-57 also recommend the separation of keys for different purposes.

2. For encryption we prefer Hybrid-Encryption, where we exchange/encapsulate keys, then use a Key Derivation on the exchanged/encapsulated key to derive a symmetric key, and then encrypt with a symmetric algorithm like AES or ChaCha20.

3. There are already well-tested and ready-to-use cryptographic libraries for use. Use TLS or Libsodium (or some other) for your purposes.

Sepulchral

This answer is a bit in the weeds. OP is looking for an explanation about the signing vs encryption and which key is used for them. There are many trustworthy libraries for performing cryptography operations. It's highly discouraged to write your own code for those operations, because a bug can be catastrophic. – Pyonephritis

@CameronHudson Where did I encourage someone to implement their own library in my answer? Many people confuse RSA decryption as signing and the whole purpose of the answer was to make sure that there was a note here. I've given an answer for that part only! – Sepulchral

@CameronHudson see crypto.stackexchange.com/questions/108422/… – Sepulchral