Re: [cryptography] Interactive graph of the CA ecosystem
On Fri, Dec 14, 2012 at 11:10 AM, Bernhard Amann wrote: > Hi, > > On Dec 14, 2012, at 4:25 AM, Ralph Holz wrote: > >>> Root-CAs are pictured as red nodes, intermediate CAs are green. >>> The node diameter scales logarithmically with the number of >>> certificates signed by the node. Similarly, the color of the green >>> nodes scales proportional to the diameter. >> >> Hm, I do have a question. Thawte EV has an "outbound" link to "Thawte >> Root", similarly TUM has an "outbound" link to DFN. I would understand >> "outbound" as indicating the direction of the signature, i.e. DFN -> >> TUM. So I would have expected the link between TUM and DFN to be >> "inbound" when I click on TUM. But it seems to be consistenly applied, >> so I guess that was a conscious choice? > > Well, we chose to represent the relationships between the certificates > the other way round - the child certificates point to their parent CA. > However, > this is a purely semantical issue - for your point of view we just would > have to reverse all links. > To that end, have y'all thought of other views that would be interesting to have? Also, can you put more meta data along with the provider? Such as address, parent company, how long they've been a CA, (if it's known) how many certs they've signed? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Here's What Law Enforcement Can Recover From A Seized iPhone
On Mar 27, 2013 11:38 PM, "Jeffrey Goldberg" wrote: > > > http://blog.agilebits.com/2012/03/30/the-abcs-of-xry-not-so-simple-passcodes/ > Days? Not sure about the algorithm but both ocl and jtr can be run in parallel and idk why you'd try to crack a password on an arm device anyway (there's a jtr page that compares platforms and arm is god awful slow). ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Integrety checking GnuPG
This is sort of a trusting trust question. However, is there a way to have gpg verify it has not been altered? Maybe by compiling it with an internal key file and it asking for a password before decrypting itself and then presenting some type of verification. I'm asking whether something like this exists or is possible? Ie, how does malware do integrety checking / try to thwart people from running it if something is amiss? Can this type of thing be put into gpg? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Integrety checking GnuPG
I guess I should've said what my use case is: I want a boot system that unlocks a partition where everything is checked to prevent an evil maid attack. I can sign / check everything but the key and the integrity checker. However, someone could replace gpg with a version that logs to something. I could use some system like tripwire to check the files but this just moves the vulnerable component to something else. Maybe it's possible to use a signed kernel module that does the integrety checking of the files via a hash that could be compiled into the kernel? Again, this is for a boot system. So I'm in initramfs at this point (shouldn't matter but just thought I'd mention it). On Wed, May 29, 2013 at 1:58 AM, Erick Staal wrote: > Herewith my 2c: > > - run static code analyzer against GPG source code (e.g. llvm's scan-build). > Verify GPG source code against keys provided after downloading. (Of course > is manual inspection also a possibility, but at least for our team > scan-build catches more errors than the humans involved). > - Question: do you trust your toolchain?. > - Compile from inspected source on a different (never Internet connected and > cleanly installed) system. > - generate checksums on binary and other related files. > - generate GPG keys. > - burn GPG binary and GPG keys to CD. > - mount CD (read-only) on system-at-risk using a cd-player without writing > capability. > - run GPG from CD. > > Caveat: doesn't protect against e.g. live in-memory attacks on running GPG > and/or on data presented to user on screen, but minimizes the risk for a lot > of other possible mischief. > Criticisms concerning cookbooklet above more than welcome. > > Sincerely, Erick > > > > > > > On 05/29/2013 07:20 AM, shawn wilson wrote: >> >> This is sort of a trusting trust question. However, is there a way to >> have gpg verify it has not been altered? Maybe by compiling it with an >> internal key file and it asking for a password before decrypting >> itself and then presenting some type of verification. I'm asking >> whether something like this exists or is possible? Ie, how does >> malware do integrety checking / try to thwart people from running it >> if something is amiss? Can this type of thing be put into gpg? >> ___ >> cryptography mailing list >> cryptography@randombit.net >> http://lists.randombit.net/mailman/listinfo/cryptography >> > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Integrety checking GnuPG
Thanks for all of the input. In the end I think I'm going to go with the simplest solution (along the way, I found ima-linux and signelf). Let me know if what issues there are with this: Encrypt the LUKS passkey in a text file. Encrypt a user defined message and file checksums in another file with a different password. Decrypt this file first and display the message (letting the user know that if it doesn't look right, they should stop). Get the hashes of all of the files and compare them with the data in the text file and report if anything didn't match. If all is good, prompt for the password of the second file. If there are no issues, I find this simplest and most elegant. On Wed, May 29, 2013 at 12:52 PM, Thierry Moreau wrote: > shawn wilson wrote: >> >> I guess I should've said what my use case is: >> I want a boot system that unlocks a partition where everything is >> checked [...] >> >> However, someone could replace >> gpg with a version that logs to something. > > > OK, simply provide a Faraday cage to the user and instruct them to boot the > device inside of it, hence ensuring a boot process without any RF connection > to the exterior. > > I'm only half joking: if you don't trust the hardware for having a > trustworthy boot in some read-only section in the device, then you stated an > impossible problem. > > Also, you may be paranoid about a user device being replaced altogether > without the victim noticing the replacement. Do you check that the serial > number of your favorite gadget remains stable over time? > > So in practice you must bear some residual risks when you tailor the boot > process towards your goal. In the tailoring project, you might find that GPG > is an overkill when only hash/signature validation is required. > > >>>> This is sort of a trusting trust question. > > > So you knew the answer already. > > > -- > - Thierry Moreau > > CONNOTECH Experts-conseils inc. > 9130 Place de Montgolfier > Montreal, QC, Canada H2M 2A1 > > Tel. +1-514-385-5691 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Integrety checking GnuPG
I was not asked to keep this off list but removing attribution just in case. > > On Thu, May 30, 2013 at 8:49 PM, shawn wilson wrote: > > Thanks for all of the input. In the end I think I'm going to go with > > the simplest solution (along the way, I found ima-linux and signelf). > > > > Let me know if what issues there are with this: > > Encrypt the LUKS passkey in a text file. > > Encrypt a user defined message and file checksums in another file with > > a different password. Decrypt this file first and display the message > > (letting the user know that if it doesn't look right, they should > > stop). Get the hashes of all of the files and compare them with the > > data in the text file and report if anything didn't match. If all is > > good, prompt for the password of the second file. > If the evil maid installs herself in the BIOS or a periphery's ROM, > then there's not a lot you can do. The user's password will always be > exposed. You could even boot to a thumb drive, perform the integrity > check, and things would still look fine from the outside. > If the hardware is altered in an undetectable manner, you're right. But is the boot image is altered (ROM or otherwise) the checksum process would fail. I could even have a simple pass/fail test case to show the user that diff or comm were not altered. Also, I think there is kernel support for reading most BIOS models. So maybe next, I should look into that. Though, I think at the point of altering hardware is where I need to call it quits - someone could modify any PCI card and as long as it was loaded at that point, there will be at least some leakage and I can't verify everything. Either way, I'll see how far I can get with dumping hardware data and hashing it as well. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] OpenPGP adoption post-PRISM
On Tue, Jul 30, 2013 at 1:51 AM, Andreas Bürki wrote: > > > Am 30.07.2013 01:25, schrieb Tony Arcieri: >> Here's the source of the data, if you're curious: >> >> https://sks-keyservers.net/ > > To me as a boring consumer it looks curious, right: > > https://www.ssllabs.com/ssltest/analyze.html?d=sks-keyservers.net&hideResults=on > What exactly are you pointing out here? If this were a timely graph (ie, one made to indicate the trend before/after the NSA leaks) it might've been limited to the beginning of the year and >3.2M and have put markers for certain events (I'd like to see this graph anyway if anyone wants to make it). The chart looks pretty honest to me (I have nothing to dispute the numbers or the source nore any feeling that the trend is wrong). ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Crack Me If You Can!
Figured some here might be interrested in this... Our password cracking contest started about 4 hours ago. Register online and play along at home! Or just watch the pretty stats as the participants duke it out. http://contest-2013.korelogic.com/ And I really need to go to bed. -- You received this message because you are subscribed to the Google Groups "NoVAHackers" group. To unsubscribe from this group and stop receiving emails from it, send an email to novahackers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] urandom vs random
I thought that decent crypto programs (openssh, openssl, tls suites) should read from random so they stay secure and don't start generating /insecure/ data when entropy runs low. The only way I could see this as being a smart thing to do is if these programs also looked at how much entropy the kernel had and stopped when it got ~50 or so. Is this the way things are done when these programs use urandom or what? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 10:03 AM, Swair Mehta wrote: > As far as I know, there is no measure like 50 or so for /dev/random. > /proc/sys/kernel/random/entropy_avail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 10:01 PM, James A. Donald wrote: > At startup, likely to be short of entropy. > > If /dev/urandom seeded at startup, and then seeded no further, bad, but not > very bad. > > If /dev/urandom seeded at startup from /dev/random, then should block at > startup. > > If /dev/urandom never blocks, bad. Should block at startup waiting to > receive 160 bits from /dev/random, and never block again. > I don't follow this - I understand why lack of entropy should block urandom but, why shouldn't it block on a running system that http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
They're also not super good. They barely keep up with my ssh traffic and it took ages to create a key for whatever Arch wanted (don't recall what). On Mon, Aug 19, 2013 at 10:21 AM, Harald Hanche-Olsen wrote: > [Aaron Toponce (2013-08-19 13:20:45 UTC)] > > > I'm currently working on a program to feed the random data found > > from an RTL-SDR dongle into the entropy pool. Then just tune to an > > empty frequency, and let atmospheric noise rule. > > The raspberry pi supposedly has a hardware RNG built in. > Perhaps one could be used as a random data "dongle"? > It's not like they're super expensive. > > > http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/ > > - Harald > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Mon, Aug 19, 2013 at 11:31 AM, Aaron Toponce wrote: > Hopefully they rise like a phoenix, and their product is for sale again. I > would like to purchase more. > > No kidding. I think someone on here told me about them and I tried to get one a bit later and couldn't. I think the company I work for might also get a few as well. It's not like they're the only ones that sell these, but they /were/ the only ones to sell USB PRNG at <$800. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
Not exactly. I think havaged is better at this as you're relying on the same type of data but with a single source. I also don't believe you want a microphone inline in order to do this. You should rely purely on electric noise with the ADC/mixer. I don't even think the volume level affects the quality of the randomness. Though I think you generate more "random" bits at higher levels. Again, at this point, I trust a modern linux kernel or havaged more than a rigged solution. -Original Message- From: "James A. Donald" To: cryptography@randombit.net Sent: Tue, 20 Aug 2013 5:54 Subject: Re: [cryptography] urandom vs random On 2013-08-20 1:31 AM, ianG wrote: > It's a recurring theme -- there doesn't seem to be enough market > demand for Hardware RNGs. Every microphone is a hardware RNG ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Fwd: Shadow Hardening
That's not really 'crypto' related but pretty cool. I only use password-less ssh, and /etc/shadow is -rw--- 1 root root. However, of course passwd has to be -rws--x--x 1 root root. I've looked at the ~200 (iirc) lines of code there and don't see how you could do anything evil there, but just because I didn't see it... So, maybe I do have a place for this :) On Thu, Sep 12, 2013 at 11:08 PM, Gutem wrote: > Someone already used this? > http://www.openwall.com/tcb/ > > - Gutem > > > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Introducing TDMX - Trusted Domain Messaging eXchange (Specification)
Per the purpose - this is to encrypt messages that generally traverse TCP/53 (zone transfer and the like), correct? On Thu, Sep 19, 2013 at 4:37 PM, wrote: > Dear cryptographers, > > I've been working privately on the design and proof-of-concept of an > enterprise messaging oriented middleware, named "Trusted Domain Messaging > eXchange". Think of it as an amalgamation of secure email and file transfer > with end2end encryption and mutual authorization. The specification is a > work in progress at [1]. > > Being a software engineer and not a hard core cryptographer - it would be > great to get some expert opinions on the concept and in particular the > proposed crypto scheme in the chapter "Cryptography". Several concrete > implementations are spec'ed out which offer PFS and the option to cascade > ciphers. > > I'm happy to answer any questions you might have. > > - Peter Klauser. > > [1] http://tdmx.org > > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Image hash function
Does anyone have a list of processes people have come up with to create images for hashes? The only one that I'm aware of is the "randomart" that is generated when creating a keypair for ssh ( http://www.ece.cmu.edu/~adrian/projects/validation/validation.pdf) I wanted a fuzzy solution - so an image would be similar but not the same for a given key. Say some type of fractal or optical ilusion with static that didn't defeat the ilusion or something like that? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] RSA equivalent key length/strength
Just an example of how to spend $250M. Jared Hunter wrote: >New to the list, so I'm sorry if I missed it, but what was the evidence >presented that RSA took a $10M payoff to make Dual EC DRBG the default >in Crypto-C? > >Thanks, > >-Jared > >> On Sep 22, 2013, at 9:01 AM, Peter Gutmann > wrote: >> >> ianG writes: >> >>> One mystery is left for me. Why so much? It clearly doesn't cost >that much >>> money to implement the DRBG, or if it did, I would have done it for >$5m, >>> honest injun! Nor would it cost that to test it nor to deploy it on >mass. >>> Documentation, etc. >> >> You're assuming that someone got passed a suitcase full of cash and >that was >> it. Far more likely that RSA got a $10M contract for some government >work and >> at some point that included a request to make the ECDRBG the default >for >> . All quite above board, >nothing >> terribly suspicious to raise eyebrows. >> >> Peter. >> ___ >> cryptography mailing list >> cryptography@randombit.net >> http://lists.randombit.net/mailman/listinfo/cryptography >___ >cryptography mailing list >cryptography@randombit.net >http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] RSA equivalent key length/strength
"James A. Donald" wrote: >On 2013-09-22 23:01, Peter Gutmann wrote: >> >> You're assuming that someone got passed a suitcase full of cash and >that was >> it. Far more likely that RSA got a $10M contract for some government >work and >> at some point that included a request to make the ECDRBG the default >for >> . All quite above board, >nothing >> terribly suspicious to raise eyebrows. > >Possibly, but security agencies do tend to use the suitcase full of >cash >gambit, not to mention the "we know where your children live" gambit. Do we have any proof of this? Is there any record of how we did business with Crypto-AG? >This, however, because done in secret, tends to be even more wasteful >and expensive that the supposedly above ground government contract. Well yes, windows with noise and radiation deflection or refraction and blast resistant probably cost more than those in your dining room. Also, we read this (and most of us are involved with this in some capacity for a living). This makes us spend a bit more time (and possibly money) securing our data. For example, the company I work for does lots of pentests - do you think we use an Active Directory domain? So if I'm working at a place that figures how to listen to LTE, do you think I'm going to let my employees use LTE? How much does it cost to get end to end encryption on a modern phone? How many models and chips do I reverse engineer? How many Angry Birds APKs do I do dynamic (and maybe static) analysis on? The report said they obtained information through hacking. So how much does their ingress and egress monitoring cost? What types of monitoring have they developed for mobile devices (bet someone like Mandiant has a killer contract for this)? You see $250 and wonder how you can spend that much. I see that and think "for that price can I have another". > >For a security agency to order a pizza costs ten million dollars. Again some proof would be nice. I've heard there is (or was) a BestBuy in the Pentagon that has standard prices on items. I'll bet that store is highly subsidized (scanning people and packages, shielding, etc) but I'd doubt the store sees much (any?) more profit above their other stores. >___ >cryptography mailing list >cryptography@randombit.net >http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Password Blacklist that includes Adobe's Motherload?
On Wed, Nov 13, 2013 at 9:13 PM, Jeffrey Walton wrote: > Hi All, > > Is anyone aware of a blacklist that includes those 150 million records > from Adobe's latest breach? > This is the only thing I've seen (haven't really looked): http://stricture-group.com/files/adobe-top100.txt > I tried finding a list and was not successful. Bonus points if > implemented as a bloom filter (I'm interested in seeing how small that > list can be in practice, and I'd like to use it for its small > footprint). > I did some quick searching and I don't see a PAM module to take that structure. It'd be interresting for other work we're doing if someone knows different. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] beginner crypto
andrew cooke wrote: > >it's difficult to know what would interest you, but there's a >collection of >puzzles / challenges that you can sign up for here - >http://www.matasano.com/articles/crypto-challenges/ - which are pretty >inteesting. you get to solve problems and at the same time learn about >how to >write secure code. andrew > Thanks for that. I emailed them - I guess they do this all by hand (which is sorta cool). Any other challenges like this (automated or not)? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] To Protect and Infect Slides
If you'll notice that both political parties have expanded on the NSA's mission, scope, and probably funding. I doubt there are any business motives here. In fact, it seems to me there are the exact opposite. Though, since much of government is now contracted out, I do wonder who this was billed out to? Also sorta interesting that the possibility of the NSA contracting a French company (Vupen) to find exploits. I always assumed HP, Rapid7, Mandiant, etc would do this type of thing and that it would be easier to clear companies in the US. coderman wrote: >On Wed, Jan 1, 2014 at 3:56 AM, Ralph Holz wrote: >> Hi Jake, >> >> Ian Grigg just made a point on metzdowd that I think is true: if you >> want to change the NSA, you need to address the [...] >> [... money] Because the chain goes like this: >> >> corporate money -> election campaigns -> representatives -> NSA > > >it should be noted that corporate money influence is currently aimed >at privacy eroding efforts in myriad manner. > > >you need to change the incentive to result in a privacy enhancing >impetus like this: > corporate money -> election campaigns -> representatives -> >defunding much NSA/CIA/DoD actvity. > >which is implemented not just in US, but all reasonable governments, >at the same time privacy aware corporations are implementing privacy >enhancing operations and software. this can be as simple as HTTPS only >with forward secret suites, or as significant as desired. > > >in other words: it's even more difficult! an effective response >requires cooperation of most governments and international corporate >entities. > > >there are tens and tens of billions that could be trimmed from the >black budget and DoD budget while preserving a minimal, defensive >force and command, allowing for targeted, HUMINT focused operations to >replace all wholesale and endemic COMSEC vulnerability exploiting >efforts. > > >good luck finding the incentive of sufficient force, and defending >against the significant pushback! > > >best regards, >___ >cryptography mailing list >cryptography@randombit.net >http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Fwd: Re: Commercialized Attack Hardware on SmartPhones
On list -- Forwarded message -- From: "shawn wilson" Date: Mar 2, 2014 11:37 AM Subject: Re: [cryptography] Commercialized Attack Hardware on SmartPhones To: "Tom Ritter" Cc: How about a dictionary and rules. Even if you choose an alphanumeric "strong" pass, you're kinda limited to the phone's keyboard - you're not going to want to switch case or between letters and special too often. Also, IIRC Android limits length to 15 chars. I also don't think the screen lock can be different than the boot pass (so everything I said above should hold true). Basically what I'm saying is use hashcat. On Mar 2, 2014 10:34 AM, "Tom Ritter" wrote: > Hey all, wondering if anyone knows of any commercialized hardware > (e.g. developed into a product, not just a research paper) that > conducts attacks on powered-on, Full Disk Encrypted Android/iPhone > phones that _isn't_ PIN guessing? > > So a powered-off FDE-ed iPhone or Android can be attacked by brute > force with no limiting factor. A good example of this type of > software is Elcomsoft [0] - they brute force the passphrase. > > A powered-on FDE-ed iPhone or Android can also be attacked by manual > or automated PIN entry - on the iPhone this can introduce a lockout, > but not on Android. Assuming they can't see your smudges and guess > the PIN/Swipe/password of course. I'm not sure if I know of a > commercialized solution to this that does it electronically, but a > friend of mine built a robot. [1] > > But if you have a strong passphrase, things are looking good. But > what about Cold Boot or DMA? > > I don't believe you can do a DMA attack against most Android phones - > it's just a USB port. But what about the HDMI-mini port? And is the > iPhone Thunderbolt/Lightning connector hooked up to DMA? > > As far as cold boot, I'm aware of the FROST paper[2], but that isn't a > commercialized offering, nor does it seem reliable or robust enough > for law enforcement needs. Chip-off attacks are very unlikely. AFAIK > iPhone jailbreaks require you to unlock your phone for technical > reasons, so those aren't possible without an unlocked phone (although > I'm not positive about that.) > > Does anyone know about anything in this space? Where an 'ordinary' law > enforcement agency (e.g. the NYPD, not the NSA) could shortcut a > strong passphrase on a phone technically? (e.g. not beating it out of > someone?) > > -tom > > [0] http://www.elcomsoft.com/eift.html#passcode > [1] http://boingboing.net/2013/07/26/pin-punching-200-robot-can-br.html > [2] https://www1.informatik.uni-erlangen.de/frost > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
What is the heartbeat used for in openssl anyway? On Apr 7, 2014 6:27 PM, "staticsafe" wrote: > On 2014-04-07 17:53, Edwin Chu wrote: > >> Hi >> >> A latest story for OpenSSL >> >> http://heartbleed.com/ >> >> ed >> > > Already patched in Debian. > > DSA 2896-1. > > -- > staticsafe > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
On Apr 8, 2014 2:03 AM, "Edwin Chu" wrote:
>
> I am not openssl expert and here is just my observation.
>
> TLS frame messages into length-prefixed "records". Each records has a
> 1 byte contentType and a 2 byte record length, followed by the record
> content and MAC.
>
> Heartbeat messages are TLS records with contentType 24 of this content
format:
>
>struct {
> HeartbeatMessageType type;
> uint16 payload_length;
> opaque payload[HeartbeatMessage.payload_length];
> opaque padding[padding_length];
>} HeartbeatMessage;
>
Here: https://github.com/FiloSottile/Heartbleed
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
On Tue, Apr 8, 2014 at 3:18 PM, wrote: >> Message du 08/04/14 18:44 >> De : "ianG" >> >> E.g., if we cannot show any damages from this breach, it isn't worth >> spending a penny on it to fix! Yes, that's outrageous and will be >> widely ignored ... but it is economically and scientifically sound, at >> some level. >> > > So, let's wait until another 40 million credit cards are stolen, then we > prove this method was used exactly, then we will try to fix it in all > deployments ... yeah, seems reasonable. > Keep it as is if you want. https://www.mattslifebytes.com/?p=533 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] question about heartbleed on Linux
On Thu, Apr 10, 2014 at 10:31 PM, John Levine wrote: >> Well, the operating system clears memory when it is allocated to a new >> process, > That's plenty bad, of course. Yeah, too bad none of that memory can be made executable :) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] NSA Said to Exploit Heartbleed Bug for Intelligence for Years
So I trust EFF's analysis more here. However this is newer than the latest article I've seen from EFF. So, where's Bloomberg's technical analysis on the subject? On Apr 11, 2014 5:50 PM, "Jeffrey Walton" wrote: > > http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html > > The U.S. National Security Agency knew for at least two years about a > flaw in the way that many websites send sensitive information, now > dubbed the Heartbleed bug, and regularly used it to gather critical > intelligence, two people familiar with the matter said. > > The NSA’s decision to keep the bug secret in pursuit of national > security interests threatens to renew the rancorous debate over the > role of the government’s top computer experts. > > Heartbleed appears to be one of the biggest glitches in the Internet’s > history, a flaw in the basic security of as many as two-thirds of the > world’s websites. Its discovery and the creation of a fix by > researchers five days ago prompted consumers to change their > passwords, the Canadian government to suspend electronic tax filing > and computer companies including Cisco Systems Inc. to Juniper > Networks Inc. to provide patches for their systems. > ... > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Silent Circle Takes on Phones, Skype, Telecoms
On Thu, Jul 10, 2014 at 10:52 PM, Tony Arcieri wrote: > On Thu, Jul 10, 2014 at 4:45 PM, John Young wrote: >> >> This is the comsec dilemma. If a product or system becomes mainstream >> it is more likely to be overtly and/or covertly compromised. > I don't find this a dilemma - I don't use immature projects because they haven't had time prove themselves and get stress tested. I like the idea of LibreSSL but won't use it for at least 3 years (if it gains traction). > Clearly OpenSSL is a great demonstration that many eyes don't make > bug(door?)s shallow, but if the source is available, it's certainly > something that can be used to build trust in a system. > I don't think that's a good example at all. I think OpenSSL's issue is feature bloat without enough time for code audits. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Fwd: Cryptoparty 2014 - Hi my name is Ed - 2014/09/20
Is anyone (or know anyone) in the DC area who would like to talk at this event? The focus is on defensive security, identity, and tools (and some UX as it relates to things like gnupg). But I'd also like to see some more technical talks involving math or programatic use of encryption. If anyone is interested, the hacdc forum is an open Google group or you can email me (I can also provide another email that I use gpg with if you'd prefer). -- Forwarded message ------ From: shawn wilson Date: Sun, Jun 8, 2014 at 7:27 PM Subject: Cryptoparty 2014 - Hi my name is Ed - 2014/09/20 To: "blab...@hacdc.org" tldr: Speaking/links/software spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0AlbW1qRSpLFMdEM5MzV4YTBhQ0g0ZXdveUVuXzR3ckE&usp=sharing Meetup event: http://www.meetup.com/hac-dc/events/187948232/ For those who don't follow the list, the back story on the subtitle (besides me thinking it's ironic) is: https://groups.google.com/a/hacdc.org/forum/#!topic/Blabber/-N8UxXMvfxU First, we need speakers!!! In order to have an event like the last two years, people need to volunteer to present on what they know. Here's last year's doc (for reference) https://docs.google.com/spreadsheet/ccc?key=0AlbW1qRSpLFMdHVlN3ZDMmNQTVlUZVJDZTA4UHZSY2c&usp=sharing and here's this year's doc (for you to sign up and update software/links on [1]): https://docs.google.com/spreadsheet/ccc?key=0AlbW1qRSpLFMdEM5MzV4YTBhQ0g0ZXdveUVuXzR3ckE&usp=sharing If you work at a news agency or activist group where you feel you're handling communication and individuals' privacy correctly maybe you or your CTO would like to talk about it? If you enjoy crypto and would like to talk about your experience, sign up. If you think that crypto is hard and have ideas on how to improve it (I know you do) maybe you should give a talk. [2] If you have a friends, colleges, college professors, etc who is kinda local who you think would add content to our discussion, get them to sign up to give a talk. On the other hand, if you'd like to become more familiar with the most cryptographically secure ways to store and transmit data including how to setup encrypted (or signed) email, FDE [3], best password hashes to use and how hashing works, common mistakes when creating passwords/making more secure passwords, etc - please come. Here's the meetup event: http://www.meetup.com/hac-dc/events/187948232/ The event can still be pretty flexible (there's more going on at the church the week before, but I think we could work around that). I think I'll wait a few days to see if anyone shows any event conflicts (within the same sphere of computer/internet/security) but this should be it. [1] We can debate on the usefulness of an unmaintained TrueCrypt, but it probably should stay in that list for now. [2] https://researchspace.auckland.ac.nz/bitstream/handle/2292/2310/02whole.pdf?sequence=2 and later https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf [3] FDE - full disk encryption (will probably be mentioned later in this thread) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Question About Best Practices for Personal File Encryption
I just use gpg and armor the file. If its text, there's also a vim plugin that works perfectly with this method. On Aug 16, 2014 12:06 AM, "Mark Thomas" wrote: > I have a question for the group, if I may ask it here and in this manner > (?). > > What are you guys using to encrypt individual files and folders or even > entire drives like a USB? > > I am thinking that: > > 1. any commercial product could be compromised and not completely secure. > Like Apple’s FileVault2, which Apple has a key to. > > 2. It is probably open source. > > 3. It is probably implemented with the command line. > > Am I on the right track? If so does anyone know of a helpful guide to get > started with OpenSSL on the command line besides the man pages? > > Regards, > > Mark > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Cryptoparty 2014 - Hi my name is Ed - 2014/09/20
I've created a @cryptopartydc twitter account where I'll put more frequent updates. On Sun, Aug 17, 2014 at 5:51 PM, shawn wilson wrote: > Is anyone (or know anyone) in the DC area who would like to talk at > this event? The focus is on defensive security, identity, and tools > (and some UX as it relates to things like gnupg). But I'd also like to > see some more technical talks involving math or programatic use of > encryption. > > If anyone is interested, the hacdc forum is an open Google group or > you can email me (I can also provide another email that I use gpg with > if you'd prefer). > > > -- Forwarded message -- > From: shawn wilson > Date: Sun, Jun 8, 2014 at 7:27 PM > Subject: Cryptoparty 2014 - Hi my name is Ed - 2014/09/20 > To: "blab...@hacdc.org" > > > tldr: > Speaking/links/software spreadsheet: > https://docs.google.com/spreadsheet/ccc?key=0AlbW1qRSpLFMdEM5MzV4YTBhQ0g0ZXdveUVuXzR3ckE&usp=sharing > Meetup event: http://www.meetup.com/hac-dc/events/187948232/ > > For those who don't follow the list, the back story on the subtitle > (besides me thinking it's ironic) is: > https://groups.google.com/a/hacdc.org/forum/#!topic/Blabber/-N8UxXMvfxU > > First, we need speakers!!! In order to have an event like the last two > years, people need to volunteer to present on what they know. Here's > last year's doc (for reference) > https://docs.google.com/spreadsheet/ccc?key=0AlbW1qRSpLFMdHVlN3ZDMmNQTVlUZVJDZTA4UHZSY2c&usp=sharing > and here's this year's doc (for you to sign up and update > software/links on [1]): > https://docs.google.com/spreadsheet/ccc?key=0AlbW1qRSpLFMdEM5MzV4YTBhQ0g0ZXdveUVuXzR3ckE&usp=sharing > > If you work at a news agency or activist group where you feel you're > handling communication and individuals' privacy correctly maybe you or > your CTO would like to talk about it? > If you enjoy crypto and would like to talk about your experience, sign up. > If you think that crypto is hard and have ideas on how to improve it > (I know you do) maybe you should give a talk. [2] > If you have a friends, colleges, college professors, etc who is kinda > local who you think would add content to our discussion, get them to > sign up to give a talk. > > On the other hand, if you'd like to become more familiar with the most > cryptographically secure ways to store and transmit data including how > to setup encrypted (or signed) email, FDE [3], best password hashes to > use and how hashing works, common mistakes when creating > passwords/making more secure passwords, etc - please come. > > Here's the meetup event: http://www.meetup.com/hac-dc/events/187948232/ > The event can still be pretty flexible (there's more going on at the > church the week before, but I think we could work around that). I > think I'll wait a few days to see if anyone shows any event conflicts > (within the same sphere of computer/internet/security) but this should > be it. > > [1] We can debate on the usefulness of an unmaintained TrueCrypt, but > it probably should stay in that list for now. > [2] > https://researchspace.auckland.ac.nz/bitstream/handle/2292/2310/02whole.pdf?sequence=2 > and later https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf > [3] FDE - full disk encryption (will probably be mentioned later in this > thread) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] best practice openssl.cnf
Does anyone have a best practice options to use in use for self signed certs with openssl? I just noticed that default_md = md5 was in most examples and a debian/ubuntu bug to up the default to sha1 and i think the best md openssl supports is sha256. So I figured I'd see if anyone had made some 'crypto best practice' openssl config file that I could go off of? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Gogo inflight Internet uses fake SSL certs to MITM their users
You can smartly limit resolution in squid - I don't trust this is what they were doing, but you could provide a better experience like this. On Tue, Jan 6, 2015 at 11:01 AM, Peter Maxwell wrote: > > > On 6 January 2015 at 15:40, Jeffrey Altman > wrote: >> >> On 1/5/2015 8:47 PM, John Levine wrote: >> > >> > >> > http://venturebeat.com/2015/01/05/gogo-in-flight-internet-says-it-issues-fake-ssl-certificates-to-throttle-video-streaming/ >> > >> > They claim they're doing it to throttle video streaming, not to be evil. >> > >> > Am I missing something, or is this stupid? If they want to throttle >> > user bandwidth (not unreasonable on a plane), they can just do it. >> > The longer a connection is open, the less bandwidth it gets. >> >> I suspect that throttling user bandwidth is not the goal. Instead they >> are attempting to strip out embedded video from within http streams. >> Since the video stream might be sent over the same tcp connection as >> non-video content they can improve the user's experience by delivering >> all but the video. > > > So why do they not take a more traditional approach of: > > i. blocking obvious video services (YouTube, etc) wholesale; and, > > ii. limiting sustained bandwidth per user at a level that would frustrate > viewing video anyway. > > > It's somewhat easier to do than intercepting SSL/TLS connections. > > > > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
So the practical reason behind everyone saying "unless you have qualifications, etc, don't do this" is because, even if you make something and say it's just for your learning or a joke or w/e, someone (no joke) *will* use it and then some Fortune 500 will fall over because of your joke code. So, yeah, don't do this - as in, it'd be best to take it down for everyone's sanity. On Tue, Jan 6, 2015 at 6:25 PM, John Young wrote: > At 04:55 PM 1/6/2015, you wrote: > > Yes, that is the received canon of cryptosystems: > > 1.Sarcasm toward unqualified efforts, > > 2. Designing cryptosysystems is *hard*. > > 3. No, that's too mild, it's mindblowingly* hard. > > 4. It doesn't start with code, it strts with mathematical description. > > 5. No, even that is not true, it starts with years of study. > > 6. Denizens of this list have seen a hundred cryptosystems crash and burn. > > 7. Some of them designed by very clever people. > > 8. Designing crytposystems is hard. > > 9. Don't even think of trying it, not unless a fewyears spent studying the > state of the art. > > 10. Sorry to be blunt. > > Not to mention how often thclaims are made despite thier sounding like > alchemy and astrology, cultish, religious, authoritarian, scientistic, > recruitment > for arcane pursuit of unsolvable mysteries, and hardly applicable to the > long > and varied history of cryptology suffused with bizarre claims, subterfuge, > deception, betrayal, treachery, obligatory prevarication, inherent cheating, > diabolical misrepresentation of trustworthiness, venomous accusations > against competitors, unrestrained dupery and duplicity against the unwary, > citizen and royalty alike. > > Nor that mathematics is a modern innovation in cryptology and remains > its weakest element due to inability of its applicators to wed it to code > and hardware without recourse to alchemy and astrology favored by > promoters, sales and PhDs who dream of math as golden key to natsec. > > QODE, QED. > >> Kevin wrote: > I figured I'd start building my own open source encryption >> algorithm: > https://github.com/kjsisco/qode If you feel overwhelmed by the >> sarcasm directed your way, there is a reason for that. Designing >> cryptosystems is *hard*. No, that's too mild. Is *mindblowingly* hard. It >> doesn't start with code. It starts with a mathematical description. No, even >> that is not true: It starts with years and years of study. The denisens of >> this list have seen a hundred cryptosystem crash and burn. Some of them were >> designed by very clever people. Did I mention that designing cryptosystems >> is hard? Don't even think of trying it, not unless you have first spent a >> few years studying the state of the art. Sorry to be so blunt, but I think >> it will save you a whole lot of grief. – Harald >> ___ cryptography mailing list >> cryptography@randombit.net >> http://lists.randombit.net/mailman/listinfo/cryptography > > > > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
On Wed, Jan 7, 2015 at 1:26 PM, Kevin wrote: > Any company could review it and decide if it's worth using or not. Ok, lets run with that - as a company, show me the steps (make file, a test suite in any programming language, or just english if you prefer), explain to me the steps one would go through to verify your crypto isn't battshit crazy? There have discussions about frameworks to test crypto on this list and iirc a few exist but I haven't gone though the time to figure out how to implement something. So, if you (or anyone else) has a verification method, I'm all ears. And, I'm not the smartest one (on this list or even the smartest sysadmin) but if I don't know, I wouldn't expect at least the majority of other devs/admins to know how to verify your crypto past the simplest code review (I wouldn't have a clue how to besides fuzzing some stuff from the outside). Hence I say, it's a mistake to publish any toy you want to call "crypto". ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
On Wed, Jan 7, 2015 at 2:40 PM, Jeffrey Goldberg wrote: > On 2015-01-07, at 12:26 PM, Kevin wrote: > >>Any company could review it and decide if it's worth using or not. > > Hi Kevin. > > Actually that’s a part of my job within the company I work for. I’m the one > who can read some of the primary literature in cryptography. Now this makes > me unusual, not a lot of companies > our size have someone with my skills. > And I'm betting they're Fortune 100. My point is, the company I work for does pentesting and have seen so many issues with information that people thought was "encrypted" not being "encrypted" and then leaked because it was only obfuscated with some base32/64 or w/e and maybe rotated by some value or w/e. It's kinda insane what people will do instead of using a well vetted crypto library. So I'm fearful that we'll stumble across someone using your library by finding some issue with it and the client says "well, we encrypted it" and then "well, obviously not". OTOH, people will be people. If you want to keep it available and hope that no one uses it in production and that someone reviews it *shrug*. If someone uses it vs making their own system, hopefully you're smarter than them (probably) and it'll be harder to break than w/e they might've done. And it would probably be a good learning exercise if an "expert" got back to you with issues. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Cryptanalysis of RADIUS MD5 cipher?
I'd look at the rfc before asking this. You seem to be looking for application issue (overrun or parse issues) which has nothing to do with the crypto. IIRC the password is padded up to 112 characters - Idr much more than that. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Crypto Vulns
On Mar 7, 2015 9:11 PM, "coderman" wrote: > > On 3/7/15, Dave Horsfall wrote: > > On Sat, 7 Mar 2015, Kevin wrote: > > > >> > No 1 vulnerability of crypto is the user > >> > 2nd passphrases > >> > 3rd overconfidence > >> > 4th trust in the producer > >> > 5th believing backdoors are No. 1 > >> > >> I don't agree that the user should be first on that list unless you are > >> talking about poor implementation. > > > > How would you arrange them, then? I seem to recall that Enigma was broken > > largely due to sloppy user practices e.g. weak message key, re-use of > > keys, repeating same message with a weaker scheme, etc. Used properly, > > Enigma would've been unbreakable at the time. > > > 1. failed software and security engineering. [#'s 1, 2, 4 above all > reduce to this error.] I strongly agree with this. For example, people are told to use a password managers for each site and most people end up with the same password across hundreds of sites - is that a user failure or one of software? I copy and paste passwords between pgp files and browsers all the time but I don't expect my mom to. > 2. overconfidence [believing backdoors or nation state attacks are > your weakness is overconfidence in the rest of your threat model] Well kinda (not necessarily "overconfidence" but the example). How about this: would the creator of gnupg be getting >$100k per year (I think it's renewed in 5 years - I suspect it will be) without the NSA things? Point being, jumping at shadows can cause productive fear (until you die of a heart attack). > 3. complacency [if everything else is in place, letting habit slide to > convenience, then to compromise, will result in sorrow.] > Orgs with otherwise pretty damn secure software setups do education next to teach their people how not to mess up again (this is generally done after a pentest). However, your average organization isn't going to do this - your average person can't do this. So I wonder whether we really want to change habits or make software that learns to conform to the user while staying secure. > some would say that truly strong, usable crypto systems with integrity > for the common public are impossible. i would retort that just because > we don't know how to build them yet, does not mean they won't exist in > the future. :P > We're starting to build them - take Proton Mail for example. No need to know pgp, generate a key, verify keys (I don't use it so IDK how they handle trust). The keys are local to you. It seems there might be shortcomings with this but I'll give them "pretty good". And this is just one example of how you can take a pretty sophisticated software and make it so that end users can deal with it and aren't likely to leak data and the like. OTOH, systems like Active Directory that are hard to setup, not scalable, allow downgrading of hashes, and have issues like PtH central to the protocol. Again, not something you can blame a user for - just a badly designed system. We can do better - should expect better. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Underhanded Crypto Contest - All Entries Published
I skimmed a few of those and noticed two submissions for signature issues: RyanCastellucci, and AleksanderEssex. Is it normal for people to find issues with the signing/verification process or is this just coincidence? On Sat, Mar 21, 2015 at 5:44 PM, Adam Caudill wrote: > FYI - All of the entries received for the Underhanded Crypto Contest have > now been published. See here for the list and downloads: > > https://underhandedcrypto.com/2015/03/21/all-underhanded-crypto-entries/ > > --Adam Caudill > http://adamcaudill.com > > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] GeoTrust Launches GeoRoot; Allows Organizations with Their Own Certificate Authority (CA) to Chain to GeoTrust's Ubiquitous Public Root
Good catch - it would seem 10 years old to be exact: http://www.hostreview.com/news/050215geotrust.html On Mon, Apr 6, 2015 at 10:30 AM, Peter Bowen wrote: > I think that press release is years old. GeoTrust was bought by VeriSign > years ago who was then bought by Symantec. > > This kind of agreement now requires the subordinate to be audited to the > same standards as all other public CAs. > > On Apr 5, 2015 3:03 PM, "Jeffrey Walton" wrote: >> >> >> http://www.prnewswire.com/news-releases/geotrust-launches-georoot-allows-organizations-with-their-own-certificate-authority-ca-to-chain-to-geotrusts-ubiquitous-public-root-54048807.html >> >> It appears Google's Internet Authority G2 (https://pki.google.com) >> could be part of this program since the subordinate CA is certified by >> GeoTrust Global CA. If you look at the certificate, it is *not* name >> constrained so Google can mint certificates for any domain (and not >> just its web properties). I'm not too worried about Google. But I >> can't say the same for any old organization that joins this program. >> >> Both the IETF and CA/B Forums have name constraints that could be used >> to enforce policy. The relevant documents are RFC 5280, 4.2.1.10 Name >> Constraints and Baseline Requirements, 9.7 Technical Constraints in >> Subordinate CA Certificates via Name Constraints. >> >> I'm not sure if the program targeting organizations as a subordinate >> CA is a bad idea or if GeoTrust is doing a bad job by not using name >> constraints. But as it stands, I don't like the smell of things. >> ___ >> cryptography mailing list >> cryptography@randombit.net >> http://lists.randombit.net/mailman/listinfo/cryptography > > > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] GoVPN -- reviewable secure state-off-art crypto free software VPN daemon
On May 4, 2015 5:09 AM, "Jane" wrote: > > Actually, in my oh so very humble opinion, world has enough reasonably good VPNs that can operate on reasonably good connections. > > What is lacking is something that can function transparently and effectively on a very flakey connection (thing lousy GPRS one) without introducing noticeable overhead. > Given that lousy GPRS connections are unstable, any classic VPN scheme starts suffering a lot of connection re-negotiation overhead, which sucks (even if the overhead for a single instance of properly negotiating a session key is minuscle, when you do it every goddamn time connection is lost, it starts adding up really fast). > Also, hearbeating tends to eat mobile battery pretty fast. > What you're looking for is "multi homed vpn", there are quite a few posts and articles on the subject. Both OpenVPN and IPSec can do this (though IPSec is more flexible and should do exactly what you want). ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] no, don't advertise that you support SSLv2!
Yahoo has always had lax security (weak spam filters, no bad pass lock, no attachment virus scan). But as a news site (as long as their reporters get to have better security), they don't do bad. On Aug 3, 2015 10:03 PM, "Patrick Pelletier" wrote: > I was on an e-commerce site today, and was horrified when I saw the > following badge: > > https://lib.store.yahoo.net/lib/yhst-11870311283124/secure.gif > > Did they still have SSLv2 enabled? I checked, and luckily they don't: > > https://www.ssllabs.com/ssltest/analyze.html?d=us-dc2-order.store.yahoo.net > > So, it's not as bad as their badge claims, but still, they only get a C. > (They support only one version: TLS 1.0.) I would've thought a big Web > property like Yahoo could do better. :( > > --Patrick > > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] IIRC, there was discussion on this list a while back about D-Wave...
http://www.technologyreview.com/news/544276/google-says-it-has-proved-its-controversial-quantum-computer-really-works/ Just curious what y'all think about NASA's research and Google's paper (linked to in the article - I read the abstract, but not much else yet) ? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Kernel space vs userspace RNG
Just reflecting on the Linux RNG thread a bit ago, is there any technical reason to have RNG in kernel space? There are things like haveged which seem to work really well and putting or charging code in any kernel can be a bit of a battle (as it should be with code as complex as that involving crypto - wouldn't want people missing an exploit your new system exposes and accepting it*). So I wonder what the gain is for putting RNGs in the kernel. The only argument I can think of against this is non technical - if you rely on users to pick their RNG implementation, they are liable to get it wrong. This may be valid but I'm still curious about the technical reasons for RNG in kernel space. Also, if kernel space is really necessary, I'd think publishing as a dkms type package would gain more traction for getting into mainline (but this is probably OT here) * Obviously that same argument can be made of userspace programs but I'd much prefer my exploits happen at a less privileged ring whenever possible :) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Kernel space vs userspace RNG
On May 5, 2016 2:22 PM, wrote: > > I think this sums it up well. Today you are thrown into having to know > what to do specifically because it's a system level problem (matching > entropy sources to extractors to PRNGs to consuming functions). > > The OS kernel does a thing well that is it's job - taking single physical > instances of entropy sources, post processing it and making it available > to all userland and kernel consumers. > > However kernel writers cannot address the full system issue because they > don't know what hardware they are running on. They don't know if they are > in a VM. They don't know whether or not they have access to entropic datao > or whether something else has access to the same data. > > So one of the "things you should know" is if you run a modern Linux, > Solaris or Windows on specific CPUs in specific environments (like not in > a VM) then it can and will serve your userland programs with > cryptographically useful random numbers, at the cost of a fairly large > attack surface (drivers, APIs, kernel code, timing, memory etc.) > > Intel came down firmly on the side of enabling the userland. One > instruction puts entropic state into the register of your running userland > program. Smaller attack surface, simpler, quicker, serves multiple users > whether or not they are running in on bare metal or in a VM. You have to > trust the VM (as you do for anything else you do in a VM). Stuff is done > in hardware to make sure it serves multiple consumers, just as an OS does > stuff to serve multiple consumers. > > A SW userland RNG is an effective method to connect entropy sources you > know about on your system to algorithms that meet your needs. The recent > switch to NIST requiring 192 bits or greater in key strength has > precipitated a few 256 bit SW SP800-90 implementations. I know, I wrote a > couple of them and I've reviewed a few others that have been written in > response to the NIST change. > > SW RNG code is also easy to take through certification. > The different is you take the system through certification, not just the > code (except for CAVS). An OS kernel writer doesn't have that advantage. > > So my general view is that if you are tasked with enabling random numbers > in your application, userland is usually a better place to do it. Maybe in > a decent library used directly by your application. Maybe with some > trivial inline assembler. But only if you can control the entropy source > and the sharing of it. If you can use HW features (RdRand, RdSeed, other > entropy sources, AES-NI, Hash instructions etc.) then your SW task is > simplified, but it assumes you know what hardware you are writing for. > Ditto for other platforms I'm less familiar with. > > The mistake I have seen, particularly in certain 'lightweight' SSL > libraries is to say "It's our policy not to do the RNG thing - we trust > the OS to provide entropy" and read from /dev/urandom as a result (because > /dev/random blocks on many platforms). They are trusting the thing that is > not in a place where it can guarantee entropy sources are available. It > will work on some platforms and will certainly fail on some platforms, > particularly lightweight platforms with Linux kernels on CPUs with no > deliberately designed source of entropy which is where lightweight SSL > libraries are used most. > This was pretty much my thinking (though idk Intel thought similar). If this is debatable, that's fine as long as my view isn't totally batt-shit-crazy :) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
