Search
1000 results for “Solimander”
-
CW: art containing nakey
Why do your magical rituals always require you to be naked, Penelope?
Commission for bigchallenges
#furryart #furry #salamander #forest #comm #furryart #fediart #foxwayart
-
Take the “High Line”: the thread about Leith’s unbuilt park through the rooftops
I found something very interesting hidden away in a cardboard file in a corner of Leith Library. The title – City of Edinburgh, Leith Local Plan, Draft Final Report, April 1975. Volume Two. Schedules and Appendices. – was so snappy that I couldn’t help but start reading it. This was the plan for a £90 million redevelopment and rejuvenation of Leith, which by this time was suffering badly from industrial decline, urban depopulation, poor housing stock and a general lack of public amenities. As part of this plan it was proposed that the Edinburgh Corporation as it then was (after 1975 it was Edinburgh District Council) would purchase the abandoned trackbed of the Caledonian Railway which ran from Pilrig Park to Seafield via Restalrig, over Leith Walk and Easter Road. This would be converted into a landscaped walkway through the area, what nowadays we might term a linear park.
Line of the Pilrig to Seafield section of the Caledonian Railway, traced over a 1971 OS land use survey map on a 6-inch to the mile base map, 1966 survey. CC-by-NC-SA via National Library of ScotlandThis section of railway, formally known as the Leith New Lines, was one of the last to be built in the city and did not open until 1903. Its purpose was to give the Caley access from its existing line into Leith Docks from the west to the expanding eastern portion of the docklands. It would cut its way through the dense industrial heartlands of Leith and Bonnington, serving these with large and convenient new goods stations.
Ordnance Survey 6-inch scale map of Leith, 1906. The North British Railway is highlighted blue, the Caledonian Railway in red and the Leith New Lines in green. Reproduced with the permission of the National Library of ScotlandOn paper this was a sound proposal but by this time the best potential routes through Leith were already well built on, therefore it had to take a winding and circuitous route requiring substantial and expensive engineering. There were numerous cuttings and viaducts required plus skew girder bridges over thoroughfares at Bonnington Toll, Leith Walk and Easter Road. As if that wasn’t enough, it also had to cross three different North British Railway lines, the Water of Leith and cut beneath Ferry Road.
https://www.flickr.com/photos/127340508@N05/40040319893/
This railway never fulfilled its potential, a planned passenger service was never introduced and its twin tracks soon singled. The western section between Newhaven and Bonnington closed in 1965. In 1968 the low bridge over Bonnington Toll was removed and the goods station off Leith Walk at Stead’s Place (Leith Walk West) was closed. For a few years the eastern section at Seafield lingered on giving access to the Leith East goods yard at Salamander Street but this too closed in 1973, making the entire line redundant. British Rail gave notice at this point that it intended to demolish its monumental girder bridges over Leith Walk and Easter Road plus a smaller one over Halmyre Street to reduce their maintenance burden.
Easter Road #NowAndThen image overlay showing the Caledonian Railway bridge in 1974 and the modern Google Streetview background. Original from Edinphoto. This bridge was removed between January and February 1980.The 1975 path scheme saw the opportunity to purchase the route from British Rail before they proceeded with demolition and proposed to replace these large, expensive structures with lightweight footbridges and to retain the smaller bridge over Halmyre Street. This would give an elevated walkway from Pilrig Park, across the arches of the viaducts at Jane Street, Manderston Street and Gordon Street and from there along the embankments and cuttings all the way to Seafield.
Cover, City of Edinburgh, Leith Local Plan, Draft Final Report, April 1975. Volume Two. Schedules and Appendices.Proposal diagram for the Leith Walk Sawmills and Caley railway yard land off of Pilrig Park.The bridges at Easter Road and Manderston Street would be removed in early 1980, with that over Leith Walk following in September that year.
It have assumed that because the bridge over Halmyre Street was to be retained that the viaduct between there and Easter Road, which cut its way rudely through the back greens between Gordon Street and Thorntree Street would have been kept too.
1929 aerial photo showing the trackbed of the Leith New Lines between Easter Road (bottom right) heading west towards Leith Walk (top left). The large roof to the top right of the photo is Leith Central Station. That building along with the tenements along the line of Manderston and Gordon Streets have since been demolished. The large white roof belongs to the Capitol cinema, until recently a bingo hall. SPW027351 via Britain from Above.This ambitious urban realm scheme of course never came to pass. By the time an updated version of the Final Plan was published in 1980 it had been quietly dropped. One assumes this was because of the disruption caused to local government when the old unitary Corporation of the City of Edinburgh was replaced in 1975 and split up into the two-tier system of Edinburgh District Council and a combined Lothian Regional Council. Instead there was a cut back scheme to purchase the trackbed between Seafield and Easter Road and to landscape it as a pathway with funding from the Scottish Development Agency (SDA). While this at least did come to pass, the word “landscape” is doing a lot of heavy lifting and in reality this path was really just a strip of compressed dirt covered in dog mess and rubbish, with obstructive barriers to try and stop you cycling it without getting off and pushing. This would not be remedied until around 2010 when it was properly surface, the barriers were removed, new access points were added and lighting was provided.
Excerpt from 1980 report.Item 26 on the above list, the railway embankment through Pilrig Park, did also ended up being achieved although the link through to Leith Walk never happened. The viaduct from Pilrig Park to Leith Walk remains fence off, although recent redevelopment on the site of the former Leith Walk West goods yard means there is now a rather roundabout connection some 45 years later through an access road.
Looking along the viaduct above Jane Street towards Leith Walk on a very grey day in 2021. Photo © SelfItem 27, the second walkway which was planned in both 1975 and 1980, along the old North British Railway trackbed alongside the Water of Leith, from Coburg Street to Warriston, would come to pass. This opened in June 1982, making it the first old railway track to formally be converted to a foot and cycle path in Edinburgh, and the first of many more miles to come.
Line of the Coburg Street to Wariston section of the North British Railway, traced over a 1971 OS land use survey map on a 6-inch to the mile base map, 1966 survey. CC-by-NC-SA via National Library of ScotlandThe opportunity to do something between Pilrig Park and Easter Road is one that has never been properly grasped. In more recent times (although over 10 years ago now!) there was a semi-serious attempt to drum up interest in reviving the idea, with a connection between Pilrig Park and Halmyre Street achieved by building a show-piece timber and cable bridge across Leith Walk. How serious this actually was I do not know, I don’t recall any funding ever being in place even for planning, and providing level access to street level at the Thorntree Street end remains a difficult proposition. Even if it had been approved, like other schemes such as the section of Railway between Powderhall and Meadowbank, there’s a very good chance that it would still find itself in development limbo.
Renderings by Biomorphis of their engineered timber and cable bridge structure they proposed over Leith Walk.But if you happen to find yourself walking along past the garages which occupy the Manderston and Gordon Street arches, it’s easy to forget that there’s actually a railway station platform up there above your head, one which was built over 120 years ago but never actually opened. Although some lucky souls in the path have at least had the chance to get off a train there and head down its stairs to street level…
Note to readers: unfortunately in April 2026, a third-party plug-in more than exceeded its authority and broke many of the image links on this site. No images were lost but I will have to restore them page-by-page, which may take some time. In the meantime please bear with me while I go about rectifying this issue.
If you have found this site useful, informative or amusing then you can help contribute towards its running costs by supporting me on ko-fi. This includes my commitment to keeping it 100% advert and AI free for all time coming, and in helping to find further unusual stories to bring you by acquiring books and paying for research.
Or please do just share this post on social media or amongst friends and like-minded people, sites like this thrive on being shared.Explore Threadinburgh by map:
Travelers' Map is loading...
If you see this after your page is loaded completely, leafletJS files are missing.These threads © 2017-2026, Andy Arthur.
NO AI TRAINING: Any use of the contents of this website to “train” generative artificial intelligence (AI) technologies to generate text is expressly prohibited. The author reserves all rights to license uses of this work for generative AI training and development of machine learning language models.
#Lochend #Logan #Restalrig #StMargaret -
Why Can’t Humans Regrow Limbs? An Evolutionary Biologist Explains
Salamanders regrow entire limbs. We share their evolutionary blueprint. So why can’t humans do the same? The answer…
#NewsBeep #News #Science #Evolution #frog #GB #Howdoesregenerationwork #immunesystem #Immunology #larvalmetamorphosis #naturalselection #Regeneration #salamander #UK #UnitedKingdom #whycan'tweregrowlimbs
https://www.newsbeep.com/uk/577019/ -
https://www.europesays.com/uk/951124/ Why Can’t Humans Regrow Limbs? An Evolutionary Biologist Explains #evolution #frog #HowDoesRegenerationWork #ImmuneSystem #Immunology #LarvalMetamorphosis #NaturalSelection #Regeneration #salamander #Science #UK #UnitedKingdom #WhyCan'tWeRegrowLimbs
-
Hewwo! I'm a punk rawk salamander! 😝
#sculpture #art #salamander #rawr #streetart #babyfur #agere #sneppyfluffballphotos
-
Ever since the Invisible Salamanders paper was published, there has been a quiet renaissance within my friends and colleagues in applied cryptography for studying systems that use Authenticated Encryption with Associated Data (AEAD) constructions, understanding what implicit assumptions these systems make about the guarantees of the AEAD mode they chose to build upon, and the consequences of those assumptions being false.
I’ve discussed Invisible Salamanders several times throughout this blog, from my criticisms of AES-GCM and XMPP + OMEMO to my vulnerability disclosures in Threema.
Five years after Invisible Salamanders, it’s become clear to me that many software developers do not fully appreciate the underlying problem discussed in the Invisible Salamanders paper, even when I share trivial proof-of-concept exploits.
Background
Fast AEAD constructions based on polynomial MACs, such as AES-GCM and ChaCha20-Poly1305, were designed to provide confidentiality and integrity for the plaintext data, and optionally integrity for some additional associated data, in systems where both parties already negotiated one shared symmetric key.
The integrity goals of the systems that adopted these AEAD constructions were often accompanied by performance goals–usually to prevent Denial of Service (DoS) attacks in networking protocols. Verification needed to be very fast and consume minimal resources.
In this sense, AEAD constructions were an incredible success. So successful, in fact, that most cryptographers urge application developers to use one of the fast AEAD modes as the default suggestion without looking deeper at the problem being solved. This is a good thing, because most developers will choose something stupid like ECB mode in the absence of guidance from cryptographers, and AEAD modes are much, much safer than any hand-rolled block cipher modes.
The problem is, that one tiny little assumption that both parties (sender, recipient) for a communication have agreed on exactly one symmetric key for use in the protocol.
Fast MACs Are Not Key-Committing
Cryptographers have concluded that AEAD constructions based on polynomial MACs–while great for performance and rejection of malformed packets without creating DoS risks–tend to make the same assumption. This is even true of misuse-resistant modes like AES-GCM-SIV and extended-nonce constructions like XSalsa20-Poly1305.
When discussing this implicit assumption of only one valid key in the systems that use these AEAD modes, we say that the modes are not key-committing. This terminology is based on what happens when this assumption is false.
Consequently, you can take a single, specially crafted ciphertext (with an authentication tag) and decrypt it under multiple different keys. The authentication tags will be valid for all keys, and the plaintext will be different.
Art: SwizzWhat does this look like in practice?
Consider my GCM exploit, which was written to generate puzzle ciphertexts for the DEFCON Furs badge challenge a few years ago. How it works is conceptually simple (although the actual mechanics behind step 4 is a bit technical):
- Generate two keys.
There’s nothing special about these keys, or their relationship to each other, and can be totally random. They just can’t be identical or the exploit is kind of pointless.
- Encrypt some blocks of plaintext with key1.
- Encrypt some more blocks of plaintext with key2.
- Calculate a collision block from the ciphertext in the previous two steps–which is just a bit of polynomial arithmetic in GF(2^128)
- Return the ciphertext (steps 2, 3, 4) and authentication tag calculated over them (which will collide for both keys).
A system that decrypts the output of this exploit under key1 will see some plaintext, followed by some garbage, followed by 1 final block of garbage.
If the same system decrypts under key2, it will see some garbage, followed by some plaintext, followed by 1 final block of garbage.
For many file formats, this garbage isn’t really a problem. Additionally, a bit more precomputation allows you to choose garbage that will be more advantageous to ensuring both outputs are accepted as “valid” by the target system.
For example, choosing two keys and a targeted nonce may allow both the valid plaintext and garbage blocks to begin with a PDF file header.
If you’re familiar with the file polyglot work of Ange Albertini, you can use this to turn the invisible salamanders problem into an artform.
Why is it called Invisible Salamanders?
The proof-of-concept used in the paper involved sending one picture (of a salamander) over an end-to-end encrypted messaging app, but when the recipient flagged it as abusive, the moderator saw a different picture.
https://www.youtube.com/watch?v=3M1jIO-jLHI
Thus, the salamander was invisible to the moderators of the encrypted messaging app.
As for the choice of a “salamander”, I’ve been told by friends familiar with the research that was inspired by the original name of the Signal Protocol being “Axolotl”.
But, like, who cares about these details besides me? It’s a cute and memorable name.
What are the consequences of violating the “one key” assumption?
That depends entirely on what your system does!
In Database Cryptography Fur the Rest of Us, I discussed the use of AEAD modes to prevent confused deputy attacks. This works great, but if you’re building an application that supports multi-tenancy, you suddenly have to care about this issue again.
An earlier design for OPAQUE, a password authenticated key exchange algorithm, was broken by a partitioning oracle attack due to building atop AEAD modes that are not key-committing. This let an attacker recover passwords from Shadowsocks proxy servers with a complexity similar to a binary search algorithm.
These are two very different impacts from the same weakness, which I believe is a significant factor for why the Invisible Salamanders issue isn’t more widely understood.
Sometimes violating the “one key” assumption that went into fast AEAD modes based on Polynomial MACs completely destroys the security of your system.
Other times, it opens the door for a high-complexity but low-impact behavior that simply violates the principle of least astonishment but doesn’t buy the attacker anything useful.
They Just Don’t Get It
The Invisible Salamanders issue is relevant in any system that uses symmetric-key encryption where more than one key can be valid.
This includes, but is not limited to:
- Multi-tenant data warehouses
- Group messaging protocols
- Envelope encryption schemes with multiple wrapping keys
- Bearer tokens (such as JSON Web Tokens) in systems that utilize Key IDs
Systems can mitigate this issue by introducing an explicit key commitment scheme (based on a cryptographic hash rather than a polynomial MAC) or by using a committing cipher mode (such as AES + HMAC, if done carefully).
However, most of the time, this advice falls on deaf ears whenever this concern is brought up by a cryptography engineer who’s more aware of this issue.
“Abuse reporting? We don’t have no stinking abuse reporting!”
The most common misunderstanding is, “We don’t have a report abuse feature, so this issue doesn’t affect us.”
This is because the Invisible Salamanders talk and paper focused on how it could be leveraged to defeat abuse reporting tools and bypass content moderation.
In my experience, many security teams would read the paper and conclude that it only impacts abuse reporting features and not potentially all systems that allow multiple symmetric keys in a given context.
Another Exploit Scenario
Imagine you’re building a Data Loss Prevention product that integrates with corporate file-sharing and collaboration software (e.g. ownCloud) for small and medium businesses.
One day, someone decides to ship an end-to-end encryption feature to the file-sharing software that uses AES-GCM to encrypt files, and then encrypts the keys to each recipient’s public key. This is basically the envelope encryption use-case above.
In order to update your integration to act as another “user”, whose public key must be included in all E2EE transfers, and will block download of ciphertexts it cannot decrypt OR contains sensitive information.
And this works, until an insider threat clever enough to abuse the Invisible Salamanders issue comes along.
In order for said insider threat (e.g., a senior business analyst) to leak sensitive data (e.g., anything that would be useful for illegal insider trading) to another person that shouldn’t have access to it (e.g., a store clerk that’s talking to the press), they just have to do this:
- Encrypt the data they want to exfiltrate using key1.
- Encrypt some innocuous data that won’t trigger your DLP product, using key2.
- Ensure that both messages encrypt to the same ciphertext and authentication tag.
- Give their recipient key1, give everyone else (including your DLP software) key2.
Bam! File leaked, and everyone’s none the wiser, until it’s too late. Let’s actually imagine what happens next:
A random store clerk has leaked sensitive data to the press that only a few analysts had access to.
The only communication between the analyst and the store clerk is a file that was shared to all employees, using the E2EE protocol. No emails or anything else were identified.
Your DLP product didn’t identify any other communications between these two, but somehow the store clerk has the data on their desktop.
A detailed forensics analysis may eventually figure out what happened, but by then, the damage is done and your product’s reputation is irrecoverably damaged.
All because the hypothetical E2EE protocol didn’t include a key-commitment mechanism, and nobody identified this deficit in their designs.
This isn’t to endorse DLP solutions at all, but rather, to highlight one of the many ways that the Invisible Salamander issue can be used creatively by clever attackers.
Art: AJThe Lesson to Learn
If you’re building a network protocol that uses AEAD to encrypt data over an insecure network (e.g., WireGuard), keep up the good work.
If you’re doing anything more involved than that, at the application layer, pause for a moment and consider whether your system will ever need multiple valid symmetric keys at once.
And, if the answer is “yes”, then you should always explicitly add a key-commitment mechanism to your system design.
(Hire a cryptographer if you’re not sure how to proceed.)
In my opinion, hemming and hawing over whether there’s a significant impact to the Invisible Salamanders issue is a worse use of your time than just solving it directly.
Eventually, I expect a new generation of AEAD modes will be standardized that explicitly provide key-commitment.
When these new designs are standardized, widely supported, and sufficiently trusted by experts, feel free to update my advice to “prefer using those modes” instead.
Header art: Harubaki, CMYKat, and Brian Gratwicke
https://soatok.blog/2024/09/10/invisible-salamanders-are-not-what-you-think/
#AEAD #AESGCM #InvisibleSalamanders #randomKeyRobustness #symmetricCryptography
- Generate two keys.
-
Ever since the Invisible Salamanders paper was published, there has been a quiet renaissance within my friends and colleagues in applied cryptography for studying systems that use Authenticated Encryption with Associated Data (AEAD) constructions, understanding what implicit assumptions these systems make about the guarantees of the AEAD mode they chose to build upon, and the consequences of those assumptions being false.
I’ve discussed Invisible Salamanders several times throughout this blog, from my criticisms of AES-GCM and XMPP + OMEMO to my vulnerability disclosures in Threema.
Five years after Invisible Salamanders, it’s become clear to me that many software developers do not fully appreciate the underlying problem discussed in the Invisible Salamanders paper, even when I share trivial proof-of-concept exploits.
Background
Fast AEAD constructions based on polynomial MACs, such as AES-GCM and ChaCha20-Poly1305, were designed to provide confidentiality and integrity for the plaintext data, and optionally integrity for some additional associated data, in systems where both parties already negotiated one shared symmetric key.
The integrity goals of the systems that adopted these AEAD constructions were often accompanied by performance goals–usually to prevent Denial of Service (DoS) attacks in networking protocols. Verification needed to be very fast and consume minimal resources.
In this sense, AEAD constructions were an incredible success. So successful, in fact, that most cryptographers urge application developers to use one of the fast AEAD modes as the default suggestion without looking deeper at the problem being solved. This is a good thing, because most developers will choose something stupid like ECB mode in the absence of guidance from cryptographers, and AEAD modes are much, much safer than any hand-rolled block cipher modes.
The problem is, that one tiny little assumption that both parties (sender, recipient) for a communication have agreed on exactly one symmetric key for use in the protocol.
Fast MACs Are Not Key-Committing
Cryptographers have concluded that AEAD constructions based on polynomial MACs–while great for performance and rejection of malformed packets without creating DoS risks–tend to make the same assumption. This is even true of misuse-resistant modes like AES-GCM-SIV and extended-nonce constructions like XSalsa20-Poly1305.
When discussing this implicit assumption of only one valid key in the systems that use these AEAD modes, we say that the modes are not key-committing. This terminology is based on what happens when this assumption is false.
Consequently, you can take a single, specially crafted ciphertext (with an authentication tag) and decrypt it under multiple different keys. The authentication tags will be valid for all keys, and the plaintext will be different.
Art: SwizzWhat does this look like in practice?
Consider my GCM exploit, which was written to generate puzzle ciphertexts for the DEFCON Furs badge challenge a few years ago. How it works is conceptually simple (although the actual mechanics behind step 4 is a bit technical):
- Generate two keys.
There’s nothing special about these keys, or their relationship to each other, and can be totally random. They just can’t be identical or the exploit is kind of pointless.
- Encrypt some blocks of plaintext with key1.
- Encrypt some more blocks of plaintext with key2.
- Calculate a collision block from the ciphertext in the previous two steps–which is just a bit of polynomial arithmetic in GF(2^128)
- Return the ciphertext (steps 2, 3, 4) and authentication tag calculated over them (which will collide for both keys).
A system that decrypts the output of this exploit under key1 will see some plaintext, followed by some garbage, followed by 1 final block of garbage.
If the same system decrypts under key2, it will see some garbage, followed by some plaintext, followed by 1 final block of garbage.
For many file formats, this garbage isn’t really a problem. Additionally, a bit more precomputation allows you to choose garbage that will be more advantageous to ensuring both outputs are accepted as “valid” by the target system.
For example, choosing two keys and a targeted nonce may allow both the valid plaintext and garbage blocks to begin with a PDF file header.
If you’re familiar with the file polyglot work of Ange Albertini, you can use this to turn the Invisible Salamanders problem into an artform.
And this is just the simple attack!
The Invisible Salamanders paper outlined a more advanced variant (with a proof of concept) in Section 3.2, which doesn’t suffer from nearly as much garbage data as the simple attack.
As Bruce Schneier often says, “Attacks only get better, they never get worse.”
Why is it called Invisible Salamanders?
The proof-of-concept used in the paper involved sending one picture (of a salamander) over an end-to-end encrypted messaging app, but when the recipient flagged it as abusive, the moderator saw a different picture.
https://www.youtube.com/watch?v=3M1jIO-jLHI
Thus, the salamander was invisible to the moderators of the encrypted messaging app.
As for the choice of a “salamander”, I’ve been told by friends familiar with the research that was inspired by the original name of the Signal Protocol being “Axolotl”.
But, like, who cares about these details besides me? It’s a cute and memorable name.
What are the consequences of violating the “one key” assumption?
That depends entirely on what your system does!
In Database Cryptography Fur the Rest of Us, I discussed the use of AEAD modes to prevent confused deputy attacks. This works great, but if you’re building an application that supports multi-tenancy, you suddenly have to care about this issue again.
An earlier design for OPAQUE, a password authenticated key exchange algorithm, was broken by a partitioning oracle attack due to building atop AEAD modes that are not key-committing. This let an attacker recover passwords from Shadowsocks proxy servers with a complexity similar to a binary search algorithm.
These are two very different impacts from the same weakness, which I believe is a significant factor for why the Invisible Salamanders issue isn’t more widely understood.
Sometimes violating the “one key” assumption that went into fast AEAD modes based on Polynomial MACs completely destroys the security of your system.
Other times, it opens the door for a high-complexity but low-impact behavior that simply violates the principle of least astonishment but doesn’t buy the attacker anything useful.
They Just Don’t Get It
The Invisible Salamanders issue is relevant in any system that uses symmetric-key encryption where more than one key can be valid.
This includes, but is not limited to:
- Multi-tenant data warehouses
- Group messaging protocols
- It’s sometimes tempting to discount group messaging as a relevant consideration if your experience is “emulated groups atop 1-to-1 messaging”, but there are protocols that establish a Group Key (i.e., RFC 9420) and then use that for all group messages.
- Envelope encryption schemes with multiple wrapping keys
- Bearer tokens (such as JSON Web Tokens) in systems that utilize Key IDs
Systems can mitigate this issue by introducing an explicit key commitment scheme (based on a cryptographic hash rather than a polynomial MAC) or by using a committing cipher mode (such as AES + HMAC, if done carefully).
However, most of the time, this advice falls on deaf ears whenever this concern is brought up by a cryptography engineer who’s more aware of this issue.
“Abuse reporting? We don’t have no stinking abuse reporting!”
The most common misunderstanding is, “We don’t have a report abuse feature, so this issue doesn’t affect us.”
This is because the Invisible Salamanders talk and paper focused on how it could be leveraged to defeat abuse reporting tools and bypass content moderation.
In my experience, many security teams would read the paper and conclude that it only impacts abuse reporting features and not potentially all systems that allow multiple symmetric keys in a given context.
Another Exploit Scenario
Imagine you’re building a Data Loss Prevention product that integrates with corporate file-sharing and collaboration software (e.g. ownCloud) for small and medium businesses.
One day, someone decides to ship an end-to-end encryption feature to the file-sharing software that uses AES-GCM to encrypt files, and then encrypts the keys to each recipient’s public key. This is basically the envelope encryption use-case above.
So, you dutifully update your integration to act as another “user”, whose public key must be included in all E2EE transfers, and will block download of ciphertexts it cannot decrypt OR contains sensitive information.
And this works, until an insider threat clever enough to abuse the Invisible Salamanders issue comes along.
In order for said insider threat (e.g., a senior business analyst) to leak sensitive data (e.g., anything that would be useful for illegal insider trading) to another person that shouldn’t have access to it (e.g., a store clerk that’s talking to the press), they just have to do this:
- Encrypt the data they want to exfiltrate using key1.
- Encrypt some innocuous data that won’t trigger your DLP product, using key2.
- Ensure that both messages encrypt to the same ciphertext and authentication tag.
- Give their recipient key1, give everyone else (including your DLP software) key2.
Bam! File leaked, and everyone’s none the wiser, until it’s too late. Let’s actually imagine what happens next:
A random store clerk has leaked sensitive data to the press that only a few analysts had access to.
The only communication between the analyst and the store clerk is a file that was shared to all employees, using the E2EE protocol. No emails or anything else were identified.
Your DLP product didn’t identify any other communications between these two, but somehow the store clerk has the data on their desktop.
A detailed forensics analysis may eventually figure out what happened, but by then, the damage is done and your product’s reputation is irrecoverably damaged.
All because the hypothetical E2EE protocol didn’t include a key-commitment mechanism, and nobody identified this deficit in their designs.
This isn’t to endorse DLP solutions at all, but rather, to highlight one of the many ways that the Invisible Salamander issue can be used creatively by clever attackers.
Art: AJ“Couldn’t you do the same with steganography?”
No, the attack is very different from stego.
Stego is about hiding a message in plain sight, so that only the person that knows where/how to look can find it.
The Invisible Salamanders attack lets you send one ciphertext through a network then selectively decrypt it to one of two plaintexts, depending on which key you reveal to each participant.
In the Invisible Salamanders paper and talk, they used this to send “abusive” messages to a recipient that the moderator would not see. Thus, invisible.
In one, the message is always emitted to anyone who knows how to find it. In the other, the attacker selects which you see, even if you have mechanisms to ensure you’re seeing the same ciphertext. It’s not a subtle difference.
Mitigation Techniques
There are multiple ways to mitigate the risk of Invisible Salamanders in a cryptosystem.
- Use HMAC, or (failing that) something built atop cryptographic hash functions, rather than a Polynomial MAC.
- Use an AEAD cipher designed with multi-recipient integrity as a security goal.
- Compute a non-invertible, one-way commitment of the encryption key.
A trivial mitigation looks like this:
class SoatokExampleEncryptor { const NEW_ENCRYPT_KEY = 'myProtocol$encryptKey'; const NEW_COMMITMENT = 'myProtocol$commitment'; public function __construct(#[SensitiveParameter] private string $key) {} /** * Let's assume we're starting with a simple AES-GCM wrapper */ public function legacyEncrypt(string $plaintext, string $assocData = ''): string { $nonce = random_bytes(12); $tag = ''; $ciphertext = openssl_encrypt( $plaintext, 'aes-256-gcm', $this->key, OPENSSL_RAW_DATA, $nonce, $tag, $assocData ); return $nonce . $ciphertext . $tag; } /** * An improved function looks something like this */ public function newEncrypt(string $plaintext, string $assocData = ''): string { // Avoid birthday bound issues with 256-bits of randomness $longerNonce = random_bytes(32); // Derive a subkey and synthetic nonce $tmp = hash_hkdf('sha512', $this->key, 44, self::NEW_ENCRYPT_KEY . $longerNonce); $encKey = substr($tmp, 0, 32); $nonce = substr($tmp, 32); // New: Key commitment $commitment = hash_hkdf('sha512', $this->key, 32, self::NEW_COMMITMENT . $longerNonce); // Most of this is unchanged $tag = ''; $ciphertext = openssl_encrypt( $plaintext, 'aes-256-gcm', $encKey, OPENSSL_RAW_DATA, $nonce, $tag, $assocData ); return $longerNonce . $commitment . $ciphertext . $tag; }}And then the decryption logic would recalculate the commitment, and compare it with the stored value, in constant-time.
It’s important that the commitment be stored with the ciphertext, rather than bundling it with the key.
(It may be worthwhile to also include the commitment in the associated data, to add a mechanism against downgrade attacks.)
The Lesson to Learn
If you’re building a network protocol that uses AEAD to encrypt data over an insecure network (e.g., WireGuard), keep up the good work.
If you’re doing anything more involved than that, at the application layer, pause for a moment and consider whether your system will ever need multiple valid symmetric keys at once.
And, if the answer is “yes”, then you should always explicitly add a key-commitment mechanism to your system design.
(Hire a cryptographer if you’re not sure how to proceed.)
In my opinion, hemming and hawing over whether there’s a significant impact to the Invisible Salamanders issue is a worse use of your time than just solving it directly.
Eventually, I expect a new generation of AEAD modes will be standardized that explicitly provide key-commitment.
When these new designs are standardized, widely supported, and sufficiently trusted by experts, feel free to update my advice to “prefer using those modes” instead.
Header art: Harubaki, CMYKat, and a photo by Brian Gratwicke. Poorly photoshopped by myself.
https://soatok.blog/2024/09/10/invisible-salamanders-are-not-what-you-think/
#AEAD #AESGCM #InvisibleSalamanders #randomKeyRobustness #symmetricCryptography
- Generate two keys.
-
Ever since the Invisible Salamanders paper was published, there has been a quiet renaissance within my friends and colleagues in applied cryptography for studying systems that use Authenticated Encryption with Associated Data (AEAD) constructions, understanding what implicit assumptions these systems make about the guarantees of the AEAD mode they chose to build upon, and the consequences of those assumptions being false.
I’ve discussed Invisible Salamanders several times throughout this blog, from my criticisms of AES-GCM and XMPP + OMEMO to my vulnerability disclosures in Threema.
Five years after Invisible Salamanders, it’s become clear to me that many software developers do not fully appreciate the underlying problem discussed in the Invisible Salamanders paper, even when I share trivial proof-of-concept exploits.
Background
Fast AEAD constructions based on polynomial MACs, such as AES-GCM and ChaCha20-Poly1305, were designed to provide confidentiality and integrity for the plaintext data, and optionally integrity for some additional associated data, in systems where both parties already negotiated one shared symmetric key.
The integrity goals of the systems that adopted these AEAD constructions were often accompanied by performance goals–usually to prevent Denial of Service (DoS) attacks in networking protocols. Verification needed to be very fast and consume minimal resources.
In this sense, AEAD constructions were an incredible success. So successful, in fact, that most cryptographers urge application developers to use one of the fast AEAD modes as the default suggestion without looking deeper at the problem being solved. This is a good thing, because most developers will choose something stupid like ECB mode in the absence of guidance from cryptographers, and AEAD modes are much, much safer than any hand-rolled block cipher modes.
The problem is, that one tiny little assumption that both parties (sender, recipient) for a communication have agreed on exactly one symmetric key for use in the protocol.
Fast MACs Are Not Key-Committing
Cryptographers have concluded that AEAD constructions based on polynomial MACs–while great for performance and rejection of malformed packets without creating DoS risks–tend to make the same assumption. This is even true of misuse-resistant modes like AES-GCM-SIV and extended-nonce constructions like XSalsa20-Poly1305.
When discussing this implicit assumption of only one valid key in the systems that use these AEAD modes, we say that the modes are not key-committing. This terminology is based on what happens when this assumption is false.
Consequently, you can take a single, specially crafted ciphertext (with an authentication tag) and decrypt it under multiple different keys. The authentication tags will be valid for all keys, and the plaintext will be different.
Art: SwizzWhat does this look like in practice?
Consider my GCM exploit, which was written to generate puzzle ciphertexts for the DEFCON Furs badge challenge a few years ago. How it works is conceptually simple (although the actual mechanics behind step 4 is a bit technical):
- Generate two keys.
There’s nothing special about these keys, or their relationship to each other, and can be totally random. They just can’t be identical or the exploit is kind of pointless.
- Encrypt some blocks of plaintext with key1.
- Encrypt some more blocks of plaintext with key2.
- Calculate a collision block from the ciphertext in the previous two steps–which is just a bit of polynomial arithmetic in GF(2^128)
- Return the ciphertext (steps 2, 3, 4) and authentication tag calculated over them (which will collide for both keys).
A system that decrypts the output of this exploit under key1 will see some plaintext, followed by some garbage, followed by 1 final block of garbage.
If the same system decrypts under key2, it will see some garbage, followed by some plaintext, followed by 1 final block of garbage.
For many file formats, this garbage isn’t really a problem. Additionally, a bit more precomputation allows you to choose garbage that will be more advantageous to ensuring both outputs are accepted as “valid” by the target system.
For example, choosing two keys and a targeted nonce may allow both the valid plaintext and garbage blocks to begin with a PDF file header.
If you’re familiar with the file polyglot work of Ange Albertini, you can use this to turn the Invisible Salamanders problem into an artform.
And this is just the simple attack!
The Invisible Salamanders paper outlined a more advanced variant (with a proof of concept) in Section 3.2, which doesn’t suffer from nearly as much garbage data as the simple attack.
As Bruce Schneier often says, “Attacks only get better, they never get worse.”
Why is it called Invisible Salamanders?
The proof-of-concept used in the paper involved sending one picture (of a salamander) over an end-to-end encrypted messaging app, but when the recipient flagged it as abusive, the moderator saw a different picture.
https://www.youtube.com/watch?v=3M1jIO-jLHI
Thus, the salamander was invisible to the moderators of the encrypted messaging app.
As for the choice of a “salamander”, I’ve been told by friends familiar with the research that was inspired by the original name of the Signal Protocol being “Axolotl”.
But, like, who cares about these details besides me? It’s a cute and memorable name.
What are the consequences of violating the “one key” assumption?
That depends entirely on what your system does!
In Database Cryptography Fur the Rest of Us, I discussed the use of AEAD modes to prevent confused deputy attacks. This works great, but if you’re building an application that supports multi-tenancy, you suddenly have to care about this issue again.
An earlier design for OPAQUE, a password authenticated key exchange algorithm, was broken by a partitioning oracle attack due to building atop AEAD modes that are not key-committing. This let an attacker recover passwords from Shadowsocks proxy servers with a complexity similar to a binary search algorithm.
These are two very different impacts from the same weakness, which I believe is a significant factor for why the Invisible Salamanders issue isn’t more widely understood.
Sometimes violating the “one key” assumption that went into fast AEAD modes based on Polynomial MACs completely destroys the security of your system.
Other times, it opens the door for a high-complexity but low-impact behavior that simply violates the principle of least astonishment but doesn’t buy the attacker anything useful.
They Just Don’t Get It
The Invisible Salamanders issue is relevant in any system that uses symmetric-key encryption where more than one key can be valid.
This includes, but is not limited to:
- Multi-tenant data warehouses
- Group messaging protocols
- It’s sometimes tempting to discount group messaging as a relevant consideration if your experience is “emulated groups atop 1-to-1 messaging”, but there are protocols that establish a Group Key (i.e., RFC 9420) and then use that for all group messages.
- Envelope encryption schemes with multiple wrapping keys
- Bearer tokens (such as JSON Web Tokens) in systems that utilize Key IDs
Systems can mitigate this issue by introducing an explicit key commitment scheme (based on a cryptographic hash rather than a polynomial MAC) or by using a committing cipher mode (such as AES + HMAC, if done carefully).
However, most of the time, this advice falls on deaf ears whenever this concern is brought up by a cryptography engineer who’s more aware of this issue.
“Abuse reporting? We don’t have no stinking abuse reporting!”
The most common misunderstanding is, “We don’t have a report abuse feature, so this issue doesn’t affect us.”
This is because the Invisible Salamanders talk and paper focused on how it could be leveraged to defeat abuse reporting tools and bypass content moderation.
In my experience, many security teams would read the paper and conclude that it only impacts abuse reporting features and not potentially all systems that allow multiple symmetric keys in a given context.
Another Exploit Scenario
Imagine you’re building a Data Loss Prevention product that integrates with corporate file-sharing and collaboration software (e.g. ownCloud) for small and medium businesses.
One day, someone decides to ship an end-to-end encryption feature to the file-sharing software that uses AES-GCM to encrypt files, and then encrypts the keys to each recipient’s public key. This is basically the envelope encryption use-case above.
So, you dutifully update your integration to act as another “user”, whose public key must be included in all E2EE transfers, and will block download of ciphertexts it cannot decrypt OR contains sensitive information.
And this works, until an insider threat clever enough to abuse the Invisible Salamanders issue comes along.
In order for said insider threat (e.g., a senior business analyst) to leak sensitive data (e.g., anything that would be useful for illegal insider trading) to another person that shouldn’t have access to it (e.g., a store clerk that’s talking to the press), they just have to do this:
- Encrypt the data they want to exfiltrate using key1.
- Encrypt some innocuous data that won’t trigger your DLP product, using key2.
- Ensure that both messages encrypt to the same ciphertext and authentication tag.
- Give their recipient key1, give everyone else (including your DLP software) key2.
Bam! File leaked, and everyone’s none the wiser, until it’s too late. Let’s actually imagine what happens next:
A random store clerk has leaked sensitive data to the press that only a few analysts had access to.
The only communication between the analyst and the store clerk is a file that was shared to all employees, using the E2EE protocol. No emails or anything else were identified.
Your DLP product didn’t identify any other communications between these two, but somehow the store clerk has the data on their desktop.
A detailed forensics analysis may eventually figure out what happened, but by then, the damage is done and your product’s reputation is irrecoverably damaged.
All because the hypothetical E2EE protocol didn’t include a key-commitment mechanism, and nobody identified this deficit in their designs.
This isn’t to endorse DLP solutions at all, but rather, to highlight one of the many ways that the Invisible Salamander issue can be used creatively by clever attackers.
Art: AJ“Couldn’t you do the same with steganography?”
No, the attack is very different from stego.
Stego is about hiding a message in plain sight, so that only the person that knows where/how to look can find it.
The Invisible Salamanders attack lets you send one ciphertext through a network then selectively decrypt it to one of two plaintexts, depending on which key you reveal to each participant.
In the Invisible Salamanders paper and talk, they used this to send “abusive” messages to a recipient that the moderator would not see. Thus, invisible.
In one, the message is always emitted to anyone who knows how to find it. In the other, the attacker selects which you see, even if you have mechanisms to ensure you’re seeing the same ciphertext. It’s not a subtle difference.
Mitigation Techniques
There are multiple ways to mitigate the risk of Invisible Salamanders in a cryptosystem.
- Use HMAC, or (failing that) something built atop cryptographic hash functions, rather than a Polynomial MAC.
- Use an AEAD cipher designed with multi-recipient integrity as a security goal.
- Compute a non-invertible, one-way commitment of the encryption key.
A trivial mitigation looks like this:
class SoatokExampleEncryptor { const NEW_ENCRYPT_KEY = 'myProtocol$encryptKey'; const NEW_COMMITMENT = 'myProtocol$commitment'; public function __construct(#[SensitiveParameter] private string $key) {} /** * Let's assume we're starting with a simple AES-GCM wrapper */ public function legacyEncrypt(string $plaintext, string $assocData = ''): string { $nonce = random_bytes(12); $tag = ''; $ciphertext = openssl_encrypt( $plaintext, 'aes-256-gcm', $this->key, OPENSSL_RAW_DATA, $nonce, $tag, $assocData ); return $nonce . $ciphertext . $tag; } /** * An improved function looks something like this */ public function newEncrypt(string $plaintext, string $assocData = ''): string { // Avoid birthday bound issues with 256-bits of randomness $longerNonce = random_bytes(32); // Derive a subkey and synthetic nonce $tmp = hash_hkdf('sha512', $this->key, 44, self::NEW_ENCRYPT_KEY . $longerNonce); $encKey = substr($tmp, 0, 32); $nonce = substr($tmp, 32); // New: Key commitment $commitment = hash_hkdf('sha512', $this->key, 32, self::NEW_COMMITMENT . $longerNonce); // Most of this is unchanged $tag = ''; $ciphertext = openssl_encrypt( $plaintext, 'aes-256-gcm', $encKey, OPENSSL_RAW_DATA, $nonce, $tag, $assocData ); return $longerNonce . $commitment . $ciphertext . $tag; }}And then the decryption logic would recalculate the commitment, and compare it with the stored value, in constant-time.
It’s important that the commitment be stored with the ciphertext, rather than bundling it with the key.
(It may be worthwhile to also include the commitment in the associated data, to add a mechanism against downgrade attacks.)
The Lesson to Learn
If you’re building a network protocol that uses AEAD to encrypt data over an insecure network (e.g., WireGuard), keep up the good work.
If you’re doing anything more involved than that, at the application layer, pause for a moment and consider whether your system will ever need multiple valid symmetric keys at once.
And, if the answer is “yes”, then you should always explicitly add a key-commitment mechanism to your system design.
(Hire a cryptographer if you’re not sure how to proceed.)
In my opinion, hemming and hawing over whether there’s a significant impact to the Invisible Salamanders issue is a worse use of your time than just solving it directly.
Eventually, I expect a new generation of AEAD modes will be standardized that explicitly provide key-commitment.
When these new designs are standardized, widely supported, and sufficiently trusted by experts, feel free to update my advice to “prefer using those modes” instead.
Header art: Harubaki, CMYKat, and a photo by Brian Gratwicke. Poorly photoshopped by myself.
https://soatok.blog/2024/09/10/invisible-salamanders-are-not-what-you-think/
#AEAD #AESGCM #InvisibleSalamanders #randomKeyRobustness #symmetricCryptography
- Generate two keys.
-
Ever since the Invisible Salamanders paper was published, there has been a quiet renaissance within my friends and colleagues in applied cryptography for studying systems that use Authenticated Encryption with Associated Data (AEAD) constructions, understanding what implicit assumptions these systems make about the guarantees of the AEAD mode they chose to build upon, and the consequences of those assumptions being false.
I’ve discussed Invisible Salamanders several times throughout this blog, from my criticisms of AES-GCM and XMPP + OMEMO to my vulnerability disclosures in Threema.
Five years after Invisible Salamanders, it’s become clear to me that many software developers do not fully appreciate the underlying problem discussed in the Invisible Salamanders paper, even when I share trivial proof-of-concept exploits.
Background
Fast AEAD constructions based on polynomial MACs, such as AES-GCM and ChaCha20-Poly1305, were designed to provide confidentiality and integrity for the plaintext data, and optionally integrity for some additional associated data, in systems where both parties already negotiated one shared symmetric key.
The integrity goals of the systems that adopted these AEAD constructions were often accompanied by performance goals–usually to prevent Denial of Service (DoS) attacks in networking protocols. Verification needed to be very fast and consume minimal resources.
In this sense, AEAD constructions were an incredible success. So successful, in fact, that most cryptographers urge application developers to use one of the fast AEAD modes as the default suggestion without looking deeper at the problem being solved. This is a good thing, because most developers will choose something stupid like ECB mode in the absence of guidance from cryptographers, and AEAD modes are much, much safer than any hand-rolled block cipher modes.
The problem is, that one tiny little assumption that both parties (sender, recipient) for a communication have agreed on exactly one symmetric key for use in the protocol.
Fast MACs Are Not Key-Committing
Cryptographers have concluded that AEAD constructions based on polynomial MACs–while great for performance and rejection of malformed packets without creating DoS risks–tend to make the same assumption. This is even true of misuse-resistant modes like AES-GCM-SIV and extended-nonce constructions like XSalsa20-Poly1305.
When discussing this implicit assumption of only one valid key in the systems that use these AEAD modes, we say that the modes are not key-committing. This terminology is based on what happens when this assumption is false.
Consequently, you can take a single, specially crafted ciphertext (with an authentication tag) and decrypt it under multiple different keys. The authentication tags will be valid for all keys, and the plaintext will be different.
Art: SwizzWhat does this look like in practice?
Consider my GCM exploit, which was written to generate puzzle ciphertexts for the DEFCON Furs badge challenge a few years ago. How it works is conceptually simple (although the actual mechanics behind step 4 is a bit technical):
- Generate two keys.
There’s nothing special about these keys, or their relationship to each other, and can be totally random. They just can’t be identical or the exploit is kind of pointless.
- Encrypt some blocks of plaintext with key1.
- Encrypt some more blocks of plaintext with key2.
- Calculate a collision block from the ciphertext in the previous two steps–which is just a bit of polynomial arithmetic in GF(2^128)
- Return the ciphertext (steps 2, 3, 4) and authentication tag calculated over them (which will collide for both keys).
A system that decrypts the output of this exploit under key1 will see some plaintext, followed by some garbage, followed by 1 final block of garbage.
If the same system decrypts under key2, it will see some garbage, followed by some plaintext, followed by 1 final block of garbage.
For many file formats, this garbage isn’t really a problem. Additionally, a bit more precomputation allows you to choose garbage that will be more advantageous to ensuring both outputs are accepted as “valid” by the target system.
For example, choosing two keys and a targeted nonce may allow both the valid plaintext and garbage blocks to begin with a PDF file header.
If you’re familiar with the file polyglot work of Ange Albertini, you can use this to turn the invisible salamanders problem into an artform.
Why is it called Invisible Salamanders?
The proof-of-concept used in the paper involved sending one picture (of a salamander) over an end-to-end encrypted messaging app, but when the recipient flagged it as abusive, the moderator saw a different picture.
https://www.youtube.com/watch?v=3M1jIO-jLHI
Thus, the salamander was invisible to the moderators of the encrypted messaging app.
As for the choice of a “salamander”, I’ve been told by friends familiar with the research that was inspired by the original name of the Signal Protocol being “Axolotl”.
But, like, who cares about these details besides me? It’s a cute and memorable name.
What are the consequences of violating the “one key” assumption?
That depends entirely on what your system does!
In Database Cryptography Fur the Rest of Us, I discussed the use of AEAD modes to prevent confused deputy attacks. This works great, but if you’re building an application that supports multi-tenancy, you suddenly have to care about this issue again.
An earlier design for OPAQUE, a password authenticated key exchange algorithm, was broken by a partitioning oracle attack due to building atop AEAD modes that are not key-committing. This let an attacker recover passwords from Shadowsocks proxy servers with a complexity similar to a binary search algorithm.
These are two very different impacts from the same weakness, which I believe is a significant factor for why the Invisible Salamanders issue isn’t more widely understood.
Sometimes violating the “one key” assumption that went into fast AEAD modes based on Polynomial MACs completely destroys the security of your system.
Other times, it opens the door for a high-complexity but low-impact behavior that simply violates the principle of least astonishment but doesn’t buy the attacker anything useful.
They Just Don’t Get It
The Invisible Salamanders issue is relevant in any system that uses symmetric-key encryption where more than one key can be valid.
This includes, but is not limited to:
- Multi-tenant data warehouses
- Group messaging protocols
- Envelope encryption schemes with multiple wrapping keys
- Bearer tokens (such as JSON Web Tokens) in systems that utilize Key IDs
Systems can mitigate this issue by introducing an explicit key commitment scheme (based on a cryptographic hash rather than a polynomial MAC) or by using a committing cipher mode (such as AES + HMAC, if done carefully).
However, most of the time, this advice falls on deaf ears whenever this concern is brought up by a cryptography engineer who’s more aware of this issue.
“Abuse reporting? We don’t have no stinking abuse reporting!”
The most common misunderstanding is, “We don’t have a report abuse feature, so this issue doesn’t affect us.”
This is because the Invisible Salamanders talk and paper focused on how it could be leveraged to defeat abuse reporting tools and bypass content moderation.
In my experience, many security teams would read the paper and conclude that it only impacts abuse reporting features and not potentially all systems that allow multiple symmetric keys in a given context.
Another Exploit Scenario
Imagine you’re building a Data Loss Prevention product that integrates with corporate file-sharing and collaboration software (e.g. ownCloud) for small and medium businesses.
One day, someone decides to ship an end-to-end encryption feature to the file-sharing software that uses AES-GCM to encrypt files, and then encrypts the keys to each recipient’s public key. This is basically the envelope encryption use-case above.
In order to update your integration to act as another “user”, whose public key must be included in all E2EE transfers, and will block download of ciphertexts it cannot decrypt OR contains sensitive information.
And this works, until an insider threat clever enough to abuse the Invisible Salamanders issue comes along.
In order for said insider threat (e.g., a senior business analyst) to leak sensitive data (e.g., anything that would be useful for illegal insider trading) to another person that shouldn’t have access to it (e.g., a store clerk that’s talking to the press), they just have to do this:
- Encrypt the data they want to exfiltrate using key1.
- Encrypt some innocuous data that won’t trigger your DLP product, using key2.
- Ensure that both messages encrypt to the same ciphertext and authentication tag.
- Give their recipient key1, give everyone else (including your DLP software) key2.
Bam! File leaked, and everyone’s none the wiser, until it’s too late. Let’s actually imagine what happens next:
A random store clerk has leaked sensitive data to the press that only a few analysts had access to.
The only communication between the analyst and the store clerk is a file that was shared to all employees, using the E2EE protocol. No emails or anything else were identified.
Your DLP product didn’t identify any other communications between these two, but somehow the store clerk has the data on their desktop.
A detailed forensics analysis may eventually figure out what happened, but by then, the damage is done and your product’s reputation is irrecoverably damaged.
All because the hypothetical E2EE protocol didn’t include a key-commitment mechanism, and nobody identified this deficit in their designs.
This isn’t to endorse DLP solutions at all, but rather, to highlight one of the many ways that the Invisible Salamander issue can be used creatively by clever attackers.
Art: AJThe Lesson to Learn
If you’re building a network protocol that uses AEAD to encrypt data over an insecure network (e.g., WireGuard), keep up the good work.
If you’re doing anything more involved than that, at the application layer, pause for a moment and consider whether your system will ever need multiple valid symmetric keys at once.
And, if the answer is “yes”, then you should always explicitly add a key-commitment mechanism to your system design.
(Hire a cryptographer if you’re not sure how to proceed.)
In my opinion, hemming and hawing over whether there’s a significant impact to the Invisible Salamanders issue is a worse use of your time than just solving it directly.
Eventually, I expect a new generation of AEAD modes will be standardized that explicitly provide key-commitment.
When these new designs are standardized, widely supported, and sufficiently trusted by experts, feel free to update my advice to “prefer using those modes” instead.
Header art: Harubaki, CMYKat, and Brian Gratwicke
https://soatok.blog/2024/09/10/invisible-salamanders-are-not-what-you-think/
#AEAD #AESGCM #InvisibleSalamanders #randomKeyRobustness #symmetricCryptography
- Generate two keys.
-
Salamander machen es seit Millionen Jahren. Jetzt wissen Forscher welche Gene das steuern und haben sie erstmals in Mäusen aktiviert.
https://denkstrom.org/artikel/limb-regeneration-sp-gene-breakthrough-2026/
#Medizin #Health #Forschung #Research #GoodNews #GuteNachrichten #News #Press #Nachrichten #Fediverse #Mastodon #Deutschland
-
#Regeneration of fins and limbs relies on shared cellular playbook
Immune cells, blood and repair #genes act in concert across three regenerating #vertebrates
Team cut fins off #bichirs and tracked #gene activity at wound after one, three and seven days, which revealed types of cells present and activity. Team compared data to similar new and existing data about #axolotl, salamander that regrows limbs, and #zebrafish, a that can regrow tips of fins
https://www.sciencenews.org/article/regeneration-of-fins-and-limbs-relies-on-a-shared-cellular-playbook
https://archive.ph/l7NI2 -
#PhantastikPrompts 12.05.
Wenn deine Protas Langeweile hätten: Womit würden sie sich die Zeit vertreiben?Spannende Frage! Langeweile zu haben, ist ja was anderes als freie Zeit, die sich nach den eigenen Vorlieben gestalten lässt. Langeweile heißt nach meinem Verständnis, nichts mit sich und seiner Zeit anzufangen zu wissen.
Soreen, der Protagonist aus #Salamander würde kleine Steine in den Staub oder gegen Mauern werfen, vielleicht auch Blätter von Büschen streifen und zerreißen.
-> -
Photo of the Day 6th March 2026.
[…]https://mancavgeek.co.uk/2026/03/06/photo-of-the-day-6th-march-2026/
-
The Roperie: the thread about Leith’s manufacture of the finest ropes and sails for the world
This thread was originally written and published in September 2020.
Today’s auction house artefact is this measuring and conversion gauge for ropes and wires issued by the Edinburgh Roperie & Sailcloth Co., Leith.
Edinburgh Roperie & Sailcloth Company measuring and conversion guageRopemaking was an established craft in North Leith and Newhaven, having been established in the latter village in the early 16th century in conjunction with King James IV’s naval expansion plans. Flodden may have killed the King and his nautical dreams in 1513 but ropemaking was a necessary and useful trade and persisted. Needing room to expand beyond the confines of those settlements, it had made the shift across the river to the Links of South Leith in 1710 when John Gilmour and Thomas Mayo took a site near the present day Salamander Street. This was the beginning of the industrial expansion of Leith beyond its medieval confines, with the glass works also expanding along the foreshore. Ropemaking in Leith and Newhaven was then consolidated under the ownership of a Captain David Deas or Daies before he and partners reconstituted the firm in 1742, changing its name to the Leith Roperie Company in 1750.
Wood’s 1777 Town Plan of Leith, showing the rope works. Reproduced with the permission of the National Library of Scotland and the Signet LibraryWithin months, the adjoining plot to the south was occupied by a competitor, the Edinburgh New Roperie Company. At least three other rope makers joined them and rope-making became the principle industry of South Leith after seafaring in the middle of the 18th century. In 1793 the rope and sail products of Leith were described as “among the best produced in Britain” by George Robertson. The principal customer of these ropeworks was the Leith whaling fleet, and when the Greenland whaling was wound down and abandoned the businesses faltered. The Leith Roperie had borrowed heavily and was wound up due to a lack of capital in 1848 leaving what was by now the Edinburgh Roperie & Sailcloth Company as the principal rope and sail maker in Leith.
Kirkwood’s Town Plan of Edinburgh & Leith, 1817, showing the names of the various ropework ownersThe site of the Leith Roperie would be swallowed up by the railway not long after it closed, and the Edinburgh Roperie came to acquire the sites of its adjacent neighbours in the 19th century.
The Roperie, from a company brochure of 1906, via Edinburgh CollectedUntil the mid-Victorian period, Leith was always critically short of clean water (despite the river running through it), and its public water supply from Lochend was always insufficient. The company therefore established a mill at Malleny in 1805, south of Balerno on the upper reaches of the Water of Leith, where the water was clean and plentiful, to undertake the initial processing and bleaching of fibres. The coming of plentiful water from the Edinburgh & District Water Trust made the Malleny site surplus to requirements and it was disposed of in the latter part of the 19th century.
The advert on the left gives you an idea of the sort of things that the company were making in Leith.
The business survived into the age of steam on account of its reputation for quality products. Indeed such was the esteem with which Leith ropes and canvas were held that the company had to fight off the threat of poor quality imitations and take out newspaper adverts to this effect.
Liverpool General Advertiser, 1838It was possibly for this reason that the Roperie adopted a distinctive trademark. The list of offices around Britain and beyond gives an indication of the company’s success and reach at this time.
Edinburgh Roperie & Sailcloth Co. brochure from 1906 via Edinburgh CollectedAt the time of this publication in 1906, the company advertised itself as having the “sixth longest rope walk in the world“, these rope walks were where the individual cords that made up the rope were gathered and twisted together in a technique that hadn’t evolved much over the centuries.
The Leith rope walk, a mid 20th century photo from British Ropes promotional material, via Edinburgh CollectedA 1958 advertisement used the words of the poet Henry Longfellow to convey “some of the atmosphere of our ancient craft, which has existed since the world was young“:
In that building, long and low,
The Ropewalk, Henry Wadsworth Longfellow, 1858
With its windows all a-row,
Like the port-holes of a hulk,
Human spiders spin and spin,
Backward down their threads so thin
Dropping, each a hempen bulk.The company carried out most of the stages of rope and cloth making for itself, from processing the raw ingredients through to spinning, weaving, binding and packaging of the end product. This included the bleaching, dying and waterproofing of fibres and it had an enormous drying green on the site. The fertiliser works on Salamander Street can be seen in the background.
The drying green. Edinburgh Roperie & Sailcloth Co. brochure from 1906 via Edinburgh CollectedIt was not just maritime ropes and sails that were produced, general waterproofed natural fabrics known as “duck” were made for any sort of purpose;
The spinning mill. Edinburgh Roperie & Sailcloth Co. brochure from 1906 via Edinburgh CollectedAnd ropes for power transmission and winding;
The steam engine of the rope spinning department. Edinburgh Roperie & Sailcloth Co. brochure from 1906 via Edinburgh CollectedThrough to agricultural binder twine. Here the company’s steam lorry is seen heading out of the works with a full load of 5lb balls of twine.
The steam lorry. Edinburgh Roperie & Sailcloth Co. brochure from 1906 via Edinburgh CollectedAt its peak it employed over 1,000 people in Leith, including a lot of women (as spinning and weaving mills often did). It was heavy and dangerous work, with unguarded, rapidly spinning, cable-powered machinery everywhere and the ever-present silent danger of a work atmosphere laden with fibres.
The largely female workforce (apart from the overseer) in the weaving factory. Edinburgh Roperie & Sailcloth Co. brochure from 1906 via Edinburgh Collected“Rope Hackling Machine” with woman worker at the Edinburgh Roperie, from a 1919 book “Cordage and Cordage Hemp”The Roperie became part of the British Ropes conglomerate in 1925, which was formed with the purpose of consolidating the British industry into a larger, more efficient concern following a huge loss of business during and after WW1. It continued to trade under its own name as part of this parent organisation.
On Saturday 25th April 1936, the Leith works suffered a disastrous fire which engulfed most of the site, the Dundee Courier reporting that there was a “quarter mile of flames” and that it was “one of the most disastrous which had occurred in that city for many years“. The fire broke out at the western end of the works and was fanned by the wind, quickly consuming the whole length within a period of just 20 minutes. Around £75,000 of damage (c. £6 million in 2022) was done to the works, but within days the company had 100 of its 500 strong workforce back on site. Its survival after this critical episode was attributed to it being part of the larger conglomerate. The management vowed to rebuild and the Minister of Labour opened the reconstructed works on November 16th 1937; this time the factory was entirely fireproof. It was now “the most up to date ropeworks in Scotland” and “one of the most important factories” in the British Ropes group.
200th Anniversary social evening advert for the Roperie, via Edinburgh CollectedThe company moved into production of synthetic ropes and celebrated its bicentennial in Leith in 1950 with the opening of a plant for the production of nylon sailcloth. However, this was not enough to guarantee the long term survival of the works, which still depended on jute and soft fibre-based production for much of its business. On Friday November 18th 1960, British Ropes announced it was simultaneously closing its Leith works and exiting the soft fibre and jute business altogether. Synthetic rope and cloth production was transferred to company sites in Tyneside and South Wales. Of the 400 workers in Leith, 60% were women and there would be redundancy of between £17,000 and £20,000 paid out in total. The works finally closed 9 months later after a winding down process.
The site was then taken over by the company of Macdonald & Muir, whisky bottlers and blenders known for their Highland Queen bonded warehouse along Commercial Street, blends such as Baillie Nicol Jarvie and their ownership of John Crabbie & Co.’s green ginger wine business in Leith. They are probably best known as the parent company of the Glenmorangie Distillery, which they bought in 1918. Bath Road, by now known as Salamander Place, became the HQ, bottling and distribution plant for the company now known simply as Glenmorangie. They left in stages between 1993 and 1996, headed for Livingston where they are still going as part of the the Moët Hennessy Louis Vuitton empire.
These monogrammed Macdonald & Muir boardroom chairs came up for sale in October 2020.The site lay vacant before being snapped up by property speculators who demolished everything and then went bust in 2008 during the financial crisis. It then took the best part of another 10 years for things to get moving again and the final phase of redevelopment is imminently coming to a conclusion.
The Roperie site in 2008The Roperie site in 2014The Roperie site in 2019You will notice that one of the developers has branded its block The Ropeworks (a name under which it never traded) and the street names include the Ropemaker Street, Sailmaker Road and Chandler Crescent. Fans of the film Trainspotting T2 may recognise Sailmaker Road…
Dalton’s long-established scrapyard on Salamander StreetNote to readers: unfortunately in April 2026, a third-party plug-in more than exceeded its authority and broke many of the image links on this site. No images were lost but I will have to restore them page-by-page, which may take some time. In the meantime please bear with me while I go about rectifying this issue.
If you have found this site useful, informative or amusing then you can help contribute towards its running costs by supporting me on ko-fi. This includes my commitment to keeping it 100% advert and AI free for all time coming, and in helping to find further unusual stories to bring you by acquiring books and paying for research.
Or please do just share this post on social media or amongst friends and like-minded people, sites like this thrive on being shared.Explore Threadinburgh by map:
Travelers' Map is loading...
If you see this after your page is loaded completely, leafletJS files are missing.These threads © 2017-2026, Andy Arthur.
NO AI TRAINING: Any use of the contents of this website to “train” generative artificial intelligence (AI) technologies to generate text is expressly prohibited. The author reserves all rights to license uses of this work for generative AI training and development of machine learning language models.
#Lochend #Logan #Restalrig #StMargaret -
My Salamanders Techmarine of many parts is painted, it was great fun to paint on stream yesterday and marks 1/3 of my foot troops complete for my badab war force. #warhammer40k #techmarine #spacemarines #paintingwarhammer #salamanders40k
-
Remember when we didn't have 30k terminator armour? This is a kitbash from that time so I had to include him in my Badab war remnant army. I'm particularly pleased with my first attempt at freehand flames 😄 #warhammer40k #badabwar #salamanders40k #paintingwarhammer #miniaturepainting
-
Looking south.
I noticed these three eastern bluebirds (Sialia sialis) high up in a pair of sweetgum trees yesterday. I think I saw them there a few months ago as well. I don't know that it was the same three, but it seems about right. It's probably the same three that I saw on a powerline a couple of days ago.
"Insects caught on the ground are a bluebird’s main food for much of the year. Major prey include caterpillars, beetles crickets, grasshoppers, and spiders. In fall and winter, bluebirds eat large amounts of fruit including mistletoe, sumac, blueberries, black cherry, tupelo, currants, wild holly, dogwood berries, hackberries, honeysuckle, bay, pokeweed, and juniper berries. Rarely, Eastern Bluebirds have been recorded eating salamanders, shrews, snakes, lizards, and tree frogs." - allabooutbirds.org
#photo #photography #photographer #photographylovers #birds #birdsofmastodon #birdwatching #EasternBluebirds
-
Why Some #Animals Live for Only Days and Others Live for Thousands of Years
#Scientists are studying why some species live so much longer than others.
Some species of #turtles, #fishes and #salamanders, for instance, don’t show any signs of degeneration or #senescence as they grow older. If they didn’t die of predation, accidents or infectious disease, they could live extremely long lives, Magalhães says.
https://www.scientificamerican.com/article/why-some-animals-live-for-only-days-and-others-live-for-thousands-of-years/ -
Back from a trail run in the Bavarian Alps.
I love being out at dusk and after dark. Your visual world narrows to the beam of the headlamp, the last light, and the stars. But everything else feels sharper: the smell of damp forest, the sound of crickets in the meadows, the sudden warm air on your skin when you reach an alpine pasture, streams running in the dark and tawny owls calling.
And tonight, this alpine salamander suddenly appeared in the light.
#TrailRunning #Mountains #Nature #Wildlife #NaturePhotography #Bavaria #Alps #Spring
-
newest episode of herphighlights is on "skydiving" salamanders ; Brown et al 2022 tests the ability of 3 tree-dwelling Aneides salamanders to guide their falls in an aerodynamic manner.
https://herphighlights.podbean.com/e/223-sky-diving-salamanders/
#herps
#salamander
#gliding
#parachuting
#fallingInStyle
#falling
#aboreal
#redwood -
CW: art containing mild nudity and cartoonish violence
The Damned Disciple
Some moody art of Penelope cause lizard.
#art #furryart #oc #fediart #foxwayart #rosethorns #digitalart #furry #salamander #blackandwhite #red
-
CW: Religion, Christianity, #Intercession
St Patrick, you drove the snakes out, which might have disturbed the ecosystem a bit.
Today, do the reverse: watch out for nature's protectors. The ones maintaining nature reserves with snakes in them, the ones helping migrating frogs, tοads, and salamanders across roads, the ones using animal venoms for hunting or research purposes.
🐍🐸🦎
-
Hysteria 2: протокол, который притворяется HTTP/3 и почти не врёт
Разбор архитектуры, Brutal-алгоритма, Salamander-обфускации и честный ответ — почему это работает в 2026-м и при каких условиях падает. Большинство статей про Hysteria 2 написаны по одному шаблону: «быстро, просто, ставится за 5 минут, вот конфиг». Это не такая статья. Я хочу разобрать что именно происходит на уровне протокола, почему выбранные инженерные решения работают против современных DPI-систем, и где у этого протокола настоящие слабые места — которые вендор в документации деликатно обходит стороной. Если тебе нужен гайд «скопируй конфиг и запусти» — закрывай вкладку. Если интересно почему это работает — читай дальше. Разобраться в протоколе
https://habr.com/ru/articles/1008554/
#hysteria2 #QUIC #DPI #обход_блокировок #proxy #цензура #Brutal #Salamander #VPN #HTTP3
-
A Snorkeling Biologist Snapped the First-Ever Photos of Newly Hatched California Giant Salamanders in the Wild. Here’s Why That's a Big Deal
https://www.smithsonianmag.com/smart-news/a-snorkeling-biologist-snapped-the-first-ever-photos-of-newly-hatched-california-giant-salamanders-in-the-wild-heres-why-thats-a-big-deal-180988619/ #marin -
From June 2024, citizen scientists/naturalists field work day.
This is a juvenile long toed #salamander #LiveSpecimen. They're native to Vancouver Island / PNW regions.
These native salamanders are an #IndicatorSpecies & extremely sensitive to any changes in their #ecological #habitats. We capture some to study their health because they help us to obtain more protection for their habitats - which are at ongoing risks for human caused pollution & degradation.#nature #Wsanec #Saanich #DisabledPhotographers #YYJphotographers #PacificNorthwest #BritishColumbia #Canada #photography #VictoriaBC #NatureLovers #YYJ #PNW #VanIsle #NatureGuardians #WorldInMyEyes #NaturePhotos #wildlife #amphibians #NativeWildlife #NativeSalamanders #NatureDefenders
-
From June 2024, citizen scientists/naturalists field work day.
This is a juvenile long toed #salamander #LiveSpecimen. They're native to Vancouver Island / PNW regions.
These native salamanders are an #IndicatorSpecies & extremely sensitive to any changes in their #ecological #habitats. We capture some to study their health because they help us to obtain more protection for their habitats - which are at ongoing risks for human caused pollution & degradation.#nature #Wsanec #Saanich #DisabledPhotographers #YYJphotographers #PacificNorthwest #BritishColumbia #Canada #photography #VictoriaBC #NatureLovers #YYJ #PNW #VanIsle #NatureGuardians #WorldInMyEyes #NaturePhotos #wildlife #amphibians #NativeWildlife #NativeSalamanders #NatureDefenders
