similar to: [PATCH] configure.ac/cipher.c: Check for OpenSSL with EVP_des_ede3_cbc

Hi everyone, (Sorry if I'm asking at the wrong mail listing, but compiler-rt page tells I'd better write on llvm-dev rather than cfe-dev/cfe-users.) I've just built LLVM/Clang+Compiler-rt (Compiler-rt is put inside llvm/projects folder) and tried the -fsanitize option. But strangely the link failed since it cannot find *libclang_rt.san-x86_64.a*. The error message is as

Hi, the following patch to cipher.c enables OpenSSH 3.9.1 to compile on IRIX 5.3 with the native IDO cc: --- cipher.c.orig 2004-10-17 12:04:10.000000000 +0200 +++ cipher.c 2004-10-17 13:43:22.000000000 +0200 @@ -76,15 +76,15 @@ u_int key_len; const EVP_CIPHER *(*evptype)(void); } ciphers[] = { - { "none", SSH_CIPHER_NONE, 8, 0,

Hi, I am trying to prune some uninteresting llvm ir branches, corresponding to the *if-else* condition in the source code. And here is the procedures: 1. Get the BasicBlock containing the BranchInst which has 2 successors(in order to keep consistent with the source code I am using the llvm ir without any optimizations, so SelectInst/SwitchInst/PHINode is absent), one of which should be

Thanks for your help, Wei-Ren and Anton. However since I am doing some experiments with klee( http://klee.llvm.org/GetStarted.html) and llvm-gcc seems to have better compatibility with it. So I still hope that I can use llvm-gcc:-) Hongxu Chen On Sat, Mar 16, 2013 at 3:35 PM, 陳韋任 (Wei-Ren Chen) [via LLVM] < ml-node+s1065342n56013h94 at n5.nabble.com> wrote: > Hi Chen, > >

On Sat, Mar 16, 2013 at 06:16:01AM -0700, Hongxu Chen wrote: > Thanks for your help, Wei-Ren and Anton. > > However since I am doing some experiments with klee(http://klee.llvm.org/ > GetStarted.html) and llvm-gcc seems to have better compatibility with it. So I > still hope that I can use llvm-gcc:-) Seems you already found the answer on klee ML. :) Regards, chenwj --

On Fri, Oct 11, 2013 at 12:06 AM, John Criswell <criswell at illinois.edu>wrote: > On 10/10/13 10:43 AM, Hongxu Chen wrote: > >> Hi, this question might be a bit silly: apart from the language >> reference(http://llvm.org/**docs/LangRef.html#switch-**instruction<http://llvm.org/docs/LangRef.html#switch-instruction>) >> page, are >> there additional rules

https://bugzilla.mindrot.org/show_bug.cgi?id=2466 Bug ID: 2466 Summary: Cipher defines from opensslconf.h Product: Portable OpenSSH Version: 7.1p1 Hardware: All OS: Linux Status: NEW Severity: minor Priority: P5 Component: Miscellaneous Assignee: unassigned-bugs at mindrot.org

> But I got another problems. I successfully compile the pass and I can insert > the call printf (C Lib function) instructions in the LLVM IR(eg: call.bc). > If the call.bc didn't contain call printf instruction ,I can call printf > successfully ,but if not ,there exists a problem. the llvm will rename my > inserted call function , and the transformed code can not run correctly!

On Wed, 29 Mar 2023, Chris Rapier wrote: > I was wondering if there was something specific to the internal chacha20 > cipher as opposed to OpenSSL implementation. > > I can't just change the block size because it breaks compatibility. I can do > something like as a hack (though it would probably be better to do it with the > compat function): > > if

I'm hardly an expert on this, but if I remember correctly, the rekey rate for good security is mostly dependent on the cipher block size. I left my reference books at home; so, I can't come up with a reference for you, but I would take Chris' "I'm deeply unsure of what impact that would have on the security of the cipher" comment seriously and switch to a cipher with a

Ah, with an internal block size [Is that what one calls it?] of 64 bytes. From: Damien Miller <djm at mindrot.org> Sent: Wednesday, March 29, 2023 3:08 PM To: Robinson, Herbie <Herbie.Robinson at stratus.com> Cc: Chris Rapier <rapier at psc.edu>; Christian Weisgerber <naddy at mips.inka.de>; openssh-unix-dev at mindrot.org Subject: RE: [EXTERNAL] Re: ChaCha20 Rekey

That's true for block ciphers, but ChaCha20+poly1305 is a stream cipher. On Wed, 29 Mar 2023, Robinson, Herbie wrote: > > I?m hardly an expert on this, but if I remember correctly, the rekey rate > for good security is mostly dependent on the cipher block size.? I left my > reference books at home; so, I can?t come up with a reference for you, but I > would take Chris?

Hi everyone, Recently I tried to compile llvm-gcc-4.2-2.9 on a 64bit ubuntu12.04 machine. And I was using the settings below, export C_INCLUDE_PATH=/usr/include/x86_64-linux-gnu export LIBRARY_PATH=/usr/lib/x86_64-linux-gnu ../llvm-gcc-4.2-2.9.source/configure --enable-optimized --program-prefix=llvm- --enable-checking --enable-llvm=${HOME}/moonbox/llvm-obj/Debug+Asserts

On 10/10/13 10:43 AM, Hongxu Chen wrote: > Hi, this question might be a bit silly: apart from the language > reference(http://llvm.org/docs/LangRef.html#switch-instruction) page, are > there additional rules for a regular llvm frontend to generate llvm IRs? > > There are a few cases that I got from clang/llvm-gcc/dragonegg when > compiling *C* source code into llvm IR: > >

https://bugzilla.mindrot.org/show_bug.cgi?id=2608 Bug ID: 2608 Summary: Signed overflow in openbsd-compat/strlcpy.c Product: Portable OpenSSH Version: 7.3p1 Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: Miscellaneous Assignee:

http://bugzilla.mindrot.org/show_bug.cgi?id=371 Summary: OpenSSH fails to build on Alpha True64 in cipher.c Product: Portable OpenSSH Version: -current Platform: Alpha OS/Version: OSF/1 Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org

Hi everyone, I have some trouble in instrumenting load instructions. I want to instrument load instructions as follow: Firstly, I judge whether the loaded pointer(*any type is possible*) is NULL. If so, I want to explicitly allocate the corresponding address space of its type to the pointer. For example, in source code level I want to translate the next statement *p = 1; into the next

On Wed, 29 Mar 2023, Thorsten Glaser wrote: > Hi Damien, > > >This is what I'm playing with at the moment: > > if you?re playing with this currently anyway, shouldn?t? > > >+ /* > >+ * Otherwise, use the RFC4344 s3.2 recommendation of 2**(L/4) blocks > >+ * before rekeying where L is the blocksize in bits. > >+ * Most other ciphers have a 128

On Thu, 30 Mar 2023, Damien Miller wrote: >> >+ return (uint64_t)1 << (c->block_size * 2); >> >> ? this get an upper bound? This is UB for 256-bit blocksizes >> at least? > >block sizes in struct sshcipher are in bytes, not bits Yes, exactly. 256 bit = 32 bytes; 32*2 = 64; (uint64_t)1 << 64 is UB. bye, //mirabilos -- Infrastrukturexperte ?

Guys, I wonder if anyone can give me any pointers here, I hope it's CentOS related enough not to be too off topic, if it is then apologies. I'm attempting to setup a CGI which can connect to a remote system and execute a command. On the 'client', for the Apache user 'apache' I've given it a shell and generated a key-pair. I've configured Keychain [