diff options
Diffstat (limited to 'archive/2022-03-14-notes-on-sigsum-and-rekor.md')
| -rw-r--r-- | archive/2022-03-14-notes-on-sigsum-and-rekor.md | 533 |
1 files changed, 0 insertions, 533 deletions
diff --git a/archive/2022-03-14-notes-on-sigsum-and-rekor.md b/archive/2022-03-14-notes-on-sigsum-and-rekor.md deleted file mode 100644 index d19e696..0000000 --- a/archive/2022-03-14-notes-on-sigsum-and-rekor.md +++ /dev/null @@ -1,533 +0,0 @@ -# A frequently asked question -We are frequently asked how Sigsum compares to Sigstore. This document -highlights some technical similarities and differences as of March, 2022. - -Sigstore's sub-project Rekor and Sigsum are both transparency log designs that -aim to make a signer's key-usage transparent. By enabling end-users to verify -that signatures they trust are public, they are protected from accepting -malicious signatures that were created in secret (e.g., due to key compromise). - -The following transparency log concepts are explored side-by-side: - - - Purpose of logging - - What is logged - - Auditing - - Gossip - - Anti-poison - - Anti-spam - - Privacy - - API - - Promises of future logging (SCTs) - - Sharding - -There is also an Appendix at the end with relevant code snippets. - -## Purpose of logging - -**Sigsum** - -No signature that an end-user accepts as valid should go unnoticed by anyone who -inspects the log. - -Sigsum is designed to be secure even if an attacker controls: - - - The signer's infrastructure and signing key - - The log's infrastructure and signing key - - A threshold of independent witnesses that cosign the log - -The log operator is not trusted beyond being available at the time of logging. - -**Sigstore/Rekor** - -[Rekor's README][] says that the goal is to "[e]nable software maintainers and -build systems to record signed metadata to an immutable record", and that it -"fulfils the signature transparency role of sigstore's software signing -infrastructure". [No threat model][] is available at the time of writing. - -[Rekor's README]: https://github.com/sigstore/rekor/tree/6ace9fe63b072a3a7e8b544fcbf393d2aafe9ae5#readme -[No threat model]: https://web.archive.org/web/20220312143825/https://docs.sigstore.dev/security/ - -## What is logged - -**Sigsum** - -A shard hint, a SHA256 checksum, an Ed25519 signature, and a SHA256-hashed -public key. The signed blob is based on the [SSH format][]. The logged -signatures are verifiable by anyone who knows the corresponding public keys. - -[SSH format]: https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.sshsig - -**Sigstore/Rekor** - -Signed manifests called [pluggable types][]. The rekord type allows signatures -based on Signify, Minisign, SSH, and PGP, as well as PKIX/X.509. For example, -you could log a signature for a PGP email that was received in 2002. There are -several other pluggable types with more to come. Rekor is overall permissive. - -Some pluggable type signatures are not verifiable in isolation for a monitor -that observes the log because to verify a signature data is needed that is not -included in the log and might be known only to the creator of the signature, see -"Example 1: unverifiable signatures" in the Appendix at the end. This means -that it is impossible to distinguish between unverifiable log entries fabricated -by the log and log entries maliciously created with a signer's private key. - -[pluggable types]: https://github.com/sigstore/rekor/blob/6ace9fe63b072a3a7e8b544fcbf393d2aafe9ae5/pkg/types/README.md - -## Auditing -How will end-users verify that public logging took place? - -**Sigsum** - -End-users receive inclusion proofs and cosigned tree heads that can be verified -offline in the same way that data and signatures are currently delivered (a -website, a git repository, etc). No other network communication is required. - -This means that a sigsum log does not have to be available to the end-user after -logging succeeded to verify that public logging took place. - -**Sigstore/Rekor** - -End-users [query the log][] to check that a signature is included. This means -the log needs to stay available to end-users at all times, also see "Privacy". - -Alternatively, an end-user may trust a signed promise (SCT) from Rekor to -include a signature in the future, see "Promises of future log inclusion". - -[query the log]: https://web.archive.org/web/20220312144545/https://www.sigstore.dev/how-it-works - -## Gossip -A mechanism that ensures everyone observes the same append-only log. A -transparency log without gossip requires trusting the log operator and the -integrity of the log's signing key. - -**Sigsum** - -Gossip is handled proactively using a simplified version of witness cosigning -([S&P 2016][]). It can be thought of as a policy-based consensus mechanism: -m-of-n witnesses audit the log's consistency from their respective vantage -points. The log distributes the witnesses' signatures, which end-users and -monitors make use of. This ensures that a malicious sigsum log operator is -unable to fool even an offline verifier. - -[S&P 2016]: https://arxiv.org/pdf/1503.08768.pdf - -**Sigstore/Rekor** - -Does not have gossip. Sigstore proposes to instead use multiple independent -[full-fledged logs][]. Logs have more freedom to fool a verifier than cosigning -witnesses and are harder and more expensive to run. - -Signers would have to take great care to submit the same entries to all the logs -and would have to monitor all of them. End-users would have to contact and/or -trust multiple logs when verifying. - -[full-fledged logs]: https://web.archive.org/web/20220312144801/http://web.archive.org/screenshot/https://docs.sigstore.dev/faq - -## Anti-poison -A transparency log design must take caution to not include large amounts of -arbitrary data, as someone could submit information that is illegal to possess -or distribute. Because the log operator cannot selectively erase information -from the log without invalidating it, the operator may be compelled to shut down -the log, or simply choose to not operate a log in the first place. - -**Sigsum** - -Include as little arbitrary information as possible. A log entry contains a -time value (a shard hint, in the interval `[shard_start, now()]`) of which the -least significant few bytes are arbitrary. The remaining content can only be -specified by brute forcing signatures or hashes so that parts of them contain -certain patterns. This quickly becomes expensive. - -**Sigstore/Rekor** - -The pluggable type system allows logging of a wide variety of information. The -rekord type for instance allows encoding an image, see "Example 2: logging JPG -images" in the Appendix at the end. Other current and future pluggable types -might permit similar things but we have not looked into that further. - -## Anti-spam -An approach to limit abusive logging requests that consume the log's capacity. - -**Sigsum** - -A logging request is only accepted if the involved public key is hashed into a -DNS TXT record. So, rate limits can be based on DNS names. This is similar to -the anti-spam mechanisms that CT relies on, where a certificate is not accepted -unless it chains up to a trusted CA. Let's Encrypt [rate-limits via DNS][]. - -[rate-limits via DNS]: https://web.archive.org/web/20220312145502/https://letsencrypt.org/docs/rate-limits/ - -**Sigstore/Rekor** - -Recently opened an issue about [needing rate-limits][]. It has since been added -to Sigstore's infrastructure setup based on IP addresses via Nginx. - -[needing rate-limits]: https://github.com/sigstore/rekor/issues/637 - -## Privacy - -**Sigsum** - -For end-users, nothing changes with regard to privacy compared to signature -verification that does not make use of a transparency log. - -A signer has to expose to the log operator a public key and a 32-byte preimage -([which should be a hash][]). - -The signer's hashed public key is exposed in DNS, see "Anti spam". Logs can be -be instructed to fetch such TXT resource records if they match `_sigsum_v0.*`. - -Log entries consisting of a shard hint, hashes and signatures become public, see -"What is logged". - -[which should be a hash]: https://git.sigsum.org/sigsum/tree/doc/design.md?id=741a65ab1894b35c9cc132d9b8401776c04fe1ce#n351 - -**Sigstore/Rekor** - -End-users that query the log for entries they are interested in expose this -information to the log. - -A signer's public key and data is exposed to the log operator. The data may be -a hash if [using X.509/PKIX][] signatures and the "hashed rekord type". - -Logs can be instructed to download arbitrary data from [specified URLs][]. - -The content of pluggable types become public, notably including public keys and -other data that may be encoded (which depends on the exact pluggable type). - -[using X.509/PKIX]: https://github.com/sigstore/rekor/blob/6ace9fe63b072a3a7e8b544fcbf393d2aafe9ae5/types.md#hashed-rekord -[specified URLs]: https://github.com/sigstore/rekor/blob/6ace9fe63b072a3a7e8b544fcbf393d2aafe9ae5/openapi.yaml#L143 - -## API - -**Sigsum** - -Simple ASCII parsers are used to add input and get output from the log. Binary -data is hex-encoded. Data that is signed and/or logged can be (de)serialized -using Tor's easy wire-format, [Trunnel][]. The overall take of the API is to -keep it as simple as possible, and to nudge towards correct usage by design. - -[Trunnel]: https://gitweb.torproject.org/trunnel.git/tree/doc/trunnel.md - -**Sigstore/Rekor** - -REST API with JSON, both for input and output as well as canonicalization of -data. Some parts of the API are easily misused due to returning redundant -and/or unauthenticated data. This happened [once][] and [twice][] already. - -Other types of mis-usage are likely to be expected. For example, the -availability of public keys makes it tempting to inappropriately use Rekor for -key discovery even though it is not designed to be a trustworthy source of keys. - -The implementation complexity of Rekor's API is also relatively large. Imports -contain much hidden complexity, in part due to pluggable types that involve PGP, -ASN.1, and such. This has already lead to issues like Rekor starting to return -[YAML instead of JSON][]; JSON marshalling of tree leaves [not being canonical -enough][]; the [need of another PGP library][]; etc. It will likely be hard to -understand, implement, and maintain Rekor compliant software in the long run. - -[once]: https://github.com/sigstore/rekor/issues/200 -[twice]: https://github.com/sigstore/rekor/pull/469 -[YAML instead of JSON]: https://github.com/sigstore/rekor/issues/593 -[not being canonical enough]: https://github.com/sigstore/rekor/pull/445 -[need of another PGP library]: https://github.com/sigstore/rekor/issues/286 - -## Promises of future log inclusion (SCTs) -A construct that enables low-latency logging. Certificate Transparency -introduced this to work with the existing TLS PKI during a gradual roll-out -scenario. Nine years later such roll-outs are still in the earlier stages. - -**Sigsum** - -Does not support SCTs. Unlike the TLS case there is no existing system to be -compatible with and use-cases that cannot tolerate a few minutes of logging -latency are out-of-scope. This is a trade-off that keeps the design simple. - -**Sigstore/Rekor** - -[Supports SCTs][]. If an entry (promised to be logged by an SCT) is not included -in the log in time the operator should not be trusted in the future. This -places high requirements on uptime and availability, and on not losing the log -request between the time of issuing an SCT and inclusion in the log. Rekor -avoids this by simply including the signature in the log [before issuing][] the -SCT. That however provides no latency reduction, making SCTs pointless. - -The mere existence of SCTs also encourages their use, making users who rely on -them not receive the full benefits of using a transparency log. We are not -aware of any clear plans specifying how Sigstore will solve SCT verification. -Without such plans, the log may deceive end-users by changing its history. - -[Supports SCTs]: https://twitter.com/lorenc_dan/status/1388109774579982340 -[before issuing]: https://github.com/sigstore/rekor/blob/a61d5f63843cbae4e5bf1f97d06628fa914a4435/openapi.yaml#L493 - -## Sharding -The practise of dividing a log into smaller independent partitions. One of -Certificate Transparency's successes is [temporal sharding][] based on expiry -date to allow log rotation (helpful to make log life cycles more manageable). - -[temporal sharding]: https://web.archive.org/web/20220312150931/https://googlechrome.github.io/CertificateTransparency/log_policy.html - -**Sigsum** - -Establishes shards based on shard hints in the interval `[shard_start, now()]`. -Shard hints are part of the signer's signing context and cannot be forged, -preventing past entries from being re-logged in a newer shard. A log can also -cease its operations safely due to Sigsum's take on offline auditing. This -gives a complete story for log life cycles without any expiration dates. - -**Sigstore/Rekor** - -Creates [virtual shards][], see also related [GitHub issues][]. The latest -virtual shard is active. All other virtual shards are kept around but in -read-only mode. If a virtual shard was to be deleted those entries can be -logged again. As old virtual shards have to be saved, this gives a complicated -log configuration but does not provide any of the benefits of sharding. - -[virtual shards]: https://docs.google.com/document/d/1QBTyK-wquplNdeUB5_aqztQHigJOepCvd-4FL4H-zl8/edit?resourcekey=0-grdVbSltkTvpNvhj03laCQ# -[GitHub issues]: https://github.com/sigstore/rekor/issues/353 - -# Appendix -## Example 1: Unverifiable signatures -The input to a signature verification is a public key, a message, and a -signature. Rekor incorrectly assumes that the signed message ("artifact") -is always a hash. - -First we demonstrate the issue using `signify`. - -**Step 1 - Generate a key-pair** - - $ signify-openbsd -G -c "demo" -p example.pub -s example.sec - passphrase: - confirm passphrase: - $ ls - example.pub example.sec - -**Step 2 - Create something to sign** - - $ echo 'print("hello")' > hello.py - $ sha256sum hello.py - b80792336156c7b0f7fe02eeef24610d2d52a10d1810397744471d1dc5738180 hello.py - $ ls - example.pub example.sec hello.py - -**Step 3 - Sign** - - $ signify-openbsd -Ss example.sec -m hello.py - passphrase: - $ ls - example.pub example.sec hello.py hello.py.sig - -**Step 4 - Log** - -The below uses Rekor on commit 6ace9fe63b072a3a7e8b544fcbf393d2aafe9ae5. - - $ rekor-cli upload \ - --artifact hello.py\ - --signature hello.py.sig\ - --pki-format=minisign\ - --public-key=example.pub\ - --rekor_server http://localhost:3000 - Created entry at index 99, available at: http://localhost:3000/api/v1/log/entries/bf5f87c83bfffc3b0d3d0151a6cfef836594dcd90ac286541b25856b7d6fd6b1 - $ rekor-cli get --log-index 99 --rekor_server http://localhost:3000 - LogID: e0f8a8ff472431bda298489c292f33f5d30363949df58d2e35c5195f915c7069 - Index: 99 - IntegratedTime: 2022-03-12T11:59:28Z - UUID: bf5f87c83bfffc3b0d3d0151a6cfef836594dcd90ac286541b25856b7d6fd6b1 - Body: { - "RekordObj": { - "data": { - "hash": { - "algorithm": "sha256", - "value": "b80792336156c7b0f7fe02eeef24610d2d52a10d1810397744471d1dc5738180" - } - }, - "signature": { - "content": "dW50cnVzdGVkIGNvbW1lbnQ6ClJXVE9PWDNrMjE0L3VDR0VuQWtHaC9wOGxCK2o4ZlU0bzN2aFpzc3dud2RFeDE2M2REUHpReE1BVXdUcUFjK1ovaGdycGdISU5VNHlFbnhPOXNwSnkydmZmcHdWSUJIV3lnWT0=", - "format": "minisign", - "publicKey": { - "content": "UldUT09YM2syMTQvdUg1RVhHbUFwdDZWSnhxVUlJZzIrWnMrajlFRDNTM1ZGOXBHSzZoWDRLSmM=" - } - } - } - } - -Let's understand the above in more detail. Our public key and signature is in -the above output, but without the untrusted comment which is irrelevant. - - cat example.pub - untrusted comment: demo public key - RWTOOX3k214/uH5EXGmApt6VJxqUIIg2+Zs+j9ED3S3VF9pGK6hX4KJc - $ echo UldUT09YM2syMTQvdUg1RVhHbUFwdDZWSnhxVUlJZzIrWnMrajlFRDNTM1ZGOXBHSzZoWDRLSmM= | base64 -d - RWTOOX3k214/uH5EXGmApt6VJxqUIIg2+Zs+j9ED3S3VF9pGK6hX4KJc - $ - $ cat hello.py.sig - untrusted comment: verify with example.pub - RWTOOX3k214/uCGEnAkGh/p8lB+j8fU4o3vhZsswnwdEx163dDPzQxMAUwTqAc+Z/hgrpgHINU4yEnxO9spJy2vffpwVIBHWygY= - $ echo "dW50cnVzdGVkIGNvbW1lbnQ6ClJXVE9PWDNrMjE0L3VDR0VuQWtHaC9wOGxCK2o4ZlU0bzN2aFpzc3dud2RFeDE2M2REUHpReE1BVXdUcUFjK1ovaGdycGdISU5VNHlFbnhPOXNwSnkydmZmcHdWSUJIV3lnWT0=" | base64 -d - untrusted comment: - RWTOOX3k214/uCGEnAkGh/p8lB+j8fU4o3vhZsswnwdEx163dDPzQxMAUwTqAc+Z/hgrpgHINU4yEnxO9spJy2vffpwVIBHWygY= - -Rekor also stored a SHA256 hash: - - "RekordObj": { - "data": { - "hash": { - "algorithm": "sha256", - "value": "b80792336156c7b0f7fe02eeef24610d2d52a10d1810397744471d1dc5738180" - } - }, - -You might recognize it from step 2. It is the output of `sha256sum hello.py`. -What is needed to do verification with the logged signature and public key is -the output of `cat hello.py`. This is because signify signs those exact bytes -without doing any hashing (unlike other schemes that actually do sign a hash). - -The impact is that you cannot know by observing the log if a real signature -operation happened (there is nothing to verify), or if the Rekor operator -fabricated an entry. The signature would be verifiable if the data can be -located. In the case of a malicious signature this might not be the case. - -**The same issue in other places** - -Minisign has the same issue, even with its pre-hashed mode because Minisign -[does not use SHA256][] which is what Rekor still stores. The exact same issue -is also there for SSH signatures. We did not dig into any other types. - -[does not use SHA256]: https://github.com/sigstore/rekor/blob/6ace9fe63b072a3a7e8b544fcbf393d2aafe9ae5/pkg/pki/minisign/minisign.go#L109 - -## Example 2: Logging JPG images -As shown above Rekor scrubs some information that was submitted for logging. -Most likely to not accept arbitrary bytes, such as signify's untrusted comments. -To protect Rekor against logging of illegal content, each pluggable type needs -to be considered in more detail. Below is an example that encodes a JPG image. - -**Step 1 - Create an image** - - $ convert -size 16x16 xc:red red.jpg - $ ls - red.jpg - -This also works with larger images, e.g., `-size 4096x4096`. - -**Step 2 - Encode image in an X.509 configuration** - - $ echo "[ req ]" > crt.cnf - $ echo "distinguished_name = dn" >> crt.cnf - $ echo "x509_extensions = extensions" >> crt.cnf - $ echo "prompt = no" >> crt.cnf - $ echo "" >> crt.cnf - $ echo "[ extensions ]" >> crt.cnf - $ echo "1.2.3.4 = ASN1:UTF8String:$(base64 -w0 red.jpg)" >> crt.cnf - $ echo "" >> crt.cnf - $ echo "[ dn ]" >> crt.cnf - $ echo "0.DC = com" >> crt.cnf - $ echo "1.DC = example" >> crt.cnf - $ echo "commonName = example.com" >> crt.cnf - $ ls - crt.cnf red.jpg - -Credit: [this post][] outlines how an X.509v3 extension can be prepared. - -[this post]: https://serverfault.com/questions/1005029/error-when-trying-to-add-custom-extensions-to-x509-certificates-using-openssl - -**Step 3 - Create X.509 certificate** - - $ openssl req -x509 -nodes\ - -newkey ec:<(openssl ecparam -name prime256v1)\ - -config crt.cnf\ - -keyout priv.pem\ - -out cert.pem - Generating an EC private key - writing new private key to 'priv.pem' - ----- - $ ls - cert.pem crt.cnf priv.pem red.jpg - -Note that we now have an X.509 certificate that encodes our image: - - $ openssl x509 -in cert.pem -text -noout - Certificate: - Data: - Version: 3 (0x2) - Serial Number: - 27:a5:0e:37:9c:3e:e1:0d:d7:a4:8f:10:ce:2d:09:35:40:9c:a8:1e - Signature Algorithm: ecdsa-with-SHA256 - Issuer: DC = com, DC = example, CN = example.com - Validity - Not Before: Mar 12 13:46:06 2022 GMT - Not After : Apr 11 13:46:06 2022 GMT - Subject: DC = com, DC = example, CN = example.com - Subject Public Key Info: - Public Key Algorithm: id-ecPublicKey - Public-Key: (256 bit) - pub: - 04:9d:2a:5d:4c:df:d4:fa:9a:76:32:59:96:3b:44: - 12:00:03:3c:c0:d9:42:58:c1:fb:2a:ed:fb:0d:95: - d0:ce:7d:62:e6:f8:ae:be:76:6b:3b:0c:44:aa:ca: - 43:57:cf:19:a3:c9:b1:cd:05:21:a2:b8:0c:50:13: - 0c:d9:9f:8f:ea - ASN1 OID: prime256v1 - NIST CURVE: P-256 - X509v3 extensions: - 1.2.3.4: - ..../9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgKCgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkLEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAARCAAQABADAREAAhEBAxEB/8QAFQABAQAAAAAAAAAAAAAAAAAAAAj/xAAUEAEAAAAAAAAAAAAAAAAAAAAA/8QAFgEBAQEAAAAAAAAAAAAAAAAAAAcJ/8QAFBEBAAAAAAAAAAAAAAAAAAAAAP/aAAwDAQACEQMRAD8AnRDGqYAAD//Z - Signature Algorithm: ecdsa-with-SHA256 - 30:46:02:21:00:ee:ee:81:d6:1c:e8:a7:ca:dd:54:b5:82:fe: - 22:1d:94:1d:b1:31:91:d6:3e:68:99:f5:d5:da:c9:f4:bc:53: - 53:02:21:00:cd:08:98:c5:73:e8:a1:8f:8c:95:06:cc:5c:70: - 65:aa:dd:94:f0:38:59:ec:f7:c7:35:98:eb:75:5f:23:eb:c5 - -Compare the X.509v3 extensions to this: - - $ base64 red.jpg - /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgKCgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkLEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAARCAAQABADAREAAhEBAxEB/8QAFQABAQAAAAAAAAAAAAAAAAAAAAj/xAAUEAEAAAAAAAAAAAAAAAAAAAAA/8QAFgEBAQEAAAAAAAAAAAAAAAAAAAcJ/8QAFBEBAAAAAAAAAAAAAAAAAAAAAP/aAAwDAQACEQMRAD8AnRDGqYAAD//Z - -Now we need to get this X.509 certificate into Rekor. - -**Step 4 - Sign something** - - $ openssl dgst -sha256 -sign priv.pem -out red.jpg.sig red.jpg - $ ls - cert.pem crt.cnf priv.pem red.jpg red.jpg.sig - -**Step 5 - Log** - - $ rekor-cli upload \ - --artifact red.jpg\ - --signature red.jpg.sig\ - --pki-format=x509\ - --public-key=cert.pem\ - --rekor_server http://localhost:3000 - Created entry at index 102, available at: http://localhost:3000/api/v1/log/entries/688f817bb1e7cb1b28eadf173b0095724cce86ab0116b0df5a0c8e06c00e880c - $ - $ rekor-cli get --log-index 102 --rekor_server http://localhost:3000 - LogID: e0f8a8ff472431bda298489c292f33f5d30363949df58d2e35c5195f915c7069 - Index: 102 - IntegratedTime: 2022-03-12T13:51:30Z - UUID: 688f817bb1e7cb1b28eadf173b0095724cce86ab0116b0df5a0c8e06c00e880c - Body: { - "RekordObj": { - "data": { - "hash": { - "algorithm": "sha256", - "value": "4a837db6d6a21a9bdfccff6ca21f72d1d4a671b59a5df76158629ff5f6b22ddf" - } - }, - "signature": { - "content": "MEYCIQD4HWtXfSDGpWUUmk1tWUP/V5MRUPgwrUMiiJB7miKZcQIhAJDYUO+lyGYKShCtt3AZZilZkoLEm9WAaXhlzGVwZMu6", - "format": "x509", - "publicKey": { - "content": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURKakNDQXN1Z0F3SUJBZ0lVSjZVT041dys0UTNYcEk4UXppMEpOVUNjcUI0d0NnWUlLb1pJemowRUF3SXcKUkRFVE1CRUdDZ21TSm9tVDhpeGtBUmtXQTJOdmJURVhNQlVHQ2dtU0pvbVQ4aXhrQVJrV0IyVjRZVzF3YkdVeApGREFTQmdOVkJBTU1DMlY0WVcxd2JHVXVZMjl0TUI0WERUSXlNRE14TWpFek5EWXdObG9YRFRJeU1EUXhNVEV6Ck5EWXdObG93UkRFVE1CRUdDZ21TSm9tVDhpeGtBUmtXQTJOdmJURVhNQlVHQ2dtU0pvbVQ4aXhrQVJrV0IyVjQKWVcxd2JHVXhGREFTQmdOVkJBTU1DMlY0WVcxd2JHVXVZMjl0TUZrd0V3WUhLb1pJemowQ0FRWUlLb1pJemowRApBUWNEUWdBRW5TcGRUTi9VK3BwMk1sbVdPMFFTQUFNOHdObENXTUg3S3UzN0RaWFF6bjFpNXZpdXZuWnJPd3hFCnFzcERWODhabzhteHpRVWhvcmdNVUJNTTJaK1A2cU9DQVprd2dnR1ZNSUlCa1FZREtnTUVCSUlCaUF5Q0FZUXYKT1dvdk5FRkJVVk5yV2twU1owRkNRVkZCUVVGUlFVSkJRVVF2TW5kQ1JFRkJUVU5CWjBsRFFXZE5RMEZuU1VSQgpkMDFFUWtGWlJVSkJVVVZDUVdkSFFtZFZSME5SWjB0RFoydEpRMUZyUzBSQk9FMURaM05QUTNkclNrUlNSVTVFClp6aFJSVUpGVVVObmQxTkZlRWxSUlhjNFVVVkNSQzh5ZDBKRVFWRk5SRUYzVVVSQ1FXZEZRa0ZuVVVOM2EweEYKUWtGUlJVSkJVVVZDUVZGRlFrRlJSVUpCVVVWQ1FWRkZRa0ZSUlVKQlVVVkNRVkZGUWtGUlJVSkJVVVZDUVZGRgpRa0ZSUlVKQlVVVkNRVkZGUWtGUlJVSkVMM2RCUVZKRFFVRlJRVUpCUkVGU1JVRkJhRVZDUVhoRlFpODRVVUZHClVVRkNRVkZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVdvdmVFRkJWVVZCUlVGQlFVRkJRVUZCUVVGQlFVRkIKUVVGQlFVRkJRUzg0VVVGR1owVkNRVkZGUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVdOS0x6aFJRVVpDUlVKQgpRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZRTDJGQlFYZEVRVkZCUTBWUlRWSkJSRGhCYmxKRVIzRlpRVUZFCkx5OWFNQW9HQ0NxR1NNNDlCQU1DQTBrQU1FWUNJUUR1N29IV0hPaW55dDFVdFlMK0loMlVIYkV4a2RZK2FKbjEKMWRySjlMeFRVd0loQU0wSW1NVno2S0dQakpVR3pGeHdaYXJkbFBBNFdlejN4eldZNjNWZkkrdkYKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=" - } - } - } - } - -Of interest here is the public key: - - $ echo "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURKakNDQXN1Z0F3SUJBZ0lVSjZVT041dys0UTNYcEk4UXppMEpOVUNjcUI0d0NnWUlLb1pJemowRUF3SXcKUkRFVE1CRUdDZ21TSm9tVDhpeGtBUmtXQTJOdmJURVhNQlVHQ2dtU0pvbVQ4aXhrQVJrV0IyVjRZVzF3YkdVeApGREFTQmdOVkJBTU1DMlY0WVcxd2JHVXVZMjl0TUI0WERUSXlNRE14TWpFek5EWXdObG9YRFRJeU1EUXhNVEV6Ck5EWXdObG93UkRFVE1CRUdDZ21TSm9tVDhpeGtBUmtXQTJOdmJURVhNQlVHQ2dtU0pvbVQ4aXhrQVJrV0IyVjQKWVcxd2JHVXhGREFTQmdOVkJBTU1DMlY0WVcxd2JHVXVZMjl0TUZrd0V3WUhLb1pJemowQ0FRWUlLb1pJemowRApBUWNEUWdBRW5TcGRUTi9VK3BwMk1sbVdPMFFTQUFNOHdObENXTUg3S3UzN0RaWFF6bjFpNXZpdXZuWnJPd3hFCnFzcERWODhabzhteHpRVWhvcmdNVUJNTTJaK1A2cU9DQVprd2dnR1ZNSUlCa1FZREtnTUVCSUlCaUF5Q0FZUXYKT1dvdk5FRkJVVk5yV2twU1owRkNRVkZCUVVGUlFVSkJRVVF2TW5kQ1JFRkJUVU5CWjBsRFFXZE5RMEZuU1VSQgpkMDFFUWtGWlJVSkJVVVZDUVdkSFFtZFZSME5SWjB0RFoydEpRMUZyUzBSQk9FMURaM05QUTNkclNrUlNSVTVFClp6aFJSVUpGVVVObmQxTkZlRWxSUlhjNFVVVkNSQzh5ZDBKRVFWRk5SRUYzVVVSQ1FXZEZRa0ZuVVVOM2EweEYKUWtGUlJVSkJVVVZDUVZGRlFrRlJSVUpCVVVWQ1FWRkZRa0ZSUlVKQlVVVkNRVkZGUWtGUlJVSkJVVVZDUVZGRgpRa0ZSUlVKQlVVVkNRVkZGUWtGUlJVSkVMM2RCUVZKRFFVRlJRVUpCUkVGU1JVRkJhRVZDUVhoRlFpODRVVUZHClVVRkNRVkZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVdvdmVFRkJWVVZCUlVGQlFVRkJRVUZCUVVGQlFVRkIKUVVGQlFVRkJRUzg0VVVGR1owVkNRVkZGUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVdOS0x6aFJRVVpDUlVKQgpRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZRTDJGQlFYZEVRVkZCUTBWUlRWSkJSRGhCYmxKRVIzRlpRVUZFCkx5OWFNQW9HQ0NxR1NNNDlCQU1DQTBrQU1FWUNJUUR1N29IV0hPaW55dDFVdFlMK0loMlVIYkV4a2RZK2FKbjEKMWRySjlMeFRVd0loQU0wSW1NVno2S0dQakpVR3pGeHdaYXJkbFBBNFdlejN4eldZNjNWZkkrdkYKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=" | base64 -d > logged-cert.pem - $ diff cert.pem logged-cert.pem - $ - -As you can see, it is the same certificate that contains our JPG image. Any -other data could be encoded as well using the above trick. |