Bug#494043: ITP: ozymandns -- An experimental DNS server and miscellaneous DNS tools
Package: wnpp Severity: wishlist Owner: Jacob Appelbaum <[EMAIL PROTECTED]> * Package name: ozymandns Version : 0.0.1 Upstream Author : Dan Kaminsky <[EMAIL PROTECTED]> * URL : http://www.doxpara.com/ozymandns_src_0.1.tgz * License : (Currently consulting with upstream for explicit * license) Programming Lang: (C, Perl) Description : An experimental DNS server and miscellaneous DNS tools OzymanDNS is a suite of tools for experimenting with DNS. It includes a number of tools: aska.pl - DNS File/Stream Sender geta.pl - DNS File/Stream Receiver nomde.pl - Experimental DNS Server droute.pl - Reliable DNS Transport for standard input/output glance.c - Represents IP addresses as dates More information about all of these tools can be found in Dan's Black Ops DNS 2004 CCC Congress slides: http://www.ccc.de/congress/2004/fahrplan/files/297-black-ops-of-dns-slides.pdf -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#494043: ITP: ozymandns -- An experimental DNS server and miscellaneous DNS tools
Clint Adams wrote: > On Thu, Aug 07, 2008 at 12:48:20AM +0200, Lucas Nussbaum wrote: >> Confirmed. And it hasn't been fixed. > > That's why I run it in a while loop and find it to be reasonable > functional that way. > > I've done just that in a screen session and I've found it to be quite useful. Screen is probably a bit heavy for the package to depend on. It is relatively usable in my use cases. Best, Jacob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#494043: ITP: ozymandns -- An experimental DNS server and miscellaneous DNS tools
Lucas Nussbaum wrote: > On 06/08/08 at 23:17 +0100, Steve McIntyre wrote: >> Jacob wrote: >>> Package: wnpp >>> Severity: wishlist >>> Owner: Jacob Appelbaum <[EMAIL PROTECTED]> >>> >>> >>> * Package name: ozymandns >> Hmmm. I used to run this version of ozymandns to provide IP-over-DNS >> style services, and it was far from stable. It would often crash, drop >> connections or chew lots of CPU for no apparent reason. Unless things >> have improved substantially since, I would recommend strongly against >> adding these to the archive. > > Confirmed. And it hasn't been fixed. Hello, Micah Anderson encouraged me to package this software. We were both annoyed that it is both very useful and seemingly abandoned software. I'd agree that ozymandns has an unstable component (specifically nomde.pl in my experience). However, the file transfer utilities are just fine as far as I've seen. Have you had any problems with them? Do you have test cases that crash them? Despite the sometimes weird behavior of nomde.pl, Ozymandns as a suite is quite useful. I'm actually using it right now to send this email. :-) Currently Debian users can only use it as an unmaintained tar.gz randomly found online. Dan Kaminsky and I spoke about a Debian package. He seemed happy to have someone, even if it wasn't me, package it up. This was some time ago but I believe he still feels this way. I've recently attempted to contact him about licensing issues and hopefully that will be worked out soon as well... I've taken the time to integrate a widely used patch, write man pages and example documentation. I've also created an init.d script. Once I have finish packaging ozymandns, I hope to find the cause of the instability issues I've personally experienced. Best, Jacob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495416: ITP: AESKeyFinder -- A tool for finding and reconstructing AES keys.
Package: wnpp Severity: wishlist Owner: Debian Forensics <[EMAIL PROTECTED]> * Package name: AESKeyFinder Version : 1.0.0 * URL : http://citp.princeton.edu/memory/code/ * License : BSD Programming Lang: C Description : A tool for finding and repairing AES keys. This program illustrates automatic techniques for locating 128-bit and 256-bit AES keys in a captured memory image. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495418: ITP: RSAKeyFinder -- A tool for locating RSA private and public keys.
Package: wnpp Severity: wishlist Owner: Debian Forensics <[EMAIL PROTECTED]> * Package name: RSAKeyFinder Version : 1.0.0 * URL : http://citp.princeton.edu/memory/code/ * License : BSD Programming Lang: C++ Description : A tool for locating RSA private and public keys. This program illustrates automatic techniques for locating RSA private and public keys. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495419: ITP: AESFix -- A tool for correcting bit errors in an AES key schedule.
Package: wnpp Severity: wishlist Owner: Debian Forensics <[EMAIL PROTECTED]> * Package name: AESFix Version : 1.0.1 * URL : http://citp.princeton.edu/memory/code/ * License : BSD Programming Lang: C++ Description : A tool for correcting bit errors in an AES key schedule. This program illustrates a technique for correcting bit errors in an AES key schedule. It should be used with the output of the AESKeyFinder program. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495422: ITP: biosmemimage -- Tools for capturing memory dumps on x86 and x86-64 systems
Package: wnpp Severity: wishlist Owner: Jacob Appelbaum <[EMAIL PROTECTED]> * Package name: biosmemimage Version : 1.0.0 * URL : http://citp.princeton.edu/memory/code/ * License : BSD Programming Lang: C Description : Tools for capturing memory dumps on x86 and x86-64 systems This package contains proof of concept utilities for capturing memory dumps from Intel x86-based and AMD/Intel x86-64 based PC systems. PXE and USB memory scraper payloads are included. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: use of RDRAND in $random_library
On 6/13/14, Theodore Ts'o wrote: > On Fri, Jun 13, 2014 at 10:09:02AM +0200, Martijn van Oosterhout wrote: >> > Excuse me if I'm blunt here, but I understand that, on the point of >> > using entropy to seed a PRNG, if you have several shitty entropy >> > sources and one _really_ good one, and you xor them all together, the >> > resulting output is as random as the best of them. If your hardware >> > entropy source is faulted and produces just an endless stream of >> > '001001001001001001', xoring it with a valid Golomb sequence will give >> > you something even more random than a Golomb sequence. >> > >> The proof that XORing streams can't reduce the entropy relies on the >> sources being independant. I think the issue here is we don't know if >> RDRAND is independent or not. That said, doing a SHA256 over the output >> should be sufficient (assuming the CPU doesn't see you're doing a hash >> and >> short circuits it). > > Basically, the question is how blatently do you think the NSA could > bugger the CPU. If you believe they can completely bugger the CPU, so > they can detect that you are implementing some explicit crypto > instruction, and change its behaviour, or they can peek ahead in the > instruction pipeline, notice an XOR, determine that one of its inputs > is an RDRAND instruction, and the other inputs come from a read of > /dev/urandom, and then modify the behaviour of the XOR, all in such a > way that the hundreds or thousands of Intel employees that need to > improve, test, debug, etc. the CPU instruction execution engine > wouldn't notice, then you might as well give up now and start > implementing your own CPU from transitors, capictors, resistors, and > wires. > > While I am willing to believe they might be able to secretly subvert > or bribe Intel to subvert the RDRAND engine, in some way which no > other or very few other employees at Intel would detect, to believe > they could then do so with the entire CPU is MUCH harder to believe. > I would expect that if the NSA wanted to take control of the RDRAND or the rest of the CPU, they'd dynamically update the microcode in the CPU to change how it behaves. To do this, it appears that they'd need to sign a microcode and then apply an update. According to some great research by Ben Hawkes, it may be that there is a 2048bit RSA key that is used for signing: http://inertiawar.com/microcode/ In the case of Lavabit, we have learned that the US Government will assert that they can request cryptographic keys in a Grand Jury. Is it that case that they might try the same with Intel? Is 2048 a large enough key size to stop the NSA? There are quite a few open questions. If the NSA can update the microcode, I believe we could fairly state that they have subverted the security of the entire CPU. > There are probably much easier things to do, such as subverting > someone in Red Hat's release engineering department, for example. A > buggered kernel is easier to accomplish, and much harder to detect. > This is one of the reasons why implementing reproducible binary builds > is a realy good idea from a security perspective. This allows you to > spot check that various binaries correspond to the sources that they > claim to be form. > I agree and I'd add that they're likely taking many angles all at once. And it isn't just the NSA. The NSA just has a great head start and a home field advantage. "Intel Inside" could have a few different meanings! :-) All the best, Jacob -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cafggdf34pi1ojup0l48ncyk+szneosc7semjxqxh4gefg-n...@mail.gmail.com
Re: use of RDRAND in $random_library
On 6/13/14, Theodore Ts'o wrote: > On Fri, Jun 13, 2014 at 06:51:44PM +0000, Jacob Appelbaum wrote: >> I would expect that if the NSA wanted to take control of the RDRAND or >> the rest of the CPU, they'd dynamically update the microcode in the >> CPU to change how it behaves. To do this, it appears that they'd need >> to sign a microcode and then apply an update. > > The Intel CPU doesn't support a persistent microcode update. A > microcode update has to be uploaded after each power cycle. I'm aware and happy about that fact. However, I have a few concerns that come from a different core assumption: we know nothing about the microcode updates that are applied at boot on many systems. What do we know about the microcode updates that are shipping in various operating systems? I think very little. Ben's research is pretty fantastic for this reason. > That > means that a microcode hack would require that you break root first. I agree that a microcode insertion requires root but I'm not sure that an attacker must always be the one to insert it. Microcode seems like a perfect trojan horse and I am very suspect of it. > And if you can break root, you can just bugger the kernel or one or > more the userspace binaries. That's going to be as detectable as > leaving an extra firmware file in /lib/firmware/intel-ucode. > It would be interesting to allow microcode updates at boot only and to signal the kernel that no more are expected. That may change how such an update could be applied. I'm unsure if it would matter as you correctly state. Lots to do! > I've long considered that there are so many zero-day exploits that if > the NSA decides to carry out a focused attack on a single machine, or > machines belonging to a single person, there is a very high > probability they can do whatever they want. And this isn't a new > problems; even before the days of computers things like "black bag jobs" > were always a thing. > Of course, though they have certain advantages and we can ensure that there is a level playing field for all attackers. > So I'm personally much more concerned about bulk surveillance, whether > it involves passive surveillance using fiber taps, or trojans > introduced into distribution-provided binaries. Other people may have > their own personal sense of paranoia, but that's mine. I happen to > think mine corresponds more with reality, but I'm sure Keith Alexander > and James Clapper would try to claim that I should be wearing tin foil > hats or something. :-) > I think paranoia isn't the right term, your rationale is grounded squarely in reality. :-) All the best, Jacob -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAFggDF1wDAEPdYx=p7t7iokmevf6j_o_dkriuv+x4r1yzah...@mail.gmail.com
Re: myth(?): places in the world where https is illegal? Re: people.debian.org will move from ravel to paradis and become HTTPS only
On 7/21/14, Holger Levsen wrote: > Hi Iain, > > On Sonntag, 20. Juli 2014, Iain R. Learmonth wrote: >> The main one is that there are places in the world you just can't use >> HTTPS >> for legal reasons [...] > > I'm curious, can you name one? > I'm also curious - is there a Debian developer who will not use HTTPS but does use SSH to access servers? Is Debian still offering telnet services too? What other unsafe protocols are standard and in use? All the best, Jacob -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cafggdf2pnzk17uzkfh-hekv2-kyvxh9+qihvzltgmdtjrrr...@mail.gmail.com
Re: myth(?): places in the world where https is illegal? Re: people.debian.org will move from ravel to paradis and become HTTPS only
On 7/21/14, Iain R. Learmonth wrote: > On Mon, Jul 21, 2014 at 01:12:37PM +0200, Holger Levsen wrote: >> Hi Iain, >> >> On Sonntag, 20. Juli 2014, Iain R. Learmonth wrote: >> > The main one is that there are places in the world you just can't use >> > HTTPS >> > for legal reasons [...] >> >> I'm curious, can you name one? > > The United Kingdom when using IPv4 over AX.25 on Amateur Radio. Encryption > is illegal because it goes against the self-policing nature of the amateur > bands. I believe you are mistaken. My understanding is that you're not supposed to use crypto on the radio layer and IP packets are already several layers away from that concern. It would be great to hear from a HAM radio literate lawyer on this topic. Perhaps someone can ask the EFF if it is actually an important sticking point? More importantly, I suspect would be to first ask if anyone in the UK uses IPv4 over AX.25 to access people.debian.org? > > (I was hoping to actually locate one of the crackpot dictator countries > that > have laws for the general population but there doesn't actually seem to be > much data available on that). > Isn't any country that outlaws use of crypto by free people by definition a crackpot country? :-) All the best, Jacob -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cafggdf0p5nqvjvmkhysrpr81kuurhsvsvas_d22wpvwewrp...@mail.gmail.com
Re: myth(?): places in the world where https is illegal? Re: people.debian.org will move from ravel to paradis and become HTTPS only
On 7/21/14, Iain R. Learmonth wrote: > Hi Jacob, > > On Mon, Jul 21, 2014 at 01:14:14PM +0000, Jacob Appelbaum wrote: >> I believe you are mistaken. My understanding is that you're not >> supposed to use crypto on the radio layer and IP packets are already >> several layers away from that concern. It would be great to hear from >> a HAM radio literate lawyer on this topic. Perhaps someone can ask the >> EFF if it is actually an important sticking point? > > I am not a lawyer but I am a radio amateur. Here is a link to the Ofcom > Amateur Radio terms: > > https://services.ofcom.org.uk/amateur-terms.pdf > > "11(2) The Licensee shall only address Messages to other Amateurs or to the > stations of those Amateurs and shall not encrypt these Messages for the > purpose of rendering the Message unintelligible to other radio spectrum > users." > It sounds like it would be good to call and clarify things with a technologically literate lawyer. > I would take this to mean that no part of the message can be encrypted. > By that reasoning, we may not authenticate except by sending plaintext passwords over such a network. That seems to either be an old policy, a mistake or a network that is simply hostile towards modern security requirements for individuals. This seems to be relevant: https://www.tapr.org/pdf/DCC2010-AX.25-AuthenticationEffects-KE5LKY.pdf >> More importantly, I suspect would be to first ask if anyone in the UK >> uses IPv4 over AX.25 to access people.debian.org? > > This is not beyond the realm of possibility. I acknowledge the possibility and was inquring about *actuality* rather than mere possibility. Is anyone actually using IPv4 over AX.25 to access people.debian.org? > It would be permitted by the > Ofcom terms to download Amateur Radio software from p.d.o and also to > browse > Amateur Radio software documentation hosted there, which are both things > that the Debian policy would permit to be hosted. > Is anyone hosting software on p.d.o and actually having it downloaded over a radio link? That sounds like a good project but I wonder if practically it happens in the wild? > There are likely also other cases, which granted are likely edge cases, > where encryption cannot be used. We should not be beholden to the lowest common denominator. This seems especially so when it is a matter of theory and without practical issue. All the best, Jacob -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cafggdf0ob2hulvncvwy_u8pf_rdbz9ynstjl5oyiwsce0ix...@mail.gmail.com
Re: Bug#733860: ITP: pond -- Forward secure, asynchronous messaging for the discerning.
Philip Rinn: > Hi, > > I think it's important to add also the paragraph about actual usability for > the > homepage: > > Dear God, please don't use Pond for anything real yet. I've hammered out > nearly > 20K lines of code that have never been reviewed. Unless you're looking to > experiment you should go use something that actually works (e.g. GnuPG).[0] > > > I general I'd ask if it's not better to wait for code reviews before > packaging it. > > Best, > Philip > > [0] https://pond.imperialviolet.org > > I use Pond regularly on machines that run Debian and Tails. I'd also be happy to give it a shot at packaging it in about a month. I think it is fine to package but it should include the warning from the author. All the best, Jacob -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52c5b757.5030...@appelbaum.net
Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition
No kidding! How many uploaded binaries might include malware? A lack of binary determinism in the build process basically ensures that it isn't feasible to discover an answer to this question. :( All the best, Jacob On 2/13/14, Holger Levsen wrote: > Hi, > > On Donnerstag, 13. Februar 2014, Ondřej Surý wrote: >> this is just a pledge to you all fellow debian developers to update your >> build environment before you build a package. > > I want all binary packages to be rebuild on *.debian.org hosts. Everything > else is just an ugly workaround. > > > amen, > Holger > > P.S.: and reproducible builds after that, then... > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cafggdf1igi23fahwhsswhsace1xsvviwnob+i5n+skyh4bq...@mail.gmail.com
Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition
On 2/13/14, Jakub Wilk wrote: > * Jacob Appelbaum , 2014-02-13, 18:36: >>How many uploaded binaries might include malware? > > *shrug* It's not like it's difficult to hide malicious code in source > packages. > It is much harder for you to hide source code changes as a third party than binary changes. Many projects have code review processes with people who read each commit and reason about the contents of each code change. Very few public projects have a similar process for reverse engineering binaries or understanding the output of a compiler for releases. Those few projects generally aim for deterministic or reproducible builds - this still has the problem of missing a solid understanding of the output, by the way. > How many configure scripts that we never rebuild from source contains > trojans? There are several serious problems involved in this topic. One expects that we at least have processes for finding malicious configure scripts, as we find buffer overflows in C programs or as we find portability problems in assembler code - no such (Debian) process currently exists for inspecting binaries that are uploaded by developers. Perhaps I'm mistaken? Perhaps there is a project for actively inspecting and reverse engineering binaries that are uploaded by developers? A key problem here is not the badly behaving developer - it is the developer that is compromised and unwittingly becomes party to harming others. Minimizing this exposure is an important goal and worth consideration. All the best, Jacob -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAFggDF1XXuGoK_DR2LpGTDQX9NNPtou8F2JOJY=qj7ob7dk...@mail.gmail.com
Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition
Heya Sam, On 2/14/14, Sam Hartman wrote: > All rants aside, I believe there's a fairly wide agreement that we > should throw away binaries from builds. I'd encourage something slightly different and then I'd expand on it a bit. I think it would be useful to have an historical archive of each binary, as uploaded by a developer or produced by a build server. In the event that a binary is imperfect, storing a copy of each binary may be useful for later analysis. This could help us spot bugs for a compiler specific problem (such as optimizing something out of the binary that was otherwise in the source) or when the binary is simply malicious (such as a backdoor inserted by a compiler or build process). I'd say that we might consider *using* that uploaded binary as an assertion by a given developer. In general it is the expected correct output binary and it is signed by that developer. As we move into the deterministic/reproducible world, the archive will serve an interesting purpose. Each developer would upload their respective binary and signature per architecture for a given source package. Their output may be represented as GnuPG signatures over hashes of source code packages and binary packages. In theory, we could have an assertion from another developer with another upload and so on. Even though we should have matching hashes, in some cases, we may not learn that we have mismatching hashes for hours or days. Thus keeping a copy of all the built binary parts is useful for later analysis. This will allow us to verify that the sources correspond to a specific binary output, we could also ensure that very important packages require a threshold of signatures before the binaries are consider properly built. Those that upload a binary should not be able to delete the uploaded binary - thus when a build server or developer builds a *different* version, we'll be able to inspect *all files* for differences. So for each developer uploading, we'd keep a copy. We could discard identical binaries and ensure that a copy is only kept in the long run when there are no strange events. If a developer is compromised, we're able to detect it and ensure that the developer's system cannot be used to erase evidence of such a compromise. If the build system is compromised, it will be useful to download the binary from the archive and to inspect it. Similarly the build system may not erase items from the archive. This could add to the overall security of the process and to begin to give us some semblance of a review process for binaries served to users. Until something like that happens, I think we should probably not *ship* the developer built binaries to users. We will however ship some binary parts to the user and hopefully those will be built by the build servers, as well as archived somewhere for all time, in case we're already compromised. ( Append only data store ideas like Chisel may have a non-evil use, hooray! ) > > I seem to recall ftp-master sending out mail to debian-devel-announce > describing the steps along that process a while ago. > > I think it's fine to ask where that project is, and to volunteer > resources to help. > However, I'd hope we're all agreed that we need to get there. > I've been reading the deterministic build page and I think it could use some further discussions. All the best, Jacob -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAFggDF0kOQsNbdQ-5-LSuHr0z0zTnOWDnSXV+H5qA1khMKF=w...@mail.gmail.com
Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition
On 2/14/14, Paul Tagliamonte wrote: > On Fri, Feb 14, 2014 at 04:44:21AM +0000, Jacob Appelbaum wrote: >> Heya Sam, >> >> On 2/14/14, Sam Hartman wrote: >> > All rants aside, I believe there's a fairly wide agreement that we >> > should throw away binaries from builds. >> >> I'd encourage something slightly different and then I'd expand on it a >> bit. >> >> I think it would be useful to have an historical archive of each >> binary, as uploaded by a developer or produced by a build server. > > Perhaps you're interested in helping with http://snapshot.debian.org/ > then? :) > I'm glad to see that the really hard part of the process is already done! Amazing! > (I've got tons of these links!) > I'm enjoying reading them all. Thank you! :) All the best, Jacob -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAFggDF18ETcHJh4HJBw5=bjiqzvm0woy4pm4y6lpxcp21qk...@mail.gmail.com
Re: goals for hardening Debian: ideas and help wanted
On 4/25/14, Kevin Chadwick wrote: > previously on this list Paul Wise contributed: > >> I have written a non-exhaustive list of goals for hardening the Debian >> distribution, the Debian project and computer systems of the Debian >> project, contributors and users. >> >> https://wiki.debian.org/Hardening/Goals >> >> If you have more ideas, please add them to the wiki page. > ... > > Tor provides privacy and more likely lowers security so which threat > against contributors or contributor actions is the Tor policy aimed to > protect? I'm confused, what? How does Tor lower security and at the same time, it provides privacy? All the best, Jacob -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAFggDF14P25ZrOp3Yj=nfvaydtry+rnbcxgfdw-vvvrbvdf...@mail.gmail.com
Re: use of RDRAND in $random_library
On 6/11/14, Joey Hess wrote: > I stumbled over a library which has switched to using RDRAND in a new > upsteam version (not yet packaged), instead of /dev/urandom[1]. Which library is using it? > > I don't have a stong opinion on the security of RDRAND, which is a > contentious topic in a domain I am not expert in. However, I would much > rather rely on linux developers to make the right decision on that, > rather than libraries deciding on an ad-hoc basis. Especially because > the kernel has a wider spectrum of choices than use/avoid (IIRC it > currently mixes in RDRAND with other entropy sources.) > I tend to agree for a few reasons. Genreally, I don't trust RDRAND and the doping paper doesn't help: http://arstechnica.com/security/2013/09/researchers-can-slip-an-undetectable-trojan-into-intels-ivy-bridge-cpus/ > Perhaps we should avoid libraries in Debian using RDRAND directly, > if the library has uses related to security. (Maybe some game or > simulation library would have a good reason to use it.) > Quite a few programs and libraries will have this issue if a cursory search of the internet is an indication. > Would it make sense to scan for the opcode? Yes, very much so. It is potentially a security bug. It will be interesting to track it. All the best, Jacob -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cafggdf0rcbmta0wyu5wwjefmirkrj2rnuyl9ra-3xvo5mgk...@mail.gmail.com
