Simon Willison's Weblog: cryptography

Constant-time support lands in LLVM: Protecting cryptographic code at the compiler level

2025-11-25T18:32:23+00:00

Constant-time support lands in LLVM: Protecting cryptographic code at the compiler level

Substantial LLVM contribution from Trail of Bits. Timing attacks against cryptography algorithms are a gnarly problem: if an attacker can precisely time a cryptographic algorithm they can often derive details of the key based on how long it takes to execute.

Cryptography implementers know this and deliberately use constant-time comparisons to avoid these attacks... but sometimes an optimizing compiler will undermine these measures and reintroduce timing vulnerabilities.

Trail of Bits has developed constant-time coding support for LLVM 21, providing developers with compiler-level guarantees that their cryptographic implementations remain secure against branching-related timing attacks. This work introduces the __builtin_ct_select family of intrinsics and supporting infrastructure that prevents the Clang compiler, and potentially other compilers built with LLVM, from inadvertently breaking carefully crafted constant-time code.

Via Lobste.rs

Tags: c, cryptography, llvm

Claude Code Can Debug Low-level Cryptography

2025-11-01T22:26:43+00:00

Claude Code Can Debug Low-level Cryptography

Go cryptography author Filippo Valsorda reports on some very positive results applying Claude Code to the challenge of implementing novel cryptography algorithms. After Claude was able to resolve a "fairly complex low-level bug" in fresh code he tried it against two other examples and got positive results both time.

Filippo isn't directly using Claude's solutions to the bugs, but is finding it useful for tracking down the cause and saving him a solid amount of debugging work:

Three out of three one-shot debugging hits with no help is extremely impressive. Importantly, there is no need to trust the LLM or review its output when its job is just saving me an hour or two by telling me where the bug is, for me to reason about it and fix it.

Using coding agents in this way may represent a useful entrypoint for LLM-skeptics who wouldn't dream of letting an autocomplete-machine writing code on their behalf.

Via Hacker News

Tags: cryptography, go, security, ai, generative-ai, llms, ai-assisted-programming, filippo-valsorda, coding-agents, claude-code

Encryption At Rest: Whose Threat Model Is It Anyway?

2024-06-04T13:17:34+00:00

Encryption At Rest: Whose Threat Model Is It Anyway?

Security engineer Scott Arciszewski talks through the challenges of building a useful encryption-at-rest system for hosted software. Encryption at rest on a hard drive protects against physical access to the powered-down disk and little else. To implement encryption at rest in a multi-tenant SaaS system - such that even individuals with insider access (like access to the underlying database) are unable to read other user's data, is a whole lot more complicated.

Consider an attacker, Bob, with database access:

Here’s the stupid simple attack that works in far too many cases: Bob copies Alice’s encrypted data, and overwrites his records in the database, then accesses the insurance provider’s web app [using his own account].

The fix for this is to "use the AAD mechanism (part of the standard AEAD interface) to bind a ciphertext to its context." Python's cryptography package covers Authenticated Encryption with Associated Data as part of its "hazardous materials" advanced modules.

Via Hacker News

Tags: cryptography, encryption, python, security

Quoting John Gruber

2023-08-24T06:16:18+00:00

And the notion that security updates, for every user in the world, would need the approval of the U.K. Home Office just to make sure the patches weren’t closing vulnerabilities that the government itself is exploiting — it boggles the mind. Even if the U.K. were the only country in the world to pass such a law, it would be madness, but what happens when other countries follow?

— John Gruber

Tags: cryptography, john-gruber, law, uk, uklaw

Over-engineering Secret Santa with Python cryptography and Datasette

2022-12-11T02:03:39+00:00

We're doing a family Secret Santa this year, and we needed a way to randomly assign people to each other without anyone knowing who was assigned to who.

I offered to write some software! (Maybe "insisted" is more accurate)

I've been wanting an excuse to write something fun involving Python's cryptography library for years. The problem is that I'm too responsible/cowardly to ignore the many warnings to only use the "hazardous materials" area of that library if you know exactly what you're doing.

A secret santa is the perfect low stakes project to ignore those warnings and play with something fun.

My requirements

I have six participants. Each participant needs to know who they are to buy a gift for - with no way of finding out any of the other gift pairings.

As the administrator of the system I must not be able to figure out the pairings either.

I don't want to use email or logins or anything like that - I just want to be able to share a link in the family WhatsApp group and have everyone use the same interface to get their pairing.

How it works

Here's the scheme I came up with:

Each participant gets a password generated for them. This happens on demand when they click a button - with an honour system not to click someone else's button (easily detected since each button can only be clicked once). If someone DOES click someone else's button we can reset the entire system and start again.
Their password is generated for them - it's three random words, for example "squirrel copper sailboat". I expect most people to take a screenshot with their phone to record it.
Behind the scenes, each user has a RSA public/private key generated for them. The private key is encrypted using their new password, then both keys are stored in the database. The password itself is NOT stored.
Once every user has generated and recorded their password, we can execute the Secret Santa assignments. This shuffles the participants and then assigns each person to the person after them in the list. It then uses their public keys to encrypt a message telling them who they should buy a gift for.
Those encrypted messages are stored in the database too.
Finally, each user can return to the site and enter their password to decrypt and view their message.

And here's an animated GIF demo:

Building it as a Datasette plugin

This is a tiny app with a very small amount of persistence needed, so I decided to build it as a Datasette plugin on top of a couple of SQLite database tables.

In addition to giving me an excuse to try something new with my main project, this should also hopefully make it easy to deploy.

Most of the code is in the datasette_secret_santa/__init__.py file. I used a number of different plugin hooks:

startup() to create the database tables it needs when the server first starts (if they do not exist already)
canned_queries() to add a canned SQL query for creating new Secret Santa groups, to save me from needing to build a custom UI for that
register_routes() to register five new custom pages within Datasette
extra_template_vars() to make an extra context variable available on the Datasette homepage, which is rendered using a custom template

Here are the routes:

@hookimpl
def register_routes():
    return [
        (r"^/secret-santa/(?P<slug>[^/]+)$", secret_santa),
        (r"^/secret-santa/(?P<slug>[^/]+)/add$", add_participant),
        (r"^/secret-santa/(?P<slug>[^/]+)/assign$", assign_participants),
        (r"^/secret-santa/(?P<slug>[^/]+)/set-password/(?P<id>\d+)$", set_password),
        (r"^/secret-santa/(?P<slug>[^/]+)/reveal/(?P<id>\d+)$", reveal),
    ]

/secret-santa/{slug} is the main page for a Secret Santa group. It shows a list of participants and a form to add a new participant.
/secret-santa/{slug}/add is the endpoint for a form that adds a new participant.
/secret-santa/{slug}/set-password/{id} is the page that lets a user generate and retrieve their password.
/secret-santa/{slug}/reveal/{id} is the page where a user enters their password to reveal their Secret Santa assignment.
/secret-santa/{slug}/assign is the endpoint that does the work of assigning participants to each other, and generating and saving encrypted message for each of them.

The cryptography

The earlier warning holds firm here: I am not a cryptographer. I'm just having fun. You should not imitate any of the code I wrote here without thoroughly reviewing it with someone who knows what they're doing.

(I also used ChatGPT to write my first drafts of it, as described in this issue. Trusting cryptographic code generated by a large language model is a particularly bad idea!)

Disclaimers out of the way, here's the code I wrote to generate and store the RSA keys:

async def generate_password_and_keys_for_user(db, participant_id):
    password = " ".join(random.sample(words, 3))

    private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
    public_key = private_key.public_key()

    # Serialize the keys for storage
    private_key_serialized = private_key.private_bytes(
        encoding=serialization.Encoding.PEM,
        format=serialization.PrivateFormat.PKCS8,
        encryption_algorithm=serialization.BestAvailableEncryption(
            password.encode("utf-8")
        ),
    ).decode("utf-8")
    public_key_serialized = public_key.public_bytes(
        encoding=serialization.Encoding.PEM,
        format=serialization.PublicFormat.SubjectPublicKeyInfo,
    ).decode("utf-8")

    await db.execute_write(
        """
        update secret_santa_participants
        set
            password_issued_at = datetime('now'),
            public_key = :public_key,
            private_key = :private_key
        where id = :id
        """,
        {
            "id": participant_id,
            "public_key": public_key_serialized,
            "private_key": private_key_serialized,
        },
    )
    return password

As you can see, it uses rsa.generate_private_key() from the PyCA cryptography library to generate the public and private keys.

The options public_exponent=65537, key_size=2048 are recommended by the generate_private_key() documentation.

It then serializes them to PEM format strings that can be stored in the database.

The private key is serialized after being encrypted using the randomly generated password for that user. This produces a string that looks like this:

-----BEGIN ENCRYPTED PRIVATE KEY-----
...
-----END ENCRYPTED PRIVATE KEY-----

I had originally come up with my own scheme for this, involving AES encryption and a key derived from a hash of the raw password (which I planned to later run through bcrypt a few hundred thousand times) - I was very happy when I realized that there was a standard way to do this already.

The code that then assigns the participants and generates their encrypted messages looks like this:

# Assign participants
random.shuffle(participants)
for i, participant in enumerate(participants):
    assigned = participants[(i + 1) % len(participants)]
    message = "You should buy a gift for {}".format(assigned["name"])
    # Encrypt the message with their public key
    public_key = serialization.load_pem_public_key(
        participant["public_key"].encode("utf-8"), backend=default_backend()
    )
    secret_message_encrypted = public_key.encrypt(
        message.encode("utf-8"),
        padding.OAEP(
            mgf=padding.MGF1(algorithm=hashes.SHA256()),
            algorithm=hashes.SHA256(),
            label=None,
        ),
    )
    await db.execute_write(
        """
        update secret_santa_participants
        set secret_message_encrypted = :secret_message_encrypted
        where id = :id
        """,
        {
            "id": participant["id"],
            "secret_message_encrypted": secret_message_encrypted,
        },
    )

And finally, the code that decrypts the message when the user provides their password again:

data = await request.post_vars()
password = data.get("password", "").strip()
if not password:
    return await _error(
        datasette, request, "Please provide a password", status=400
    )
# Decrypt the private key with the password
try:
    private_key = decrypt_private_key_for_user(participant, password)
except ValueError:
    return await _error(datasette, request, "Incorrect password", status=400)
# Decrypt the secret message with the private key
decrypted_message = private_key.decrypt(
    participant["secret_message_encrypted"],
    padding.OAEP(
        mgf=padding.MGF1(algorithm=hashes.SHA256()),
        algorithm=hashes.SHA256(),
        label=None,
    ),
).decode("utf-8")

And some snowflakes

I spent all of five minutes on the visual design for it - the main feature of which is a thick red top border on body followed by a thinner white border to make it look like its wearing a Santa hat.

I did add some animated snowflakes though! I used this script Natalie Downe built back in 2010. It works great!

Deploying it on Glitch

This kind of project is a really great fit for Glitch, which offers free hosting with persistent file storage - perfect for SQLite - provided you don't mind your projects going to sleep in between bouts of activity (unless you pay to "boost" them). A Secret Santa app is a perfect fit for this sort of hosting.

(You can remix my project to get your own copy of the app (with your own database) by clicking the "Remix" button.)

Since I had shipped the plugin up to PyPI already, deploying it on Glitch was a matter of creating a new project there containing this single glitch.json file:

{
  "install": "pip3 install --user datasette datasette-secret-santa -U",
  "start": "datasette --create .data/santa.db -p 3000"
}

This causes Glitch to install both datasette and datasette-secret-santa when the project first launches. It then starts the Datasette server running like this:

datasette --create .data/santa.db -p 3000

The --create flag tells Datasette to create a new SQLite database if one doesn't already exist at that path. .data/ is a special directory on Glitch that won't have its contents automatically tracked using their version control.

The -p 3000 flag tells the server to listen on port 3000, which is the Glitch default - traffic to the subdomain for the app will automatically be routed to that port.

And the database is public

Here's a slightly surprising thing about this: the SQLite table containing all of the data - including the public keys and encrypted private keys - is visible for anyone with access to the instance to see!

Here's that table for a demo I deployed on Glitch.

Once again, I am by no means a cryptography expert, and this isn't something I would tolerate for any other application. But with the risk profile involved in a secret santa I think this is OK. I'm pretty sure you could brute force decrypt the private keys if you really wanted to, so it's a good thing they're not being used for anything else!

(This is also one of the reasons I didn't let users pick their own passwords - by assigning generated passwords I can be 100% sure I don't accidentally end up holding onto an encrypted copy of a credential that could be used for anything else.)

Self-contained apps as plugins

Something I find interesting about this project is that it demonstrates how a Datasette plugin can be used to provide a full, self-contained app.

I think this is a powerful pattern. It's a neat way to take advantage of the tools I've built to help make Datasette easy to deploy - not just on Glitch but on platforms like Fly as well.

This is my first time using Datasette in this way and I found it to be a pleasantly productive way of building and deploying this kind of personal tool. I'm looking forward to trying this approach out for other projects in the future.

And if you know cryptography and can spot any glaring (or subtle) holes in the way my system works, please open an issue and let me know!

Tags: cryptography, glitch, projects, datasette, chatgpt, llms, ai-assisted-programming

Ok Google: please publish your DKIM secret keys

2020-11-16T22:02:58+00:00

Ok Google: please publish your DKIM secret keys

The DKIM standard allows email providers such as Gmail to include cryptographic headers that protect against spoofing, proving that an email was sent by a specific host and has not been tampered with. But it has an unintended side effect: if someone’s email is leaked (as happened to John Podesta in 2016) DKIM headers can be used to prove the validity of the leaked emails. This makes DKIM an enabling factor for blackmail and other security breach related crimes.

Matthew Green proposes a neat solution: providers like Gmail should rotate their DKIM keys frequently and publish the PRIVATE key after rotation. By enabling spoofing of past email headers they would provide deniability for victims of leaks, fixing this unintended consequence of the DKIM standard.

Via @matthew_d_green

Tags: cryptography, email, security

Looking back at the Snowden revelations

2019-09-25T05:48:39+00:00

Looking back at the Snowden revelations

Six years on from the Snowden revelations, crypto researcher Matthew Green reviews their impact and reminds us what we learned. Really interesting.

Via @matthew_d_green

Tags: cryptography, security

Verified cryptography for Firefox 57

2017-11-16T14:26:41+00:00

Verified cryptography for Firefox 57

Mozilla just became the first browser vendor to ship a formally verified crypto implementation.

Via Tim Taubert

Tags: cryptography, firefox, mozilla

doc/beatings.txt

2010-05-24T14:17:00+00:00

doc/beatings.txt

Rubberhose is a disk encryption system developed by the founder of Wikileaks that implements deniable cryptography—different keys reveal different parts of the encrypted data, and it is impossible to prove that all of the keys have been divulged. Here, Julian Assange explains how this works with a scenario involving Alice and the Rubber-hose-squad.

Via Rubberhose cryptographically deniable transparent disk encryption system

Tags: cryptography, wikileaks, recovered, coercion, julian-assange, rubberhose

Don't Hash Secrets

2010-01-24T13:30:58+00:00

Don't Hash Secrets

A well written explanation from 2008 of why you must use hmac instead of raw SHA-1 when hashing against a secret.

Tags: cryptography, hmac, security, sha1, signing

Timing attack in Google Keyczar library

2010-01-04T15:23:32+00:00

Timing attack in Google Keyczar library

An issue I also need to fix in the proposed Django signing code. If you’re comparing two strings in crypto (e.g. seeing if the provided signature matches the expected signature) you need to use a timing independent string comparison function or you risk leaking information. This kind of thing is exactly why I want an audited signing module in Django rather than leaving developers to figure it out on their own.

Tags: cryptography, django, keyczar, python, security, signing, timing-attack

Design and code review requested for Django string signing / signed cookies

2010-01-04T13:24:50+00:00

Design and code review requested for Django string signing / signed cookies

Do you know your way around web app security and cryptography (in particular signing things using hmac and sha1)? We’d appreciate your help reviewing the usage of these concepts in Django’s proposed string signing and signed cookie implementations.

Tags: code-review, cryptography, django, hashing, hmac, python, security, sha1

Intercepting Predator Video

2009-12-24T21:26:26+00:00

Intercepting Predator Video

Bruce Schneier’s take on the unencrypted Predator UAV story. A fascinating discussion of key management and the non-technical side of cryptography.

Tags: bruce-schneier, cryptography, drones, military, nsa, security

Notes from the No Lone Zone

2009-12-16T10:02:38+00:00

Notes from the No Lone Zone

A computer scientist with a background in cryptography visits a Titan II ICBM launch complex.

Tags: coldwar, cryptography, history, icbm, security

openstreetmap genuine advantage

2009-09-29T09:49:52+00:00

openstreetmap genuine advantage

The OpenStreetMap data model (points, ways and relations, all allowing arbitrary key/value tags) is a real thing of beauty—simple to understand but almost infinitely extensible. Mike Migurski’s latest project adds PGP signing to OpenStreetMap, allowing organisations (such as local government) to add a signature to a way (a sequence of points) and a subset of its tags, then write that signature in to a new tag on the object.

Tags: cryptography, geospatial, mapping, michal-migurski, openstreetmap, pgp

Django ponies: Proposals for Django 1.2

2009-09-28T23:32:04+00:00

I've decided to step up my involvement in Django development in the run-up to Django 1.2, so I'm currently going through several years worth of accumulated pony requests figuring out which ones are worth advocating for. I'm also ensuring I have the code to back them up - my innocent AutoEscaping proposal a few years ago resulted in an enormous amount of work by Malcolm and I don't think he'd appreciate a repeat performance.

I'm not a big fan of branches when it comes to exploratory development - they're fine for doing the final implementation once an approach has been agreed, but I don't think they are a very effective way of discussing proposals. I'd much rather see working code in a separate application - that way I can try it out with an existing project without needing to switch to a new Django branch. Keeping code out of a branch also means people can start using it for real development work, making the API much easier to evaluate. Most of my proposals here have accompanying applications on GitHub.

I've recently got in to the habit of including an "examples" directory with each of my experimental applications. This is a full Django project (with settings.py, urls.py and manage.py files) which serves two purposes. Firstly, it allows developers to run the application's unit tests without needing to install it in to their own pre-configured project, simply by changing in to the examples directory and running ./manage.py test. Secondly, it gives me somewhere to put demonstration code that can be viewed in a browser using the runserver command - a further way of making the code easier to evaluate. django-safeform is a good example of this pattern.

Here's my current list of ponies, in rough order of priority.

Signing and signed cookies

Signing strings to ensure they have not yet been tampered with is a crucial technique in web application security. As with all cryptography, it's also surprisingly difficult to do correctly. A vulnerability in the signing implementation used to protect the Flickr API was revealed just today.

One of the many uses of signed strings is to implement signed cookies. Signed cookies are fantastically powerful - they allow you to send cookies safe in the knowledge that your user will not be able to alter them without you knowing. This dramatically reduces the need for sessions - most web apps use sessions for security rather than for storing large amounts of data, so moving that "logged in user ID" value to a signed cookie eliminates the need for session storage entirely, saving a round-trip to persistent storage on every request.

This has particularly useful implications for scaling - you can push your shared secret out to all of your front end web servers and scale horizontally, with no need for shared session storage just to handle simple authentication and "You are logged in as X" messages.

The latest version of my django-openid library uses signed cookies to store the OpenID you log in with, removing the need to configure Django's session storage. I've extracted that code in to django-signed, which I hope to evolve in to something suitable for inclusion in django.utils.

Please note that django-signed has not yet been vetted by cryptography specialists, something I plan to fix before proposing it for final inclusion in core.

django-signed on GitHub
Details of the Signing proposal on the Django wiki
Signing discussion on the django-developers mailing list

Improved CSRF support

This is mainly Luke Plant's pony, but I'm very keen to see it happen. Django has shipped with CSRF protection for more than three years now, but the approach (using middleware to rewrite form HTML) is relatively crude and, crucially, the protection isn't turned on by default. Hint: if you aren't 100% positive you are protected against CSRF, you should probably go and turn it on.

Luke's approach is an iterative improvement - a template tag (with a dependency on RequestContext) is used to output the hidden CSRF field, with middleware used to set the cookie and perform the extra validation. I experimented at length with an alternative solution based around extending Django's form framework to treat CSRF as just another aspect of validation - you can see the result in my django-safeform project. My approach avoids middleware and template tags in favour of a view decorator to set the cookie and a class decorator to add a CSRF check to the form itself.

While my approach works, the effort involved in upgrading existing code to it is substantial, compared to a much easier upgrade path for Luke's middleware + template tag approach. The biggest advantage of safeform is that it allows CSRF failure messages to be shown inline on the form, without losing the user's submission - the middleware check means showing errors as a full page without redisplaying the form. It looks like it should be possible to bring that aspect of safeform back to the middleware approach, and I plan to put together a patch for that over the next few days.

Luke's CSRF branch on bitbucket
My django-safeform on GitHub
Details of the CSRF proposal on the Django wiki
CSRF discussion on the django-developers mailing list

Better support for outputting HTML

This is a major pet peeve of mine. Django's form framework is excellent - one of the best features of the framework. There's just one thing that bugs me about it - it outputs full form widgets (for input, select and the like) so that it can include the previous value when redisplaying a form during validation, but it does so using XHTML syntax.

I have a strong preference for an HTML 4.01 strict doctype, and all those <self-closing-tags /> have been niggling away at me for literally years. Django bills itself as a framework for "perfectionists with deadlines", so I feel justified in getting wound up out of proportion over this one.

A year ago I started experimenting with a solution, and came up with django-html. It introduces two new Django template tags - {% doctype %} and {% field %}. The doctype tag serves two purposes - it outputs a particular doctype (saving you from having to remember the syntax) and it records that doctype in Django's template context object. The field tag is then used to output form fields, but crucially it gets to take the current doctype in to account.

The field tag can also be used to add extra HTML attributes to form widgets from within the template itself, solving another small frustration about the existing form library. The README describes the new tags in detail.

The way the tags work is currently a bit of a hack - if merged in to Django core they could be more cleanly implemented by refactoring the form library slightly. This refactoring is currently being discussed on the mailing list.

django-html on GitHub
Improved HTML discussion on the django-developers mailing list

Logging

This is the only proposal for which I don't yet have any code. I want to add official support for Python's standard logging framework to Django. It's possible to use this at the moment (I've done so on several projects) but it's not at all clear what the best way of doing so is, and Django doesn't use it internally at all. I posted a full argument in favour of logging to the mailing list, but my favourite argument is this one:

Built-in support for logging reflects a growing reality of modern Web development: more and more sites have interfaces with external web service APIs, meaning there are plenty of things that could go wrong that are outside the control of the developer. Failing gracefully and logging what happened is the best way to deal with 3rd party problems - much better than throwing a 500 and leaving no record of what went wrong.

I'm not actively pursuing this one yet, but I'm very interesting in hearing people's opinions on the best way to configure and use the Python logging module in production.

A replacement for get_absolute_url()

Django has a loose convention of encouraging people to add a get_absolute_url method to their models that returns that object's URL. It's a controversial feature - for one thing, it's a bit of a layering violation since URL logic is meant to live in the urls.py file. It's incredibly convenient though, and since it's good web citizenship for everything to have one and only one URL I think there's a pretty good argument for keeping it.

The problem is, the name sucks. I first took a look at this in the last few weeks before the release of Django 1.0 - what started as a quick proposal to come up with a better name before we were stuck with it quickly descended in to a quagmire as I realised quite how broken get_absolute_url() is. The short version: in some cases it means "get a relative URL starting with /", in other cases it means "get a full URL starting with http://" and the name doesn't accurately describe either.

A full write-up of my investigation is available on the Wiki. My proposed solution was to replace it with two complementary methods - get_url() and get_url_path() - with the user implementing one hence allowing the other one to be automatically derived. My django-urls project illustrates the concept via a model mixin class. A year on I still think it's quite a neat idea, though as far as I can tell no one has ever actually used it.

ReplacingGetAbsoluteUrl on the wiki
django-urls on GitHub
Recent get_absolute_url discussion on the django-developers mailing list

Comments on this post are open, but if you have anything to say about any of the individual proposals it would be much more useful if you posted it to the relevant mailing list thread.

Tags: cookies, cryptography, csrf, django, html, logging, luke-plant, markup, ponies, projects, python, security, signedcookies, signing, xhtml

Adding signing (and signed cookies) to Django core

2009-09-24T19:31:20+00:00

Adding signing (and signed cookies) to Django core

I’ve been increasing my participation in Django recently—here’s my proposal for adding signing and signed cookies to Django, which I’d personally like to see ship as part of Django 1.2.

Tags: cookies, cryptography, django, security, signedcookies, signing

NaCl: Networking and Cryptography library

2009-07-16T20:24:50+00:00

NaCl: Networking and Cryptography library

A new high level cryptography library. “NaCl advances the state of the art by improving security, by improving usability and by improving speed.” Ambitious claims, but DJB is one of the core maintainers.

Tags: cryptography, djb, nacl, security

Cryptographic Right Answers

2009-06-11T22:16:25+00:00

Cryptographic Right Answers

Best practise recommendations for cryptography: “While some people argue that you should never use cryptographic primitives directly and that trying to teach people cryptography just makes them more likely to shoot themselves in their proverbial feet, I come from a proud academic background and am sufficiently optimistic about humankind that I think it’s a good idea to spread some knowledge around.”

Tags: aes, colinpercival, cryptography, hashing, security

Django snippets: Sign a string using SHA1, then shrink it using url-safe base65

2008-08-27T22:18:49+00:00

Django snippets: Sign a string using SHA1, then shrink it using url-safe base65

I needed a way to create tamper-proof URLs and cookies by signing them, but didn’t want the overhead of a full 40 character SHA1 hash. After some experimentation, it turns out you can knock a 40 char hash down to 27 characters by encoding it using a custom base65 encoding which only uses URL-safe characters.

Tags: base65, cookies, cryptography, django, django-snippets, hashes, python, security, sha1, signedcookies, urls

Quoting Bruce Schneier

2007-11-16T10:25:42+00:00

I don't understand why the NSA was so insistent about including Dual_EC_DRBG in the standard. It makes no sense as a trap door: It's public, and rather obvious. It makes no sense from an engineering perspective: It's too slow for anyone to willingly use it. And it makes no sense from a backwards-compatibility perspective: Swapping one random-number generator for another is easy.

— Bruce Schneier

Tags: bruce-schneier, cryptography, dualecdrbg, nsa, randomnumbers, security

The Beauty Of The Diffie-Hellman Protocol

2007-03-01T22:08:46+00:00

The Beauty Of The Diffie-Hellman Protocol

Some useful explanations here. Diffie-Hellman is used by OpenID to establish a shared secret between the provider and the consumer.

Tags: cryptography, diffiehellman, openid, reddit

James Randi owes me a million dollars

2007-01-30T01:10:50+00:00

James Randi owes me a million dollars

Interesting case study in cryptographic bit commitment protocols, which allow something to be published that can later prove the authenticity of a revealed secret.

Via reddit

Tags: cryptography

Easy Python Cryptography

2003-04-14T11:04:05+00:00

Via Garth Kidd's Python cryptography roundup, ezPyCrypto is a cryptography API so simple even I can use it. Unfortunately the example code is only available in the download archive (not on the web site) but here's an overview of how it works:

import ezPyCrypto
# Generate a 512 bit key
key = ezPyCrypto.key(512)

text = 'This will be encrypted'

# Encrypt the string
encrypted = key.encString(text)
print encrypted

# Unencrypt the string
decrypted = key.decString(encrypted)
print decrypted

# Export the public key
public = key.exportKey()
# This can now be saved or distributed

# Export the private key
private = key.exportKeyPrivate()
# This can now be saved somewhere safe

# Encrypting using an already generated public key:
key = ezPyCrypto.key()
key.importKey(public)
encrypted = key.encString(text)

# Decrypting using an already generated private key:
key = ezPyCrypto.key()
key.importKey(private)
decrypted = key.decString(text)

That's pretty much it. The class also has support for passphrases which can be used to add an extra layer of protection to a private key, as well as methods to handle crypotgraphic signing and verification.

ezPyCrypto is an easy to use wrapper for the excellent PyCrypto module, and includes PyCrypto (and a handy Windows installer) in the distribution.

Tags: cryptography, python