At our crypto service discovery site discovery.cryptosense.com you don’t have to enter the qualified domain name of a server to test (like
www.mydomain.com) – you can just enter a partial name like
mydomain.com and the tool will query DNS records to look for machines.
Previously, we used to do this by looking for common machines like
vpn.mydomain.com. Recently, we added a feature to query the certificate transparency log to look for certificates registered to this domain. This results in much better coverage of machines. The example screenshot below shows part of the results when querying for
As of today we support user accounts on our crypto protocol scanning and analysis site discovery.cryptosense.com.
It’s free to sign up, and once you sign in, you can:
- manage a list of servers for which you want regular scans;
- see a summary of the latest results;
- get remediation help in the browser;
- get on-demand rescans;
- select whether you want regular email reports.
Features in the pipeline include results in JSON format for integration with other tools. What else would you like to see?
I was excited to read Matt Might’s recent post “An introduction to QuickCheck by example”. QuickCheck is a library that lets you define random generators for arbitrary data-types, and then use these generators to produce test cases for functions.
Matt’s post is a perfect occasion to describe the testing methodology we use a Cryptosense, and how it’s different from QuickCheck. I am going to present the ideas behind it at the next ICFP ML Workshop, so think of this as a sneak preview.
The 13th Smart Card Research and Advanced Application Conference (CARDIS) will be held in Paris November 5-7 this year, and Cryptosense is proud to be among the sponsors.
We’ll have a booth at the conference with some live demos of our cryptographic security audit tools. We promise to enliven your coffee break.
This post follows on from the previous one describing the range of RSA mechanisms supported in PKCS#11, and their security properties (or lack of). One big change to the standard in the upcoming version 2.40 is a separation of the mechanisms in to “Historic” and “Current” mechanisms.
The standard doesn’t say anything specific about the security of the mechanisms in each, but one might conclude that the Historic category will include all the broken mechanisms and the Current list those still believed to be secure.
This is not the case.
Continue reading →
The 7th workshop on Analysis of Security APIs will be held in Vienna University of Technology, Austria on 18th July 2014 as part of the Vienna Summer of Logic. The programme includes talks on low-cost HSMs made from smartcard chips, secure device enrollment, smart API fuzzing and a banking security wishlist.
We’d be delighted to see you there, register here via the VSL registration page – select “FloC and Associated Workshops Week 2“.