I'm having trouble interpreting an S/MIME signed / encrypted message. This is the structure I get when I parse a .msg file into JavaMail MimeMessage (and I'm not sure that it matters that it is Java or Outlook):
MimeMessage
- FROM, TO, SUBJECT
- S/MIME signed attachment
Should I interpret the attachment as a nested / attached email as follows when decrypting?:
MimeMessage
- FROM, TO, SUBJECT
- MimeMessage attachment*
- FROM, TO, SUBJECT
- BODY
- ATTACHMENTS
Or am I supposed to merge it with the root level items such that I end up with the following?:
MimeMessage
- FROM, TO, SUBJECT
- BODY*
- ATTACHMENTS*
* decrypted
Your explanation of what you are seeing is very misleading as it implies that the decrypted content is itself an rfc822 MIME message structure.
The reality is that the decrypted S/MIME content should be a MIME entity, not a MIME message. Therefor, it will not have Subject, To, From, or Date headers.
In this case, yes, you would merge it with the container message if you want to get the original (pre-encrypted) MIME message structure.
Related
I need to get the following out of x509 CA certificates:
the Hash of the DER encoded public key (excluding tag and length) of the subject public key field
the hash of the issuers distinguished name, that must be calculated over the DER encoding of the issuer's name field
I tried to use X509_issuer_name_hash and X509_pubkey_digest, but apparently they return not the results that I expect.
This question and the answers posted is close to what I look for: https://crypto.stackexchange.com/questions/87661/how-can-i-get-issuernamehash-and-issuerkeyhash-from-pem-or-der-certificates but I would like to have an explanation on how to do this in C++ and OpenSSL.
UPDATE: X509_pubkey_digest is exactly what i needed, I just made a mistake converting to hexstring. The hash of the issuer's distinguished name is still open though.
Background: Suppose I want to verify the ownership of some tweet or some picture by looking up the data in the blockchain. If my understanding is correct, I need to be able to assign a unique tokenId that represents that tweet/picture.
Question 1: Is there some standardization on how this ID is assigned? Do different platform perform this mapping in a unique way? I feel like without such a standardization, the non-fungibility becomes questionable (e.g., do you really own this tweet, or do you only own it if you apply the tweet->token ID mapping you crafted yourself?).
Question 2: Could you provide a few examples of how exactly is the token ID assigned to some (well-known) NFTs?
Is there some standardization on how this ID is assigned?
The ERC-721 standard explicitly states that there is no standard to assign the ID (except for the uint256 datatype):
While some ERC-721 smart contracts may find it convenient to start with ID 0 and simply increment by one for each new NFT, callers SHALL NOT assume that ID numbers have any specific pattern to them, and MUST treat the ID as a “black box”.
e.g., do you really own this tweet, or do you only own it if you apply the tweet->token ID mapping
Token ownership does not mean that you own the underlying resource. It only means that you own the token (representing the resource).
Could you provide a few examples of how exactly is the token ID assigned to some (well-known) NFTs?
CryptoKitties - link, line 412, incrementing
uint256 newKittenId = kitties.push(_kitty) - 1;
CryptoPunks - link, lines 73 and 83, assigning ID set by the (authorized) caller
mapping (uint => address) public punkIndexToAddress;
function setInitialOwner(address to, uint punkIndex) {
// ...
punkIndexToAddress[punkIndex] = to;
When an NFT is minted with a smart contract, associated with the NFT TokenID, the block chain also typically records a URI (universal resource identifier) that points to the NFT metadata (usually a json file). This URI can be obtained by querying the blockchain via the smart contract address and TokenID. The json file itself includes, among other things, another URI that points to the digital asset linked with the NFT. If immutable URIs are used (e.g. IPFS URIs), the URI recorded in the block chain for the NFT TokenID is unambiguously linked to the unchangeable json file which unambiguously links to the unchangeable digital asset. As Petr correctly points out, technologically, nothing prevents anyone else from minting another NFT that also records the same URI and therefore points to the same json file (and by transitivity to the same digital asset). I've tried to be precise in the preceding statements to avoid incorrect extrapolatory claims that would actually depend on the smart contract implementation details.
For work i am going to use use DNS records between two servers using a software made by the company. Mostly SRV, NAPTR and A records.
To propagate the information i have to create a new type of message which is going to be sent by a function in our software managing all messages.
Instead of creating 3 types of messages "SRv" "NAPTR "A" i thought about creating only one kind - general for all DNS records - with a part of the message dedicated to the type; NAPTR, A, SRV, MX etc...
I would like to have advice for the fields needed in this message, for example which fields are common for each DNS record type to include them in all messages, and which fields are specials for each records ? (Maybe creating a Data field in the message for additionnal informations specific for each type (prefix and protocol for NAPTR for example))
Actually for NAPTR (only one i did) i have various variables like TTL, zone, that i receive.
And i put every one in a stream and update it with :
system("nsupdate update.txt")
the file filled with the oss looks like this:
update add test.zone 60 NAPTR 10 100 "S" "SIP+D2T" "" _sip._tcp.zone.
send
But i would like to have a more general message which adapts for various DNS records if someday i need new ones.
Any help appreciated.
To solve the problem i created one message subdivised in two part, header and body. The header has all the common infos of the RR, like TTL, domain, Class, Type, and in function of the type i create a "length of data" and "data" field for each RR. For example NAPTR got data field with others fields in it, like Weight, Priority etc...
I did not found any better idea to factorise the informations.
Suppose I have a proto structure that looks like the following:
message TMessage {
optional TDictionary dictionary = 1;
optional int specificField1 = 2;
optional TOtherMessage specificField2 = 3;
...
}
Suppose I am using C++. This is the message stub that is used in the master process to send information to the bunch of the nodes using the network. In particular, the dictionary field is 1) pretty heavy 2) common for all the serialized messages, and all the following specific fields are filled with the relatively small information specific to the destination node.
Of course, dictionary is built only once, but it comes out that the major part of running time is spent while serializing the common dictionary part again and again for each new node.
Obvious optimization would be to pre-serialize dictionary into the byte string and put it into the TMessage as a bytes field, but this looks a bit nasty to me.
Am I right that there is no built-in way to pre-serialize a message field without ruining the message structure? It sounds like an idea for a good plugin for proto compiler.
Protobuf is designed such that concatenation === composition, at least for the root message. That means that you can serialize an object with just the dictionary, and snapshot the bytes somewhere. Now for each of the real messages you can paste down that snapshot, and then serialize an object with just the other fields - just whack it straight after: no additional syntax is required. This is semantically identical to serializing them all at the same time. In fact, since it will retain the field order, it should actually be identical bytes too.
It helps that you used "optional" throughout :)
Marc's answer is perfect for your use case. Here is just another option:
The field must be a submessage, like your TDictionary is.
Have another variant of the outer message, with bytes in place of the submessage you want to preserialize:
message TMessage_preserialized {
optional bytes dictionary = 1;
...
}
Now you can serialize the TDictionary separately and put the resulting data in the bytes field. In protobuf format, submessages and bytes field are written out the same way. This means you can serialize as TMessage_preserialized and still deserialize as normal TMessage.
I have a Json data retrieved from facebook using graph api, now i am going to parse that data, i decoded that json
$decodedjson= json_decode($jsondata);
after that i got data in following format.
i write
$id= $decodedjson->message_id;
to get the id,
the attachment is an other object, please tell me how can i access the attachment, media, href, alt and the video , display_url and so on, name etc
Thanks
Just like any object -
$vid=($decodedjson[2])->attachment->media[0];
$alt=$vid->alt;
Edit: Noticed the [2]=>... at the top of your var_dump
json_decode - convert json format to php array
You should access it as array
$id= $decodedjson[0]['message_id'];
$attachment= $decodedjson[0]['attachment']['media'];//an array
$video= $decodedjson[0]['media'][0]['video']['owner'];